netdev - Re: [PATCH] Gigabit Ethernet driver of Topcliff PCH

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:	Thu, 02 Sep 2010 15:40:47 +0200
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Masayuki Ohtake <masa-korg@....okisemi.com>
Cc:	Stephen Hemminger <shemminger@...tta.com>,
	Sam Ravnborg <sam@...nborg.org>, Joe Perches <joe@...ches.com>,
	LKML <linux-kernel@...r.kernel.org>,
	ML netdev <netdev@...r.kernel.org>,
	Greg Rose <gregory.v.rose@...el.com>,
	Maxime Bizon <mbizon@...ebox.fr>,
	Kristoffer Glembo <kristoffer@...sler.com>,
	Ralf Baechle <ralf@...ux-mips.org>,
	John Linn <john.linn@...inx.com>,
	Randy Dunlap <randy.dunlap@...cle.com>,
	"David S. Miller" <davem@...emloft.net>,
	MeeGo <meego-dev@...go.com>, "Wang, Qi" <qi.wang@...el.com>,
	"Wang, Yong Y" <yong.y.wang@...el.com>,
	Andrew <andrew.chih.howe.khor@...el.com>,
	Intel OTC <joel.clark@...el.com>,
	"Foster, Margie" <margie.foster@...el.com>,
	Toshiharu Okada <okada533@....okisemi.com>,
	Tomoya Morinaga <morinaga526@....okisemi.com>,
	Takahiro Shimizu <shimizu394@....okisemi.com>
Subject: Re: [PATCH] Gigabit Ethernet driver of Topcliff PCH

Le jeudi 02 septembre 2010 à 21:39 +0900, Masayuki Ohtake a écrit :
> Hi Eric
> 
> Thank you for your comments.
> 
> > I find hard to believe this driver needs to copy all outgoing frames on
> > pre-allocated skbs.
> >
> > +       /* [Header:14][payload] ---> [Header:14][paddong:2][payload]    */
> > +       memcpy(tmp_skb->data, skb->data, ETH_HLEN);
> > +       tmp_skb->data[ETH_HLEN] = 0x00;
> > +       tmp_skb->data[ETH_HLEN + 1] = 0x00;
> > +       tmp_skb->len = skb->len;
> > +       memcpy(&tmp_skb->data[ETH_HLEN + 2], &skb->data[ETH_HLEN],
> > +              (skb->len - ETH_HLEN));
> > +       buffer_info->kernel_skb = skb;
> > +       skb = tmp_skb;
> >
> > Whats the deal here please ?
> 
> This processing depends on hardware specification.
> 
> At the time of transmission.
> Hardware accepts a packet in the following format.
>   [Header: 14octet] + [padding: 2octet] + [payload]
>   Also, it is necessary to align the head of a [Header: 14octet] at 64byte.
> 
> In my knowledge, SKB received by kernel are the following format.
>   [padding: 2octet] + [Header:14octet] + [payload]
>   Also, The head of [payload] has aligned at 16 byte.
> 
> So, it has adjusted with the format of hardware by a copy.

The two bytes padding can be handled by network stack, if you
force in your setup phase :
	dev->hard_header_len = ETH_HLEN + 2;

then, you can do a single memcpy:

memcpy(tmp_skb->data, skb->data, skb->len);

About the 64 byte alignement, it might be a bit more complex :)




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