Re: [PATCH] Gigabit Ethernet driver of Topcliff PCH

From: Eric Dumazet
Date: Thu Sep 02 2010 - 09:41:00 EST


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 linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/