Re: [PATCH RFC net-next 00/11] udp gso

2018-09-03 Thread Sowmini Varadhan
On (09/03/18 10:02), Steffen Klassert wrote: > I'm working on patches that builds such skb lists. The list is chained > at the frag_list pointer of the first skb, all subsequent skbs are linked > to the next pointer of the skb. It looks like this: there are some risks to using the frag_list

Re: [PATCH RFC net-next 00/11] udp gso

2018-09-03 Thread Steffen Klassert
On Fri, Aug 31, 2018 at 09:08:59AM -0400, Willem de Bruijn wrote: > On Fri, Aug 31, 2018 at 5:09 AM Paolo Abeni wrote: > > > > Hi, > > > > On Tue, 2018-04-17 at 17:07 -0400, Willem de Bruijn wrote: > > > That said, for negotiated flows an inverse GRO feature could > > > conceivably be implemented

Re: [PATCH RFC net-next 00/11] udp gso

2018-08-31 Thread Willem de Bruijn
On Fri, Aug 31, 2018 at 9:44 AM Paolo Abeni wrote: > > On Fri, 2018-08-31 at 09:08 -0400, Willem de Bruijn wrote: > > On Fri, Aug 31, 2018 at 5:09 AM Paolo Abeni wrote: > > > > > > Hi, > > > > > > On Tue, 2018-04-17 at 17:07 -0400, Willem de Bruijn wrote: > > > > That said, for negotiated flows

Re: [PATCH RFC net-next 00/11] udp gso

2018-08-31 Thread Paolo Abeni
On Fri, 2018-08-31 at 09:08 -0400, Willem de Bruijn wrote: > On Fri, Aug 31, 2018 at 5:09 AM Paolo Abeni wrote: > > > > Hi, > > > > On Tue, 2018-04-17 at 17:07 -0400, Willem de Bruijn wrote: > > > That said, for negotiated flows an inverse GRO feature could > > > conceivably be implemented to

Re: [PATCH RFC net-next 00/11] udp gso

2018-08-31 Thread Willem de Bruijn
On Fri, Aug 31, 2018 at 5:09 AM Paolo Abeni wrote: > > Hi, > > On Tue, 2018-04-17 at 17:07 -0400, Willem de Bruijn wrote: > > That said, for negotiated flows an inverse GRO feature could > > conceivably be implemented to reduce rx stack traversal, too. > > Though due to interleaving of packets on

Re: [PATCH RFC net-next 00/11] udp gso

2018-08-31 Thread Eric Dumazet
On 08/31/2018 02:09 AM, Paolo Abeni wrote: > I hope quic can leverage such scenario, but I > really know nothing about the protocol. > Most QUIC receivers are mobile phones, laptops, with wifi without GRO anyway... Even if they had GRO, the inter-packet delay would be too high for GRO to be

Re: [PATCH RFC net-next 00/11] udp gso

2018-08-31 Thread Paolo Abeni
Hi, On Tue, 2018-04-17 at 17:07 -0400, Willem de Bruijn wrote: > That said, for negotiated flows an inverse GRO feature could > conceivably be implemented to reduce rx stack traversal, too. > Though due to interleaving of packets on the wire, it aggregation > would be best effort, similar to TCP

Re: [PATCH RFC net-next 00/11] udp gso

2018-05-23 Thread Willem de Bruijn
On Wed, May 23, 2018 at 8:02 PM, Marcelo Ricardo Leitner wrote: > On Wed, Apr 18, 2018 at 09:49:18AM -0400, Willem de Bruijn wrote: >> I just hacked up a sendmmsg extension to the benchmark to verify. >> Indeed that does not have nearly the same benefit as GSO: >> >>

Re: [PATCH RFC net-next 00/11] udp gso

2018-05-23 Thread Marcelo Ricardo Leitner
On Wed, Apr 18, 2018 at 09:49:18AM -0400, Willem de Bruijn wrote: > I just hacked up a sendmmsg extension to the benchmark to verify. > Indeed that does not have nearly the same benefit as GSO: > > udp tx:976 MB/s 695394 calls/s 16557 msg/s > > This matches the numbers seen from TCP

Re: [PATCH RFC net-next 00/11] udp gso

2018-04-20 Thread Alexander Duyck
On Fri, Apr 20, 2018 at 2:58 PM, Willem de Bruijn wrote: Also any plans for HW offload support for this? I vaguely recall that the igb and ixgbe parts had support for something like this in hardware. I would have to double check to see what exactly

Re: [PATCH RFC net-next 00/11] udp gso

2018-04-20 Thread Willem de Bruijn
>>> Also any plans for HW offload support for this? I vaguely recall that >>> the igb and ixgbe parts had support for something like this in >>> hardware. I would have to double check to see what exactly is >>> supported. >> >> I hadn't given that much thought until the request yesterday to >>

Re: [PATCH RFC net-next 00/11] udp gso

2018-04-20 Thread Tushar Dave
On 04/20/2018 01:08 PM, Alexander Duyck wrote: On Fri, Apr 20, 2018 at 11:27 AM, Tushar Dave wrote: On 04/18/2018 11:12 AM, Alexander Duyck wrote: On Wed, Apr 18, 2018 at 10:28 AM, David Miller wrote: From: Sowmini Varadhan

Re: [PATCH RFC net-next 00/11] udp gso

2018-04-20 Thread Alexander Duyck
On Fri, Apr 20, 2018 at 11:27 AM, Tushar Dave wrote: > > > On 04/18/2018 11:12 AM, Alexander Duyck wrote: >> >> On Wed, Apr 18, 2018 at 10:28 AM, David Miller >> wrote: >>> >>> From: Sowmini Varadhan >>> Date: Wed, 18

Re: [PATCH RFC net-next 00/11] udp gso

2018-04-20 Thread Tushar Dave
On 04/18/2018 11:12 AM, Alexander Duyck wrote: On Wed, Apr 18, 2018 at 10:28 AM, David Miller wrote: From: Sowmini Varadhan Date: Wed, 18 Apr 2018 08:31:03 -0400 However, I share Sridhar's concerns about the very fundamental change to UDP

Re: [PATCH RFC net-next 00/11] udp gso

2018-04-20 Thread Alexander Duyck
On Wed, Apr 18, 2018 at 11:22 AM, Willem de Bruijn wrote: > On Wed, Apr 18, 2018 at 2:12 PM, Alexander Duyck > wrote: >> On Wed, Apr 18, 2018 at 10:28 AM, David Miller wrote: >>> From: Sowmini Varadhan

Re: [PATCH RFC net-next 00/11] udp gso

2018-04-19 Thread David Miller
From: Willem de Bruijn Date: Wed, 18 Apr 2018 14:12:40 -0400 > Actually, yes, I should be able to relax that constraint with > segmentation. > > It is there in case a corked packet may grow to the point of > having to be fragmented. But segmentation already

Re: [PATCH RFC net-next 00/11] udp gso

2018-04-18 Thread David Miller
From: Alexander Duyck Date: Wed, 18 Apr 2018 11:12:06 -0700 > My only concern with the patch set is verifying what mitigations are > in case so that we aren't trying to set an MSS size that results in a > frame larger than MTU. I'm still digging through the code and

Re: [PATCH RFC net-next 00/11] udp gso

2018-04-18 Thread Willem de Bruijn
On Wed, Apr 18, 2018 at 2:12 PM, Alexander Duyck wrote: > On Wed, Apr 18, 2018 at 10:28 AM, David Miller wrote: >> From: Sowmini Varadhan >> Date: Wed, 18 Apr 2018 08:31:03 -0400 >> >>> However, I share Sridhar's

Re: [PATCH RFC net-next 00/11] udp gso

2018-04-18 Thread Willem de Bruijn
On Wed, Apr 18, 2018 at 1:50 PM, David Miller wrote: > From: Willem de Bruijn > Date: Tue, 17 Apr 2018 16:00:50 -0400 > >> Segmentation offload reduces cycles/byte for large packets by >> amortizing the cost of protocol stack traversal. >> >>

Re: [PATCH RFC net-next 00/11] udp gso

2018-04-18 Thread Alexander Duyck
On Wed, Apr 18, 2018 at 10:28 AM, David Miller wrote: > From: Sowmini Varadhan > Date: Wed, 18 Apr 2018 08:31:03 -0400 > >> However, I share Sridhar's concerns about the very fundamental change >> to UDP message boundary semantics here. There is

Re: [PATCH RFC net-next 00/11] udp gso

2018-04-18 Thread David Miller
From: Willem de Bruijn Date: Tue, 17 Apr 2018 16:00:50 -0400 > Segmentation offload reduces cycles/byte for large packets by > amortizing the cost of protocol stack traversal. > > This patchset implements GSO for UDP. This looks great. And as mentioned in

Re: [PATCH RFC net-next 00/11] udp gso

2018-04-18 Thread David Miller
From: Willem de Bruijn Date: Wed, 18 Apr 2018 09:51:50 -0400 > Eric is correct. If the application sets a segment size with UDP_SEGMENT > this is an instruction to the kernel to split the payload along that border > into > separate discrete datagrams. > > It

Re: [PATCH RFC net-next 00/11] udp gso

2018-04-18 Thread David Miller
From: Sowmini Varadhan Date: Wed, 18 Apr 2018 09:47:06 -0400 > - in the "GSO" proposal my 2000 bytes of data are sent as *two* > udp packets, each of them with a unique udp header, and uh_len set > to 1476 (for first) and 526 (for second). The receiver has no

Re: [PATCH RFC net-next 00/11] udp gso

2018-04-18 Thread David Miller
From: Sowmini Varadhan Date: Wed, 18 Apr 2018 08:31:03 -0400 > However, I share Sridhar's concerns about the very fundamental change > to UDP message boundary semantics here. There is actually no such thing > as a "segment" in udp, so in general this feature makes

Re: [PATCH RFC net-next 00/11] udp gso

2018-04-18 Thread David Miller
From: Paolo Abeni Date: Wed, 18 Apr 2018 13:17:54 +0200 > When testing with Spectre/Meltdown mitigation in places, I expect > that the most relevant part of the gain is due to the single syscall > per burst. I was going to say exactly this. Batching schemes that were

Re: [PATCH RFC net-next 00/11] udp gso

2018-04-18 Thread Samudrala, Sridhar
On 4/18/2018 6:51 AM, Willem de Bruijn wrote: On Wed, Apr 18, 2018 at 9:47 AM, Sowmini Varadhan wrote: On (04/18/18 06:35), Eric Dumazet wrote: There is no change at all. This will only be used as a mechanism to send X packets of same size. So instead of X

Re: [PATCH RFC net-next 00/11] udp gso

2018-04-18 Thread Willem de Bruijn
On Wed, Apr 18, 2018 at 9:59 AM, Willem de Bruijn wrote: >> One thing that was not clear to me about the API: shouldn't UDP_SEGMENT >> just be automatically determined in the stack from the pmtu? Whats >> the motivation for the socket option for this? also AIUI

Re: [PATCH RFC net-next 00/11] udp gso

2018-04-18 Thread Willem de Bruijn
> One thing that was not clear to me about the API: shouldn't UDP_SEGMENT > just be automatically determined in the stack from the pmtu? Whats > the motivation for the socket option for this? also AIUI this can be > either a per-socket or a per-packet option? I decided to let the application

Re: [PATCH RFC net-next 00/11] udp gso

2018-04-18 Thread Willem de Bruijn
On Wed, Apr 18, 2018 at 9:47 AM, Sowmini Varadhan wrote: > On (04/18/18 06:35), Eric Dumazet wrote: >> >> There is no change at all. >> >> This will only be used as a mechanism to send X packets of same size. >> >> So instead of X system calls , one system call. >> >>

Re: [PATCH RFC net-next 00/11] udp gso

2018-04-18 Thread Willem de Bruijn
On Wed, Apr 18, 2018 at 7:17 AM, Paolo Abeni wrote: > On Tue, 2018-04-17 at 16:00 -0400, Willem de Bruijn wrote: >> From: Willem de Bruijn >> >> Segmentation offload reduces cycles/byte for large packets by >> amortizing the cost of protocol stack

Re: [PATCH RFC net-next 00/11] udp gso

2018-04-18 Thread Sowmini Varadhan
On (04/18/18 06:35), Eric Dumazet wrote: > > There is no change at all. > > This will only be used as a mechanism to send X packets of same size. > > So instead of X system calls , one system call. > > One traversal of some expensive part of the host stack. > > The content on the wire should

