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
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
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
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
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
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
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
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:
>>
>>
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
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
>>> 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
>>
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
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
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
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
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
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
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
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.
>>
>>
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
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
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
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
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
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
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
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
> 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
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.
>>
>>
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
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
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?
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
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
>
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:
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
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
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
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
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
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
41 matches
Mail list logo