[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+mtBx-aiCMyJocmDw8MfoGxWns2yppjFr8-hn6mH7yrFbMrGA@mail.gmail.com>
Date: Mon, 6 Jan 2014 10:46:32 -0800
From: Tom Herbert <therbert@...gle.com>
To: Or Gerlitz <or.gerlitz@...il.com>
Cc: Or Gerlitz <ogerlitz@...lanox.com>, Jerry Chu <hkchu@...gle.com>,
Eric Dumazet <edumazet@...gle.com>,
Herbert Xu <herbert@...dor.apana.org.au>,
Linux Netdev List <netdev@...r.kernel.org>,
David Miller <davem@...emloft.net>,
Yan Burman <yanb@...lanox.com>,
Shlomo Pongratz <shlomop@...lanox.com>
Subject: Re: [PATCH V1 net-next 2/2] net: Add UDP GRO support for vxlan traffic
On Mon, Jan 6, 2014 at 10:13 AM, Or Gerlitz <or.gerlitz@...il.com> wrote:
> On Mon, Jan 6, 2014 at 6:50 PM, Tom Herbert <therbert@...gle.com> wrote:
>> I think this would be a good start. We can further optimize the encap
>> path later on.
>
> good, did you had the chance to look on the 2nd problem I was facing,
> e.g how to prevent gro-ing encapsulated VM (this issue will not happen
> for non-virtualization schemes, I think) udp packets which happen to
> carry a destination port which belongs to an encapsulation protocol?
> as I wrote earlier here, I was thinking to add some field to struct
> napi_gro_cb which will be zeroed when the gro stacks starts to work on
> the skb and set once we pass udp_gro_receive, such that if we arrive
> again to udp_gro_recieve and this field is set, which means the
> encapsulated
> packet is udp one, we flush.
I don't see what the problem is, GRO should not be recursively applied
to an inner UDP header for encapsulation. The guest may try to do it's
own version of GRO on an inner UDP packet, but interpreting the
destination port correctly is its responsibility then.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists