On Fri, Dec 2, 2016 at 6:36 AM, Edward Cree wrote:
> On 01/12/16 23:46, Tom Herbert wrote:
>> The only time we
>> _really_ to allocate an skbuf is when we need to put the packet onto a
>> queue. All the other use cases are really just to pass a structure
>> containing a packet from function to fun
On 01/12/16 23:46, Tom Herbert wrote:
> The only time we
> _really_ to allocate an skbuf is when we need to put the packet onto a
> queue. All the other use cases are really just to pass a structure
> containing a packet from function to function. For that purpose we
> should be able to just pass a
On Thu, 1 Dec 2016 23:47:44 +0100
Hannes Frederic Sowa wrote:
> Side note:
>
> On 01.12.2016 20:51, Tom Herbert wrote:
> >> > E.g. "mini-skb": Even if we assume that this provides a speedup
> >> > (where does that come from? should make no difference if a 32 or
> >> > 320 byte buffer gets alloc
On Thu, 1 Dec 2016 11:51:42 -0800 Tom Herbert wrote:
> On Wed, Nov 30, 2016 at 6:44 PM, Florian Westphal wrote:
> > Tom Herbert wrote:
[...]
> >> - Call into TCP/IP stack with page data directly from driver-- no
> >> skbuff allocation or interface. This is essentially provided by the
> >> X
On 12/01/2016 02:12 PM, Tom Herbert wrote:
We have consider both request size and response side in RPC.
Presumably, something like a memcache server is most serving data as
opposed to reading it, we are looking to receiving much smaller
packets than being sent. Requests are going to be quite smal
On Thu, Dec 1, 2016 at 2:47 PM, Hannes Frederic Sowa
wrote:
> Side note:
>
> On 01.12.2016 20:51, Tom Herbert wrote:
>>> > E.g. "mini-skb": Even if we assume that this provides a speedup
>>> > (where does that come from? should make no difference if a 32 or
>>> > 320 byte buffer gets allocated).
On 01.12.2016 21:13, Sowmini Varadhan wrote:
> On (12/01/16 11:05), Tom Herbert wrote:
>>
>> Polling does not necessarily imply that networking monopolizes the CPU
>> except when the CPU is otherwise idle. Presumably the application
>> drives the polling when it is ready to receive work.
>
> I'm n
Side note:
On 01.12.2016 20:51, Tom Herbert wrote:
>> > E.g. "mini-skb": Even if we assume that this provides a speedup
>> > (where does that come from? should make no difference if a 32 or
>> > 320 byte buffer gets allocated).
>> >
> It's the zero'ing of three cache lines. I believe we talked ab
On Thu, Dec 1, 2016 at 1:47 PM, Rick Jones wrote:
> On 12/01/2016 12:18 PM, Tom Herbert wrote:
>>
>> On Thu, Dec 1, 2016 at 11:48 AM, Rick Jones wrote:
>>>
>>> Just how much per-packet path-length are you thinking will go away under
>>> the
>>> likes of TXDP? It is admittedly "just" netperf but
On 12/01/2016 12:18 PM, Tom Herbert wrote:
On Thu, Dec 1, 2016 at 11:48 AM, Rick Jones wrote:
Just how much per-packet path-length are you thinking will go away under the
likes of TXDP? It is admittedly "just" netperf but losing TSO/GSO does some
non-trivial things to effective overhead (servi
On Thu, Dec 1, 2016 at 12:13 PM, Sowmini Varadhan
wrote:
> On (12/01/16 11:05), Tom Herbert wrote:
>>
>> Polling does not necessarily imply that networking monopolizes the CPU
>> except when the CPU is otherwise idle. Presumably the application
>> drives the polling when it is ready to receive wor
On Thu, Dec 1, 2016 at 11:48 AM, Rick Jones wrote:
> On 12/01/2016 11:05 AM, Tom Herbert wrote:
>>
>> For the GSO and GRO the rationale is that performing the extra SW
>> processing to do the offloads is significantly less expensive than
>> running each packet through the full stack. This is true
On (12/01/16 11:05), Tom Herbert wrote:
>
> Polling does not necessarily imply that networking monopolizes the CPU
> except when the CPU is otherwise idle. Presumably the application
> drives the polling when it is ready to receive work.
I'm not grokking that- "if the cpu is idle, we want to busy
On Wed, Nov 30, 2016 at 6:44 PM, Florian Westphal wrote:
> Tom Herbert wrote:
>> Posting for discussion
>
> Warning: You are not going to like this reply...
>
>> Now that XDP seems to be nicely gaining traction
>
> Yes, I regret to see that. XDP seems useful to create impressive
> benchmark
On 12/01/2016 11:05 AM, Tom Herbert wrote:
For the GSO and GRO the rationale is that performing the extra SW
processing to do the offloads is significantly less expensive than
running each packet through the full stack. This is true in a
multi-layered generalized stack. In TXDP, however, we shoul
On Thu, Dec 1, 2016 at 5:55 AM, Sowmini Varadhan
wrote:
> On (11/30/16 14:54), Tom Herbert wrote:
>>
>> Posting for discussion
>:
>> One simplifying assumption we might make is that TXDP is primarily for
>> optimizing latency, specifically request/response type operations
>> (think HPC, HF
On (11/30/16 14:54), Tom Herbert wrote:
>
> Posting for discussion
:
> One simplifying assumption we might make is that TXDP is primarily for
> optimizing latency, specifically request/response type operations
> (think HPC, HFT, flash server, or other tightly coupled communications
> within
Tom Herbert wrote:
> Posting for discussion
Warning: You are not going to like this reply...
> Now that XDP seems to be nicely gaining traction
Yes, I regret to see that. XDP seems useful to create impressive
benchmark numbers (and little else).
I will send a separate email to keep that f
Posting for discussion
Now that XDP seems to be nicely gaining traction we can start to
consider the next logical step which is to apply the principles of XDP
to accelerating transport protocols in the kernel. For lack of a
better name I'll refer to this as Transport eXpress Data Path, or just
19 matches
Mail list logo
