Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload

On 12/08/15 at 09:45pm, Alexei Starovoitov wrote: > definetely not 1, not 2 and hardly 3. > bpf verifier in 2k lines does full code analysis with all branches, > memory accesses and so on, so it's not hard to understand _intent_ > of the program by any HW backend. > I agree with John that it's not

Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload

On Wed, Dec 09, 2015 at 01:58:57PM +0100, Thomas Graf wrote: > > So if the goal is to make the intent available to the hardware in > a format which both the kernel and the hardware can draw the same > conclusions from, wouldn't something like P4 + BPF derived from P4 > be a possibly better fit?

Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload

On 12/09/15 at 09:38am, Alexei Starovoitov wrote: > On Wed, Dec 09, 2015 at 01:58:57PM +0100, Thomas Graf wrote: > > > > So if the goal is to make the intent available to the hardware in > > a format which both the kernel and the hardware can draw the same > > conclusions from, wouldn't something

Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload

From: Alexei Starovoitov Date: Wed, 9 Dec 2015 09:38:44 -0800 > p4 is a high level language and absolutely not suitable for such purpose. > bpf as intermediate representation can be generated from p4 or C or other > language. There is room to innovate in the

Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload

On 12/09/15 at 05:21pm, David Miller wrote: > It is clearly the most appropriate middle layer representation. > > The fact that BPF could be generated from any P4 program, yet the > reverse is not true, tells me everything I need to know. > > I'm sorry if you have either a mental or a time

Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload

From: Thomas Graf Date: Wed, 9 Dec 2015 23:03:39 +0100 > On 12/09/15 at 09:38am, Alexei Starovoitov wrote: >> On Wed, Dec 09, 2015 at 01:58:57PM +0100, Thomas Graf wrote: >> > >> > So if the goal is to make the intent available to the hardware in >> > a format which both the

Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload

On 15-12-08 02:33 AM, John Fastabend wrote: On 15-12-02 04:15 PM, Tom Herbert wrote: Just keying off the last statement there... I think BPF programs are going to be hard to translate into hardware for most devices. The problem is the BPF programs in general lack structure. A parse graph

Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload

On 15-12-08 09:23 AM, Jamal Hadi Salim wrote: On 15-12-08 02:33 AM, John Fastabend wrote: ;-> I feel a little vindicated with this discussion. Of course you can implement hardware using BPF! BTW - Just to be clear; I am not arguing for what that paper preaches. What the paper preaches is

Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload

On 12/08/15 at 10:10am, Jamal Hadi Salim wrote: > On 15-12-08 09:23 AM, Jamal Hadi Salim wrote: > >On 15-12-08 02:33 AM, John Fastabend wrote: > > >;-> I feel a little vindicated with this discussion. > > > >Of course you can implement hardware using BPF! > > BTW - Just to be clear; I am not

Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload

On Wed, Dec 09, 2015 at 02:40:38AM +0100, Thomas Graf wrote: > > I'm still having a difficulty trying to understand what exactly > the intended proposal around this is. You may have just answered > my question but just to make sure: When people refer to > implementing or interpreting BPF in

Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload

On 15-12-02 04:15 PM, Tom Herbert wrote: > On Wed, Dec 2, 2015 at 3:35 PM, John Fastabend > wrote: >> [...] >> I wonder why we need protocol generic offloads? I know there are currently a lot of overlay encapsulation protocols. Are there many more

Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload

On Sun, Dec 6, 2015 at 7:02 PM, David Ahern wrote: > On 12/6/15 6:20 PM, Alexander Duyck wrote: >> >> That works for Linux to Linux, but what about the cases where you have >> a non-Linux endpoint on the other end such as something like a Cisco >> switch? > > > Why does

Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload

> The only spot I think you and I disagreed on was the approach. I > don't know if the hard push back does anything but punish the users by > delaying the time needed to find a reasonable solution. I really > think if we are going to get the hardware vendors to change their > behavior we have to

Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload

On Sun, Dec 6, 2015 at 8:31 AM, Tom Herbert wrote: >> The only spot I think you and I disagreed on was the approach. I >> don't know if the hard push back does anything but punish the users by >> delaying the time needed to find a reasonable solution. I really >> think if

Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload

On 12/6/15 6:20 PM, Alexander Duyck wrote: That works for Linux to Linux, but what about the cases where you have a non-Linux endpoint on the other end such as something like a Cisco switch? Why does is matter what kind of switch the NIC is connected to? -- To unsubscribe from this list: send

Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload

On Sun, Dec 6, 2015 at 1:30 PM, Tom Herbert wrote: > On Sun, Dec 6, 2015 at 10:44 AM, Alexander Duyck > wrote: >> On Sun, Dec 6, 2015 at 8:31 AM, Tom Herbert wrote: The only spot I think you and I disagreed on was the

Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload

On Sun, Dec 6, 2015 at 10:44 AM, Alexander Duyck wrote: > On Sun, Dec 6, 2015 at 8:31 AM, Tom Herbert wrote: >>> The only spot I think you and I disagreed on was the approach. I >>> don't know if the hard push back does anything but punish the

Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload

From: Alexander Duyck Date: Sat, 5 Dec 2015 00:24:55 -0800 > Still, hard blocking this isn't necessarily going to push the > vendors to change their ways. Pushing back is different from blocking entirely. That means I'm going to be very difficult and make a lot of

Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload

> Keep in mind I don't represent one of the hardware vendors here > anymore. I am approaching this from the customer point of view. I > would like to have the performance I can get out of the parts I have. Trying enabling UDP checksum, GRO/GSO, and Remote Checksum Offload in VXLAN. Assuming you

Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload

On Sat, Dec 5, 2015 at 9:53 AM, Tom Herbert wrote: >> Keep in mind I don't represent one of the hardware vendors here >> anymore. I am approaching this from the customer point of view. I >> would like to have the performance I can get out of the parts I have. > > Trying

Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload

On Sat, Dec 5, 2015 at 10:03 AM, David Miller wrote: > From: Alexander Duyck > Date: Sat, 5 Dec 2015 00:24:55 -0800 > >> Still, hard blocking this isn't necessarily going to push the >> vendors to change their ways. > > Pushing back is different

Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload

From: Alexander Duyck Date: Sat, 5 Dec 2015 11:34:47 -0800 > I'm only really interested in what options the customers has in order > to get this all configured. As long as there eventually ends up being > some path forward I'll be good with whatever ends up happening,

Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload

On Fri, Dec 4, 2015 at 10:49 PM, David Miller wrote: > From: Alexander Duyck > Date: Fri, 4 Dec 2015 21:45:09 -0800 > >> Not having this feature has to in some way impact sales. > > I'm glad money trumps clean design and performance these days. > >

Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload

On Sat, Dec 5, 2015 at 2:27 PM, David Miller wrote: > From: Alexander Duyck > Date: Sat, 5 Dec 2015 11:34:47 -0800 > >> I'm only really interested in what options the customers has in order >> to get this all configured. As long as there

Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload

On Fri, Dec 4, 2015 at 12:26 PM, Hannes Frederic Sowa wrote: > Hi Dave, > > On Fri, Dec 4, 2015, at 21:06, David Miller wrote: >> From: Hannes Frederic Sowa >> Date: Fri, 04 Dec 2015 20:59:05 +0100 >> >> > Yes, I agree, I am totally with

Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload

From: Tom Herbert Date: Fri, 4 Dec 2015 12:13:53 -0800 > On Fri, Dec 4, 2015 at 12:06 PM, David Miller wrote: >> From: Hannes Frederic Sowa >> Date: Fri, 04 Dec 2015 20:59:05 +0100 >> >>> Yes, I agree, I am totally with you

Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload

[...] Please provide a sketch up for a protocol generic api that can tell hardware where a inner protocol header starts that supports vxlan, vxlan-gpe, geneve and ipv6 extension headers and knows which protocol is starting at that point. >>> BPF. Implementing protocol

Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload

Hi Tom, On Fri, Dec 4, 2015, at 19:28, Tom Herbert wrote: > > I do know that, but fact is, the current drivers do it. I am concerned > > about the amount of entropy in one single 16 bit field used to > > distinguish flows. Flow labels fine and good, but if current hardware > > does not support

Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload

On Fri, Dec 4, 2015, at 20:59, Hannes Frederic Sowa wrote: > And then filling out those fields using the offsetof and sizeof of the > headers, but this seemed to be very difficult a) because they use > bitmasks (which of course could be converted) or in case of IPv6 a > schema would have to be

Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload

Hi Dave, On Fri, Dec 4, 2015, at 21:06, David Miller wrote: > From: Hannes Frederic Sowa > Date: Fri, 04 Dec 2015 20:59:05 +0100 > > > Yes, I agree, I am totally with you here. If generic offloading can be > > realized by NICs I am totally with you that this should

Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload

On Fri, Dec 4, 2015, at 21:43, Tom Herbert wrote: > On Fri, Dec 4, 2015 at 12:26 PM, Hannes Frederic Sowa > wrote: > > Hi Dave, > > > > On Fri, Dec 4, 2015, at 21:06, David Miller wrote: > >> From: Hannes Frederic Sowa > >> Date: Fri, 04

Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload

On Fri, Dec 4, 2015 at 12:26 PM, Hannes Frederic Sowa wrote: > Hi Dave, > > On Fri, Dec 4, 2015, at 21:06, David Miller wrote: >> From: Hannes Frederic Sowa >> Date: Fri, 04 Dec 2015 20:59:05 +0100 >> >> > Yes, I agree, I am totally with

Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload

From: Hannes Frederic Sowa Date: Fri, 04 Dec 2015 20:59:05 +0100 > Yes, I agree, I am totally with you here. If generic offloading can be > realized by NICs I am totally with you that this should be the way to > go. I don't see that coming in the next (small number

Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload

On Fri, Dec 4, 2015 at 12:06 PM, David Miller wrote: > From: Hannes Frederic Sowa > Date: Fri, 04 Dec 2015 20:59:05 +0100 > >> Yes, I agree, I am totally with you here. If generic offloading can be >> realized by NICs I am totally with you that

Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload

On Fri, Dec 4, 2015 at 12:06 PM, David Miller wrote: > From: Hannes Frederic Sowa > Date: Fri, 04 Dec 2015 20:59:05 +0100 > >> Yes, I agree, I am totally with you here. If generic offloading can be >> realized by NICs I am totally with you that

Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload

> I actually tried to push the generic checksum idea for fm10k back > during hardware development but ended up losing that battle. The > problem is you have to have some customer willing to spend the cash in > order to get a feature, and the fact is nobody other than Tom has been > pushing for

Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload

From: Alexander Duyck Date: Fri, 4 Dec 2015 14:44:00 -0800 > I actually tried to push the generic checksum idea for fm10k back > during hardware development but ended up losing that battle. This chips already have a circuit calculating the 1's complement sum over the

Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload

On 12/04/2015 04:53 PM, Tom Herbert wrote: I actually tried to push the generic checksum idea for fm10k back during hardware development but ended up losing that battle. The problem is you have to have some customer willing to spend the cash in order to get a feature, and the fact is nobody

Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload

On Fri, Dec 4, 2015 at 8:50 PM, David Miller wrote: > From: Alexander Duyck > Date: Fri, 4 Dec 2015 14:44:00 -0800 > >> I actually tried to push the generic checksum idea for fm10k back >> during hardware development but ended up losing that

Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload

From: Alexander Duyck Date: Fri, 4 Dec 2015 21:45:09 -0800 > Not having this feature has to in some way impact sales. I'm glad money trumps clean design and performance these days. Would they ship a literal turd until some customer asked for something better? You

Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload

> I do know that, but fact is, the current drivers do it. I am concerned > about the amount of entropy in one single 16 bit field used to > distinguish flows. Flow labels fine and good, but if current hardware > does not support it, it does not help. Imagine containers with lots of > applications,

Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload

On Thu, Dec 3, 2015, at 17:35, Andreas Schultz wrote: > On 12/03/2015 04:59 PM, Hannes Frederic Sowa wrote: > > Hi Tom, > > > > On Wed, Dec 2, 2015, at 20:15, Tom Herbert wrote: > >> On Wed, Dec 2, 2015 at 8:35 AM, Hannes Frederic Sowa > >> wrote: > >>> On Wed, Dec 2,

Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload

On 12/03/2015 04:59 PM, Hannes Frederic Sowa wrote: Hi Tom, On Wed, Dec 2, 2015, at 20:15, Tom Herbert wrote: On Wed, Dec 2, 2015 at 8:35 AM, Hannes Frederic Sowa wrote: On Wed, Dec 2, 2015, at 04:50, Tom Herbert wrote: That completely misses the whole point of

Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload

Hi Tom, On Wed, Dec 2, 2015, at 20:15, Tom Herbert wrote: > On Wed, Dec 2, 2015 at 8:35 AM, Hannes Frederic Sowa > wrote: > > On Wed, Dec 2, 2015, at 04:50, Tom Herbert wrote: > >> That completely misses the whole point of the rest of this thread. > >> Protocol

Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload

On Wed, Dec 2, 2015, at 04:50, Tom Herbert wrote: > On Tue, Dec 1, 2015 at 7:49 AM, Hannes Frederic Sowa > wrote: > > On Tue, Dec 1, 2015, at 16:44, John W. Linville wrote: > >> On Mon, Nov 30, 2015 at 09:26:51PM -0800, Tom Herbert wrote: > >> > On Mon, Nov 30, 2015 at

Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload

On Wed, Dec 2, 2015 at 8:35 AM, Hannes Frederic Sowa wrote: > On Wed, Dec 2, 2015, at 04:50, Tom Herbert wrote: >> On Tue, Dec 1, 2015 at 7:49 AM, Hannes Frederic Sowa >> wrote: >> > On Tue, Dec 1, 2015, at 16:44, John W. Linville wrote: >>

Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload

[...] >> >> I wonder why we need protocol generic offloads? I know there are >> currently a lot of overlay encapsulation protocols. Are there many more >> coming? >> > Yes, and assume that there are more coming with an unbounded limit > (for instance I just noticed today that there is a netdev1.1

Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload

On Wed, Dec 2, 2015 at 3:35 PM, John Fastabend wrote: > [...] > >>> >>> I wonder why we need protocol generic offloads? I know there are >>> currently a lot of overlay encapsulation protocols. Are there many more >>> coming? >>> >> Yes, and assume that there are more

Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload

On Wed, Dec 02, 2015 at 03:35:53PM -0800, John Fastabend wrote: > [...] > > BPF. Implementing protocol generic offloads are not just a HW concern > > either, adding kernel GRO code for every possible protocol that comes > > along doesn't scale well. This becomes especially obvious when we > >

Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload

On 12/1/2015 8:08 AM, John W. Linville wrote: On Tue, Dec 01, 2015 at 04:49:28PM +0100, Hannes Frederic Sowa wrote: On Tue, Dec 1, 2015, at 16:44, John W. Linville wrote: On Mon, Nov 30, 2015 at 09:26:51PM -0800, Tom Herbert wrote: On Mon, Nov 30, 2015 at 5:28 PM, Jesse Gross

Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload

On Tue, Dec 1, 2015 at 7:49 AM, Hannes Frederic Sowa wrote: > On Tue, Dec 1, 2015, at 16:44, John W. Linville wrote: >> On Mon, Nov 30, 2015 at 09:26:51PM -0800, Tom Herbert wrote: >> > On Mon, Nov 30, 2015 at 5:28 PM, Jesse Gross wrote: >> >> > >

Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload

On Mon, Nov 30, 2015 at 09:26:51PM -0800, Tom Herbert wrote: > On Mon, Nov 30, 2015 at 5:28 PM, Jesse Gross wrote: > > Based on what we can do today, I see only two real choices: do some > > refactoring to clean up the stack a bit or remove the existing VXLAN > > offloading

Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload

On Tue, Dec 1, 2015, at 16:44, John W. Linville wrote: > On Mon, Nov 30, 2015 at 09:26:51PM -0800, Tom Herbert wrote: > > On Mon, Nov 30, 2015 at 5:28 PM, Jesse Gross wrote: > > > > Based on what we can do today, I see only two real choices: do some > > > refactoring to clean

Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload

On Tue, Dec 01, 2015 at 04:49:28PM +0100, Hannes Frederic Sowa wrote: > On Tue, Dec 1, 2015, at 16:44, John W. Linville wrote: > > On Mon, Nov 30, 2015 at 09:26:51PM -0800, Tom Herbert wrote: > > > On Mon, Nov 30, 2015 at 5:28 PM, Jesse Gross wrote: > > > > > > Based on what we

Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload

brandeb...@intel.com>; Singhai, Anjali > <anjali.sing...@intel.com>; je...@kernel.org; netdev@vger.kernel.org; Patil, > Kiran <kiran.pa...@intel.com> > Subject: Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload > > From: Tom Herbert <t...@herbertland.co

RE: [PATCH v1 1/6] net: Generalize udp based tunnel offload

PATCH v1 1/6] net: Generalize udp based tunnel offload From: Tom Herbert <t...@herbertland.com> Date: Mon, 23 Nov 2015 13:53:44 -0800 > The bad effect of this model is that it is encourages HW vendors to > continue implement HW protocol specific support for encapsulations, we &g

RE: [PATCH v1 1/6] net: Generalize udp based tunnel offload

