On Mon, Mar 09, 2015 at 02:41:52PM -0500, swair shah wrote: > > > > I don't see how that can solve the problem that he is reporting. Did > > you read his whole scenario? If we knew how to handle the packet in the > > datapath at the beginning of the scenario then we would not be sending > > it to the controller. > > > > I doubt that this is a real problem that needs to be solved, because > > it's been in the back of my mind since about 2008 as a possible concern > > but this is the first time I remember anyone actually voicing it. Swair > > hasn't explained how it actually shows up as a problem in practice. > > Swair? > > I ran into this case when running some tests with streams of UDP datagrams. > Clearly in case of TCP, the flow would gradually build up and this case > would not occur as only the first 'ack' would not be followed by any > packets before the handshake is done. I am not sure how significant this > problem would be in real world scenarios.
I guess I don't count this as a real problem then. > Can this be done: > If we define flow as the set of packets with 'similar' header (I am not > sure on the granularity with which one would define 'similar' in this > case), then after the first packet buffer each subsequent packet in a > ordered list (and probably don't send Packet_In, for subsequent packets; > but this can be a configuration). In response to packet_out for first > packet forward all the packets from that list. > > Again, the issue is how would you decide if two packets are 'similar', i.e. > are to be queued in the same list. > > Another probably highly inefficient way to do is to check all the buffered > packets in response to every packet_in. I think that's the same as what I proposed. _______________________________________________ discuss mailing list [email protected] http://openvswitch.org/mailman/listinfo/discuss