Re: [PATCH RFC net-next 00/11] udp gso

2018-04-18 Thread Eric Dumazet
On 04/18/2018 05:31 AM, Sowmini Varadhan wrote: > > I went through the patch set and the code looks fine- it extends existing > infra for TCP/GSO to UDP. > > One thing that was not clear to me about the API: shouldn't UDP_SEGMENT > just be automatically determined in the stack from the pmtu?

Re: [PATCH RFC net-next 00/11] udp gso

2018-04-18 Thread Sowmini Varadhan
I went through the patch set and the code looks fine- it extends existing infra for TCP/GSO to UDP. One thing that was not clear to me about the API: shouldn't UDP_SEGMENT just be automatically determined in the stack from the pmtu? Whats the motivation for the socket option for this? also AIUI

Re: [PATCH RFC net-next 00/11] udp gso

2018-04-18 Thread Paolo Abeni
On Tue, 2018-04-17 at 16:00 -0400, Willem de Bruijn wrote: > From: Willem de Bruijn > > Segmentation offload reduces cycles/byte for large packets by > amortizing the cost of protocol stack traversal. > > This patchset implements GSO for UDP. A process can concatenate and >

Re: [PATCH RFC net-next 00/11] udp gso

2018-04-17 Thread Willem de Bruijn
On Tue, Apr 17, 2018 at 10:25 PM, Samudrala, Sridhar wrote: > > On 4/17/2018 2:07 PM, Willem de Bruijn wrote: >> >> On Tue, Apr 17, 2018 at 4:48 PM, Sowmini Varadhan >> wrote: >>> >>> On (04/17/18 16:23), Willem de Bruijn wrote:

Re: [PATCH RFC net-next 00/11] udp gso

2018-04-17 Thread Samudrala, Sridhar
On 4/17/2018 2:07 PM, Willem de Bruijn wrote: On Tue, Apr 17, 2018 at 4:48 PM, Sowmini Varadhan wrote: On (04/17/18 16:23), Willem de Bruijn wrote: Assuming IPv4 with an MTU of 1500 and the maximum segment size of 1472, the receiver will see three datagrams with

Re: [PATCH RFC net-next 00/11] udp gso

2018-04-17 Thread Willem de Bruijn
On Tue, Apr 17, 2018 at 4:48 PM, Sowmini Varadhan wrote: > On (04/17/18 16:23), Willem de Bruijn wrote: >> >> Assuming IPv4 with an MTU of 1500 and the maximum segment >> size of 1472, the receiver will see three datagrams with MSS of >> 1472B, 528B and 512B. > > so

Re: [PATCH RFC net-next 00/11] udp gso

2018-04-17 Thread Sowmini Varadhan
On (04/17/18 16:23), Willem de Bruijn wrote: > > Assuming IPv4 with an MTU of 1500 and the maximum segment > size of 1472, the receiver will see three datagrams with MSS of > 1472B, 528B and 512B. so the recvmsg will also pass up 1472, 526, 512, right? If yes, how will the recvmsg differentiate

Re: [PATCH RFC net-next 00/11] udp gso

2018-04-17 Thread Willem de Bruijn
On Tue, Apr 17, 2018 at 4:15 PM, Sowmini Varadhan wrote: > On (04/17/18 16:00), Willem de Bruijn wrote: >> >> This patchset implements GSO for UDP. A process can concatenate and >> submit multiple datagrams to the same destination in one send call >> by setting socket

Re: [PATCH RFC net-next 00/11] udp gso

2018-04-17 Thread Sowmini Varadhan
On (04/17/18 16:00), Willem de Bruijn wrote: > > This patchset implements GSO for UDP. A process can concatenate and > submit multiple datagrams to the same destination in one send call > by setting socket option SOL_UDP/UDP_SEGMENT with the segment size, > or passing an analogous cmsg at send

[PATCH RFC net-next 00/11] udp gso

2018-04-17 Thread Willem de Bruijn
From: Willem de Bruijn Segmentation offload reduces cycles/byte for large packets by amortizing the cost of protocol stack traversal. This patchset implements GSO for UDP. A process can concatenate and submit multiple datagrams to the same destination in one send call by