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 pointe
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 a
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
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
s
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 T
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:
>>
>> udp tx:976 MB/s 695394 c
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 withou
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 is
supported.
>>>
>>> I hadn'
>>> 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
>> expo
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
Date: Wed, 18 Apr 2018 08:31:03 -0400
However, I share Srid
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 Apr 2018 08:31:03 -0400
>>>
However, I share Sridhar's concerns about the
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 message boundary semantics here. There is actually
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
>>> Date: Wed, 18 Apr 2018 08:31:03 -0400
>>>
However, I share Sridhar's concerns about
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 ensures
> that its datagrams always fi
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 trying
> to grok it, but I fig
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 concerns about the very fundamental change
>>> to UDP message boundary semantics he
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.
>>
>> This patchset implements GSO for UDP.
>
> This looks g
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 actually no such thing
>> as a "segment" in udp, s
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 other emails, the interface looks good
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 does not matter what the behavior is
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 clue
> that they are both part
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 me a little
> uneasy. Well beh
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 borderline beneficial befor
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 system calls , one system call.
On
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 this can be
>> either a per-socket o
> 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 expli
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.
>>
>> One traversal of some expensi
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 traversal.
>>
>> This patchset implements GSO for
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 b
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? Wh
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 t
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
> submit multiple datag
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:
Assuming IPv4 with an MTU of 1500 and the maximum segment
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 MSS of
1472B, 528B and 512B.
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 the recvmsg will also pass up 1
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 b
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 option SOL_UDP/UDP_SEGMENT wi
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 tim
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 setting socket option SO
41 matches
Mail list logo
