netdev - Re: Single packet receiving in multiple ring buffers

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] [day] [month] [year] [list]

Message-ID: <20080523120041.GA16850@2ka.mipt.ru>
Date:	Fri, 23 May 2008 16:00:41 +0400
From:	Evgeniy Polyakov <johnpol@....mipt.ru>
To:	David Miller <davem@...emloft.net>
Cc:	kchudgar@...c.com, kchudgar.linux@...il.com, netdev@...r.kernel.org
Subject: Re: Single packet receiving in multiple ring buffers

On Thu, May 22, 2008 at 11:57:55AM -0700, David Miller (davem@...emloft.net) wrote:
> > You have to copy part of the data (up to and including transport headers)
> > into skb->data.
> 
> You don't necessarily have to.  The input paths of the networking
> stack will pull into the skb->data, as needed, using
> pskb_may_pull() calls.
> 
> I did some tests with the NIU driver on receive, and to be
> honest there was nearly zero performance gain from pre-copying
> into skb->data from the paged SKB area preemptively before
> passing the packet in via netif_receive_skb().

Well, yes, essentially there should not be major difference who will
copy that bits into skb->data when/if needed, although MAC header has
to be there oterwise eth_type_trans() will not work, it does plain
skb_pull(). If eth_type_trans() is not used (there is some way to know
protocol number) things should be ok without copy (?)

So, from perfomance viewpoint it looks like the best decision is to
have first part of the packet in skb->data and the rest in attached
pages.

-- 
	Evgeniy Polyakov
--
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