netdev - Re: can we reuse an skb

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 19 Jun 2009 14:41:14 -0400
From:	Neil Horman <nhorman@...driver.com>
To:	Saikiran Madugula <hummerbliss@...il.com>
Cc:	Radha Mohan <radhamohan_ch@...oo.com>, netdev@...r.kernel.org
Subject: Re: can we reuse an skb

On Fri, Jun 19, 2009 at 11:37:37AM +0100, Saikiran Madugula wrote:
> Radha Mohan wrote:
> > Hi,
> > 
> > For an ethernet driver, we need to allocate some pool of SKBs for receiving packets. Is there any way we can reuse the same SKBs without the need to re-allocate in atomic every time one has been used up for netif_rx(). 
> > 
> > Any pointers will be helpful.
> http://kerneltrap.org/mailarchive/linux-netdev/2008/9/28/3433504
Thats usefull on the transmit side, This appears to be in relation to receive
side buffering.

The answer to the question I think is, yes, you probably could come up with some
method to recycle skb's on the recieve side, but in all honesty, you're not
likely to come up with a solution that doesn't kill your performance.  If you
want to recycle the same skbs to your hardware, you either have to detect when
an application has received that data at the top of the stack, or you have to
copy the data out of the skb you just got from your hardware, so you can reuse
it immediately.  Theres not much point in doing the latter, as it doesn't avoid
the skb allocation your trying to not make.  The former is technically feasible,
but it requires your driver to wait an indefinate amount of time while an
application (or applications, if you consider the multicast case) all get on the
scheduler and receive from their open sockets, so theres no easy way to size
your receive ring, and if you run out, you have to drop frames until someone
releases an skb to you.

Its far easier, and more efficient to just allocate a new skb, and insert that
your hardwares ring buffer.  And its really not that expensive considering the
caching effect that our various allocators have
Neil

> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html