[ovs-dev] [PATCH v7] datapath: Add Stateless TCP Tunneling protocol.

Jesse Gross jesse at nicira.com
Fri Apr 24 22:48:28 UTC 2015


On Fri, Apr 24, 2015 at 11:25 AM, Pravin Shelar <pshelar at nicira.com> wrote:
> On Thu, Apr 23, 2015 at 12:11 PM, Pravin Shelar <pshelar at nicira.com> wrote:
>> On Thu, Apr 23, 2015 at 11:55 AM, Jesse Gross <jesse at nicira.com> 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.

I suppose the frag_list is actually coming from GRO - I forgot or
didn't realize that it also did this if it ran out of room in the
frags array. And I guess the difference in performance is that the
segments we generate are still larger than MSS GSO segments since we
know we still have another layer behind us. This factor would apply to
both transmit and receive, so I guess we can put aside just not doing
segmenting at all.

OK, I guess we're back to orphaning as the only real possible
solution. I can't think of any real solution where we would both have
a frag_list and a socket owner on transmit, so I suppose it's not so
bad even if it is conceptually weird.



More information about the dev mailing list