NETdev driver question xxxx_type_trans()
Andy Fleming
afleming at freescale.com
Sat Feb 23 07:39:07 EST 2008
On Feb 22, 2008, at 14:26, Russell McGuire wrote:
> All,
>
> A general and specific question on the behavior of netdev devices
> before received sk_buff(s) get passed up to the kernel.
>
> I am almost done creating / testing an HDLC device driver for the
> 83xx.
>
>
> I have it working at a low level and was printing out skb_bufs
> before and after TX and RX, to ensure data integrity.
>
> Due to me having the print_skbbuf, AFTER the hdlc_type_trans(skb,
> ndev).
>
> I thought I was continuously losing 14 bytes of data, after a
> little digging I realized that the hdlc_type_trans() call
>
> was shifting the skb->data pointer forward by 14 bytes. ????????
>
> Is this corresponding to a 14 byte pad that the kernel stack adds
> before it sends it down?
>
> And why isn’t the data length being shortened as a result after I
> call hdlc_type_trans?
>
> Anyway… I guess I am confused as to what this function was intended
> for, I see there are other calls for eth_type_trans, so I imagine
> their usage is similar.
>
> When are they needed?
>
They move the data pointer to point to the start of the L2 header.
There's no need for the kernel to see the L1 header, and it doesn't
expect it to be there when it looks at the skb.
You shouldn't be using it for TX packets. For TX, I believe the
kernel takes care of setting up the L1 header, though I'm not
familiar with the kernel's hdlc support.
Andy
More information about the Linuxppc-embedded
mailing list