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 invens
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 kernel and the hardw
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
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 language definition on top
> and in HW
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? Th
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
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 hardwa
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 argu
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 an
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 wou
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
coming?
>>> Yes, and ass
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 is matter what kind of swit
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 t
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 approach. I
don't know if the hard push back does anything but puni
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 users by
>>> delaying the time needed to find a reas
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 we are going to get the
> 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
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 eventually ends up being
>> some path forward I'll be good
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, though
> my preference woul
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 from blocking entirely.
Sorry. I had the mistaken
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 enabling UDP checksum, GR
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 noise
until I see the message
> 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
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.
>
> Would they ship a literal turd until some custom
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 battle.
>
> This chips already have a circuit calculati
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 have to be kidding me.
If it'
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 othe
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 data as is passed through th
> 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 thi
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 this should be the way to
>> go. I don't see that co
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 here. If generic offloading can be
>>> realized by NICs I am totally wi
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 Dec 2015 20:59:05 +0100
> >>
> >> > Yes, I agree, I am tota
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 you here. If generic offloading can be
>> > realized by NIC
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 you here. If generic offloading can be
>> > realized by NIC
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 be the way to
> > go. I don't
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 this should be the way to
>> go. I don't see that co
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 of) years, so I
> don't see a r
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 sp
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 it,
[...]
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 gene
> 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,
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 the rest of this thread.
Pro
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, 2015, at 04:50, Tom Herbert w
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 specific offloads are what we are t
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
> > consi
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 coming with an unbounded limit
[...]
>>
>> 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
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:
>> >> On Mon, Nov 30, 2015 at 09:26:51PM -0800, Tom Herbert
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 5:28 PM, Jesse Gross 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 5:28 PM, Jesse Gross wrote:
>>
>> > > Based on what we can do today, I see only two rea
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 wrote:
Based
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 can do today, I se
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 up the stack a bit o
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 altogether. I think th
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 checksum field is and
>> what is the length that needs
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 wrote:
From: Tom Herbert
Date: Mon, 23 Nov 2015 13:53:44 -0800
>
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
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 the line "unsubscribe ne
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 per
> packet basis. On Rx th
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 13:53:44 -0800
>>>
The bad effect of this model is that it is encourages HW ven
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 vendors to
>>> continue implement HW protocol specific support
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 encapsulations, we
>> get so much more benefit if they i
-Original Message-
From: Tom Herbert [mailto:t...@herbertland.com]
Sent: Monday, November 30, 2015 8:36 AM
To: Singhai, Anjali
Cc: Linux Kernel Network Developers ; Jesse Gross
; Patil, Kiran
Subject: Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload
On Mon, Nov 23, 2015
; netdev@vger.kernel.org; Patil,
> Kiran
> Subject: 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,
>
-Original Message-
From: David Miller [mailto:da...@davemloft.net]
Sent: Sunday, November 29, 2015 7:23 PM
To: t...@herbertland.com
Cc: Brandeburg, Jesse ; Singhai, Anjali
; je...@kernel.org; netdev@vger.kernel.org; Patil,
Kiran
Subject: Re: [PATCH v1 1/6] net: Generalize udp based
-Original Message-
From: David Miller [mailto:da...@davemloft.net]
Sent: Sunday, November 29, 2015 7:22 PM
To: t...@herbertland.com
Cc: Singhai, Anjali ; netdev@vger.kernel.org;
je...@kernel.org; Patil, Kiran
Subject: Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload
From
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 for this instead of a new nd
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
>> this de-ossificatio
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.
+1
--
To unsubscribe
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 to do
>>> anything. But encouraging HW vendors to p
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. But encouraging HW vendors to
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
>> that your users can use whateve
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 encouraging HW vendors to provid
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 your users can use whatever pro
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
>
> 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 pr
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 tes
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 adds a bunch of
> >> > e
l, Kiran
>> Subject: 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
>
> -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
&
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
>>
>> +enum udp_tunnel_type {
>>
> 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,
> +
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)
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 .config
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 tested with x86_64_defconfig.
Signed-off-by: Kiran Pati
85 matches
Mail list logo
