Re: Initial thoughts on TXDP

2016-12-02 Thread Tom Herbert
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

Re: Initial thoughts on TXDP

2016-12-02 Thread Edward Cree
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

Re: Initial thoughts on TXDP

2016-12-02 Thread Jesper Dangaard Brouer
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 > >>

Re: Initial thoughts on TXDP

2016-12-02 Thread Jesper Dangaard Brouer
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

Re: Initial thoughts on TXDP

2016-12-01 Thread Rick Jones
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

Re: Initial thoughts on TXDP

2016-12-01 Thread Tom Herbert
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

Re: Initial thoughts on TXDP

2016-12-01 Thread Hannes Frederic Sowa
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

Re: Initial thoughts on TXDP

2016-12-01 Thread Hannes Frederic Sowa
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

Re: Initial thoughts on TXDP

2016-12-01 Thread Tom Herbert
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

Re: Initial thoughts on TXDP

2016-12-01 Thread Rick Jones
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

Re: Initial thoughts on TXDP

2016-12-01 Thread Tom Herbert
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

Re: Initial thoughts on TXDP

2016-12-01 Thread Tom Herbert
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

Re: Initial thoughts on TXDP

2016-12-01 Thread Sowmini Varadhan
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

Re: Initial thoughts on TXDP

2016-12-01 Thread Tom Herbert
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

Re: Initial thoughts on TXDP

2016-12-01 Thread Rick Jones
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

Re: Initial thoughts on TXDP

2016-12-01 Thread Tom Herbert
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

Re: Initial thoughts on TXDP

2016-12-01 Thread Sowmini Varadhan
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 >

Re: Initial thoughts on TXDP

2016-11-30 Thread Florian Westphal
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