[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CALx6S367+xaF_aA4wUk6E5n-Tao0hebkef9LFJOEp4PdwLv1vw@mail.gmail.com>
Date: Fri, 2 Dec 2016 09:12:39 -0800
From: Tom Herbert <tom@...bertland.com>
To: Edward Cree <ecree@...arflare.com>
Cc: Hannes Frederic Sowa <hannes@...essinduktion.org>,
Florian Westphal <fw@...len.de>,
Linux Kernel Network Developers <netdev@...r.kernel.org>,
Jesper Dangaard Brouer <jbrouer@...hat.com>
Subject: Re: Initial thoughts on TXDP
On Fri, Dec 2, 2016 at 6:36 AM, Edward Cree <ecree@...arflare.com> 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 function. For that purpose we
>> should be able to just pass a much smaller structure in a stack
>> argument and only allocate an skbuff when we need to enqueue. In cases
>> where we don't ever queue a packet we might never need to allocate any
>> skbuff
> Now this intrigues me, because one of the objections to bundling (vs GRO)
> was the memory usage of all those SKBs. IIRC we already do a 'GRO-like'
> coalescing when packets reach a TCP socket anyway (or at least in some
> cases, not sure if all the different ways we can enqueue a TCP packet for
> RX do it), but if we could carry the packets from NIC to socket without
> SKBs, doing so in lists rather than one-at-a-time wouldn't cost any extra
> memory (the packet-pages are all already allocated on the NIC RX ring).
> Possibly combine the two, so that rather than having potentially four
> versions of each function (skb, skbundle, void*, void* bundle) you just
> have the two 'ends'.
>
Yep, seems like a good idea to incorporate bundling into TXDP from the get-go.
Tom
> -Ed
Powered by blists - more mailing lists