atil, Kiran <kiran.pa...@intel.com> Subject: Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload From: Tom Herbert <t...@herbertland.com> Date: Tue, 24 Nov 2015 09:32:11 -0800 >> >> FWIW, I've brought the issue to the attention of the architects here, >>

RE: [PATCH v1 1/6] net: Generalize udp based tunnel offload

kiran.pa...@intel.com> Subject: Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload On Mon, Nov 23, 2015 at 1:02 PM, Anjali Singhai Jain <anjali.sing...@intel.com> wrote: > Replace add/del ndo ops for vxlan_port with tunnel_port so that all > UDP based tunnels can use the

Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload

On Mon, Nov 23, 2015 at 1:02 PM, Anjali Singhai Jain wrote: > Replace add/del ndo ops for vxlan_port with tunnel_port so that all UDP > based tunnels can use the same ndo op. Add a parameter to pass tunnel > type to the ndo_op. > Please consider using RX ntuple filters

Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload

On Sun, Nov 29, 2015 at 7:21 PM, David Miller wrote: > From: Tom Herbert > Date: Mon, 23 Nov 2015 13:53:44 -0800 > >> The bad effect of this model is that it is encourages HW vendors to >> continue implement HW protocol specific support for

Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload

From: "Singhai, Anjali" Date: Mon, 30 Nov 2015 21:42:37 + > The reason for receive being different than transmit is, on TX side > driver can provide the meta data for where the checksum field is and > what is the length that needs to be check summed to the HW on a

Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload

On Mon, Nov 30, 2015 at 5:02 PM, Tom Herbert wrote: > On Mon, Nov 30, 2015 at 4:25 PM, Jesse Gross wrote: >> On Sun, Nov 29, 2015 at 7:21 PM, David Miller wrote: >>> From: Tom Herbert >>> Date: Mon, 23 Nov 2015

Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload

Please learn how to properly quote people and respond to list postings. The material from Tom you are quoting looks like it is something you are writing. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info

Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload

On Mon, Nov 30, 2015 at 4:25 PM, Jesse Gross wrote: > On Sun, Nov 29, 2015 at 7:21 PM, David Miller wrote: >> From: Tom Herbert >> Date: Mon, 23 Nov 2015 13:53:44 -0800 >> >>> The bad effect of this model is that it is encourages HW

Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload

On Mon, Nov 30, 2015 at 5:28 PM, Jesse Gross wrote: > On Mon, Nov 30, 2015 at 5:02 PM, Tom Herbert wrote: >> On Mon, Nov 30, 2015 at 4:25 PM, Jesse Gross wrote: >>> On Sun, Nov 29, 2015 at 7:21 PM, David Miller

Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload

From: Tom Herbert Date: Mon, 30 Nov 2015 13:48:36 -0800 > Please look at how CHECKSUM_COMPLETE interface works. Description is > in sk_buff.h or > http://people.netfilter.org/pablo/netdev0.1/papers/UDP-Encapsulation-in-Linux.pdf. +1 -- To unsubscribe from this list: send

Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload

On Mon, Nov 30, 2015 at 7:48 PM, David Miller wrote: > From: "Singhai, Anjali" > Date: Mon, 30 Nov 2015 21:42:37 + > >> The reason for receive being different than transmit is, on TX side >> driver can provide the meta data for where the

Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload

From: Tom Herbert Date: Tue, 24 Nov 2015 09:32:11 -0800 >> >> FWIW, I've brought the issue to the attention of the architects here, >> and we will likely be able to make changes in this space. Intel >> hardware (as demonstrated by your patches) already is able to deal with

Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload

From: Tom Herbert Date: Mon, 23 Nov 2015 13:53:44 -0800 > The bad effect of this model is that it is encourages HW vendors to > continue implement HW protocol specific support for encapsulations, we > get so much more benefit if they implement protocol generic > mechanisms.

Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload

> > FWIW, I've brought the issue to the attention of the architects here, > and we will likely be able to make changes in this space. Intel > hardware (as demonstrated by your patches) already is able to deal with > this de-ossification on transmit. Receive is a whole different beast. > Please

Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload

On Tue, Nov 24, 2015, at 18:32, Tom Herbert wrote: > As you said this in only feedback and nobody is forcing anyone to do > anything. But encouraging HW vendors to provide generic mechanisms so > that your users can use whatever protocol they want is the exact > _opposite_ of punishing users, this

Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload

