From: Eric Dumazet <eric.dumazet@gmail.com>
To: Grant Likely <grant.likely@secretlab.ca>
Cc: John Linn <John.Linn@xilinx.com>,
netdev@vger.kernel.org, linuxppc-dev@ozlabs.org,
jwboyer@linux.vnet.ibm.com, john.williams@petalogix.com,
michal.simek@petalogix.com, John Tyner <jtyner@cs.ucr.edu>
Subject: Re: [PATCH] [V3] Add non-Virtex5 support for LL TEMAC driver
Date: Tue, 06 Apr 2010 22:24:01 +0200 [thread overview]
Message-ID: <1270585441.2091.65.camel@edumazet-laptop> (raw)
In-Reply-To: <k2mfa686aa41004061153q3d065924o9172b1cf6038d917@mail.gmail.com>
Le mardi 06 avril 2010 à 12:53 -0600, Grant Likely a écrit :
> Hold on.... BUFFER_ALIGN is being used to align the DMA buffer on a
> cache line boundary. I don't think netdev_alloc_skb() makes any
> guarantees about how the start of the IP header lines up against cache
> line boundaries. The amount of padding needed is not known until an
> skbuff is obtained from netdev_alloc_skb(), and
> netdev_alloc_skb_ip_align() can only handle a fixed size padding,
>
> It doesn't look like netdev_alloc_skb_ip_align() is the right thing in
> this regard.
>
OK, time to have a long explanation :
netdev_alloc_skb_ip_align() is doing the right thing, but it seems you
guys insist to invent a new private stuff.
I am only wondering if you really know why you do this.
Many drivers do have same requirements, so every driver should reinvent
the wheel ? Really this is beyond me.
Original code was aligning the buffer on a 32 bytes boundary (because of
a hardware requirement on NIC, I only trust original code on this).
Then you want to change this to align buffer on this 32 bytes boundary
PLUS 2. What is this kind of new requirement ?
1) Hardware requirement really changed that much. (firmware changed on
NIC). If not using this new alignement, NIC doesnt work at all.
2) or Microblaze arch requires that IP header is aligned on a word
boundary to avoid unaligned traps in IP stack ? (like many arches)
If this is the latest requirement, then use standard mechanism.
skb data is naturally aligned on L1_CACHE_SIZE + SKB_PAD boundaries.
(32 bytes alignment)
netdev_alloc_skb_ip_align()() then skips 2 bytes to make skb data
aligned so that 2 + 14 (sizeof eth header) = 16 : IP header is aligned
(modulo 16)
It just works. If not, we should correct it, please fill a bug report.
Thanks
next prev parent reply other threads:[~2010-04-06 20:24 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-05 21:11 [PATCH] [V3] Add non-Virtex5 support for LL TEMAC driver John Linn
2010-04-05 21:29 ` Eric Dumazet
2010-04-05 21:33 ` John Linn
2010-04-06 15:08 ` Steven J. Magnani
2010-04-06 17:54 ` Grant Likely
2010-04-06 16:12 ` John Linn
2010-04-06 17:00 ` Eric Dumazet
2010-04-06 17:11 ` John Linn
2010-04-06 17:47 ` Eric Dumazet
2010-04-06 18:53 ` Grant Likely
2010-04-06 20:03 ` John Linn
2010-04-06 20:03 ` Steven J. Magnani
2010-04-06 20:12 ` John Linn
2010-04-06 20:24 ` Eric Dumazet [this message]
2010-04-06 20:32 ` John Linn
2010-04-07 2:52 ` David Miller
2010-04-07 13:25 ` John Linn
2010-04-07 13:31 ` Eric Dumazet
2010-04-06 0:08 ` Grant Likely
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1270585441.2091.65.camel@edumazet-laptop \
--to=eric.dumazet@gmail.com \
--cc=John.Linn@xilinx.com \
--cc=grant.likely@secretlab.ca \
--cc=john.williams@petalogix.com \
--cc=jtyner@cs.ucr.edu \
--cc=jwboyer@linux.vnet.ibm.com \
--cc=linuxppc-dev@ozlabs.org \
--cc=michal.simek@petalogix.com \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox