On Mon, Jun 01, 2015 at 07:53:51AM -0700, Adrian Chadd wrote: > oh, hm, you asked the next question. Sorry, I haven't had coffee. > > I vaguely remember testing this and discovering the /should/ be > putting all the frames in a packet int he same queue, as long as the > frames have a consistent set of fragment bits set. Ie, if you're doing > UDP and all frames in a packet have the fragment bit set, then all > fragments (first and the rest) go into the same queue. Frames in a > flow that are fragmented for some and not others (eg TCP flows with a > firewall/router doing explicit fragmentation, or a mix of small/large > UDP packets) will end up going into different queues. > > I can re-test this on ixgbe at some point, but IIRC that's how it behaved. > > I don't have the RSS stuff done for chelsio, so I haven't done any > experiments just yet. > > Now, I also remember that with the badly setup flowdirector code in > ixgbe it would mess that up, so the flowdir code was disabled in -HEAD > and I believe now in -10.
I am expect that second and next fragments may distributed in different queue. This is acceptable for me. And I think workaround of this in driver/OS code may be very expensive (collect and save 5-tuple, expiration control of this hash and etc). But I am very surprised that _first_ fragment distributed in different queue. I.e. fragment with frag_offset==0. Only different with DF bit clear and MF bit set. I am don't check case with frag_offset==0, DF bit clear and MF bit clear. May be this is also distrebuted in different queue. _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