On Tue, Nov 24, 2015 at 9:43 AM, Hannes Frederic Sowa wrote: > On Tue, Nov 24, 2015, at 18:32, Tom Herbert wrote: >> As you said this in only feedback and nobody is forcing anyone to do >> anything. But encouraging HW vendors to provide generic mechanisms so >> that

Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload

On Tue, Nov 24, 2015, at 18:52, Tom Herbert wrote: > On Tue, Nov 24, 2015 at 9:43 AM, Hannes Frederic Sowa > wrote: > > On Tue, Nov 24, 2015, at 18:32, Tom Herbert wrote: > >> As you said this in only feedback and nobody is forcing anyone to do > >> anything. But

Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload

From: Hannes Frederic Sowa Date: Tue, 24 Nov 2015 18:43:35 +0100 > On Tue, Nov 24, 2015, at 18:32, Tom Herbert wrote: >> As you said this in only feedback and nobody is forcing anyone to do >> anything. But encouraging HW vendors to provide generic mechanisms so >>

Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload

On Tue, Nov 24, 2015, at 19:37, David Miller wrote: > From: Hannes Frederic Sowa > Date: Tue, 24 Nov 2015 18:43:35 +0100 > > > On Tue, Nov 24, 2015, at 18:32, Tom Herbert wrote: > >> As you said this in only feedback and nobody is forcing anyone to do > >> anything.

Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload

On Tue, Nov 24, 2015 at 10:37 AM, David Miller wrote: > From: Hannes Frederic Sowa > Date: Tue, 24 Nov 2015 18:43:35 +0100 > >> On Tue, Nov 24, 2015, at 18:32, Tom Herbert wrote: >>> As you said this in only feedback and nobody is forcing anyone

Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload

On Mon, Nov 23, 2015 at 1:53 PM, Tom Herbert wrote: >> diff --git a/include/net/udp_tunnel.h b/include/net/udp_tunnel.h >> index cb2f89f..72415aa 100644 >> --- a/include/net/udp_tunnel.h >> +++ b/include/net/udp_tunnel.h >> @@ -9,6 +9,12 @@ >> #include >> #endif >> >>

Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload

> diff --git a/include/net/udp_tunnel.h b/include/net/udp_tunnel.h > index cb2f89f..72415aa 100644 > --- a/include/net/udp_tunnel.h > +++ b/include/net/udp_tunnel.h > @@ -9,6 +9,12 @@ > #include > #endif > > +enum udp_tunnel_type { > + UDP_TUNNEL_UNSPEC, > + UDP_TUNNEL_VXLAN, > +

Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload

On 11/23/2015 01:02 PM, Anjali Singhai Jain wrote: Replace add/del ndo ops for vxlan_port with tunnel_port so that all UDP based tunnels can use the same ndo op. Add a parameter to pass tunnel type to the ndo_op. Change all drivers to use the generalized udp tunnel offload Patch was compile

Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload

ux Kernel Network Developers; Patil, Kiran >> Subject: Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload >> >> On Mon, Nov 23, 2015 at 1:53 PM, Tom Herbert <t...@herbertland.com> >> wrote: >> >> diff --git a/include/net/udp_tunnel.h b/include/net/u

RE: [PATCH v1 1/6] net: Generalize udp based tunnel offload

> -Original Message- > From: Jesse Gross [mailto:je...@kernel.org] > Sent: Monday, November 23, 2015 2:50 PM > To: Tom Herbert > Cc: Singhai, Anjali; Linux Kernel Network Developers; Patil, Kiran > Subject: Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload &

Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload

On Mon, 23 Nov 2015 16:38:59 -0800 Tom Herbert wrote: > >> > > >> > Sorry, I still don't like this. Grant it least it gets rid of of VXLAN > >> > specific ops, but the problem is there no such things as a common set > >> > of encapsulations in the kernel (e.g. foo-over-udp

Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload

Hi Anjali, [auto build test ERROR on net/master] [also build test ERROR on v4.4-rc2 next-20151123] url: https://github.com/0day-ci/linux/commits/Anjali-Singhai-Jain/Generalize-udp-based-tunnels-and-add-geneve-offload/20151124-044959 config: i386-randconfig-x006-11230317 (attached as .config)

Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload

Hi Anjali, [auto build test ERROR on net/master] [also build test ERROR on v4.4-rc2 next-20151123] url: https://github.com/0day-ci/linux/commits/Anjali-Singhai-Jain/Generalize-udp-based-tunnels-and-add-geneve-offload/20151124-044959 config: x86_64-randconfig-x001-11230704 (attached as