NETdev driver question xxxx_type_trans()

NETdev driver question xxxx_type_trans()

[Russell McGuire]

[-- Attachment #1: Type: text/plain, Size: 949 bytes --]

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?

-Russ


[-- Attachment #2: Type: text/html, Size: 7130 bytes --]

Re: NETdev driver question xxxx_type_trans()

[Andy Fleming]

On Feb 22, 2008, at 14:26, Russell McGuire wrote:

> All,
>
> A general and specific question on the behavior of netdev devices =20
> before received sk_buff(s) get passed up to the kernel.
>
> I am almost done creating / testing an HDLC device driver for the =20
> 83xx.
>
>
> I have it working at a low level and was printing out skb_bufs =20
> before and after TX and RX, to ensure data integrity.
>
> Due to me having the print_skbbuf, AFTER the hdlc_type_trans(skb, =20
> ndev).
>
> I thought I was continuously losing 14 bytes of data, after a =20
> 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 =20
> before it sends it down?
>
> And why isn=92t the data length being shortened as a result after I =20=

> call hdlc_type_trans?
>
> Anyway=85 I guess I am confused as to what this function was intended =20=

> for, I see there are other calls for eth_type_trans, so I imagine =20
> their usage is similar.
>
> When are they needed?
>


They move the data pointer to point to the start of the L2 header.  =20
There's no need for the kernel to see the L1 header, and it doesn't =20
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 =20
kernel takes care of setting up the L1 header, though I'm not =20
familiar with the kernel's hdlc support.

Andy=

RE: NETdev driver question xxxx_type_trans()

[Russell McGuire]

Andy,

Thanks... I only have the hdlc_type_trans, on the RX side of the equation.

I want the driver to be able to support two modes, so not sure if I am going
to have to put an ioctl switch into to turn this on / off. 

Mode 1) I want the driver to be able to simulate an Ethernet device, which I
assume will need to use the hdlc_type_trans(), to remove layer 2.

Mode 2) I want the driver to be able to support fully RAW mode, but then
again, perhaps the hdlc_type_trans() knows this already depending on what
mode I am setup in, via 'sethdlc' ???

At the moment before I am able to use the device, I have to configure it via

'sethdlc hdlc0 hdlc-eth' or similar. <-- that previous call I assuming links
it to the TCP/IP stack as I can assign IP addresses with 
"ifconfig hdlc0 up 192.168.1.100".

However, for true P2P support, I was wanting to be able to open the device
directly and manage everything directly at the application level, i.e. the
only protocol would be "Application Layer->HDLC" and nothing in between.

In that case, I was concerned that any removal of Layer 2 stuff, simply
would be unnecessary as the 83xx already pulls the HDLC layer stuff off,
before I get the sk_buff. <Using the MCC Engine to a TDM<T1> port>.

So not sure if the kernel will let me... But that is one of my goals.

-Russ
> -----Original Message-----
> From: Andy Fleming [mailto:afleming@freescale.com]
> Sent: Friday, February 22, 2008 12:39 PM
> To: rmcguire@videopresence.com
> Cc: linuxppc-embedded@ozlabs.org
> Subject: Re: NETdev driver question xxxx_type_trans()
> 
> 
> 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