On Thu, Apr 23, 2015 at 12:11 PM, Pravin Shelar <[email protected]> wrote: > On Thu, Apr 23, 2015 at 11:55 AM, Jesse Gross <[email protected]> wrote: > >> I'm a little nervous about orphaning the packets in this case since it >> can potentially affect socket accounting and from a high level, >> there's no logical reason to do so (i.e. we're not crossing a boundary >> or something like that). >> >> I guess that in many cases (particularly on the transmit side), moving >> the truesize around in normalize_frag_list() and skb_try_coalesce() >> will effectively cancel each other out if we can merge things together >> (although I guess that depends on the source of the frag_list, IP >> fragment reassembly first tries to coalesce and then falls back on >> creating frag_lists, in which case us trying to merge things is a >> waste of time). It would be nice if we could relegate this to a corner >> case and just linearize in those situations. Or better yet, more >> deeply understand the conditions where we get the frag_list on >> transmit and see if it's really worth trying to coalesce them at all. >> grepping drivers/net I don't see a lot of frag_list creation. Even on >> receive, I'm not totally sure that breaking up frag_lists makes sense >> if skb_segment() can handle it now... > > Lat time I looked into it it could not handle uneven geometry of skb > that STT generate. I will recheck it.
I checked with or without STT segmenting the skb and saw 12% performance improvement with STT segmentation compared to skb_segment(). This is with ixgbe driver generating skbs with fraglist. _______________________________________________ dev mailing list [email protected] http://openvswitch.org/mailman/listinfo/dev
