From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtpauth16.prod.mesa1.secureserver.net (smtpauth16.prod.mesa1.secureserver.net [64.202.165.22]) by ozlabs.org (Postfix) with SMTP id 5BDB3DE08D for ; Sat, 23 Feb 2008 07:27:39 +1100 (EST) From: "Russell McGuire" To: Subject: NETdev driver question xxxx_type_trans() Date: Fri, 22 Feb 2008 12:26:12 -0800 Message-ID: <000001c87591$2b5a8740$6405a8c0@absolut> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C8754E.1D374740" Reply-To: rmcguire@videopresence.com List-Id: Linux on Embedded PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C8754E.1D374740 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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 ------=_NextPart_000_0001_01C8754E.1D374740 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable NETdev driver question xxxx_type_trans()

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

------=_NextPart_000_0001_01C8754E.1D374740--