[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAEP_g=8mYKypVS-MJeGnY4BGfPiu4zXRn-9--j5kntSFBe8Lnw@mail.gmail.com>
Date: Wed, 1 Oct 2014 14:12:34 -0700
From: Jesse Gross <jesse@...ira.com>
To: Or Gerlitz <gerlitz.or@...il.com>
Cc: Tom Herbert <therbert@...gle.com>,
Alexander Duyck <alexander.h.duyck@...el.com>,
John Fastabend <john.r.fastabend@...el.com>,
Jeff Kirsher <jeffrey.t.kirsher@...el.com>,
David Miller <davem@...emloft.net>,
Linux Netdev List <netdev@...r.kernel.org>,
Thomas Graf <tgraf@...g.ch>,
Pravin Shelar <pshelar@...ira.com>,
Andy Zhou <azhou@...ira.com>
Subject: Re: [PATCH] net: Add ndo_gso_check
On Wed, Oct 1, 2014 at 1:58 PM, Or Gerlitz <gerlitz.or@...il.com> wrote:
>> Also, this does not benefit the stack or drivers that already support
>> generic SKB_GSO_UDP_TUNNEL mechanism.
>
> But again, we have 4-5 drivers that are
>
> 1. upstream
> 2. support GSO offloading under VXLAN
> 3. advertize GSO_UDP_TUNNEL
>
> As a starting point to stabilize the system (3.18 which has FOU and
> friends, merge window coming up while we are @ LPC) we can
>
> 1. add GSO_UDP_VXLAN_TUNNEL type
>
> 2. ask each maintainer to decide if they want to advertize the generic tunnel
> or only the vxlan specific one
>
> 3. color udp tunneled skb's with the tunnel type being vxlan or something else
There is no point in doing this. We should create a generic mechanism
that allows for drivers to assert some restrictions. For existing
drivers we can just provide an implementation of restrictions that is
pretty conservative and ask driver writers to take a look and loosen
it if possible. This is both cleaner and just as safe.
--
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