* ip_finish_outpu2 question
@ 2008-05-14 3:42 Prashanth
2008-05-14 4:34 ` David Miller
0 siblings, 1 reply; 6+ messages in thread
From: Prashanth @ 2008-05-14 3:42 UTC (permalink / raw)
To: netdev
hi, In the following function at line 189 , we are getting aligned
length (hh_alen) for the hardware header , but while doing a
skb_push() why are we using the hh->hh_len;for ethernet hh_alen would
be 16 , and hh->hh_len would be 14, since we are doing skb_push() with
14 (i.e hh->hh_len), the skb->data will not be aligned right? Can
someone please shed some light on this. thanks.
163 static inline int ip_finish_output2(struct sk_buff *skb)
164 {
165 struct dst_entry *dst = skb->dst;
166 struct hh_cache *hh = dst->hh;
167 struct net_device *dev = dst->dev;
168 int hh_len = LL_RESERVED_SPACE(dev);
169
170 /* Be paranoid, rather than too clever. */
171 if (unlikely(skb_headroom(skb) < hh_len && dev->hard_header)) {
172 struct sk_buff *skb2;
173
174 skb2 = skb_realloc_headroom(skb, LL_RESERVED_SPACE(dev));
175 if (skb2 == NULL) {
176 kfree_skb(skb);
177 return -ENOMEM;
178 }
179 if (skb->sk)
180 skb_set_owner_w(skb2, skb->sk);
181 kfree_skb(skb);
182 skb = skb2;
183 }
184
185 if (hh) {
186 int hh_alen;
187
188 read_lock_bh(&hh->hh_lock);
189 hh_alen = HH_DATA_ALIGN(hh->hh_len);
190 memcpy(skb->data - hh_alen, hh->hh_data, hh_alen);
191 read_unlock_bh(&hh->hh_lock);
192 skb_push(skb, hh->hh_len);
193 return hh->hh_output(skb);
194 } else if (dst->neighbour)
195 return dst->neighbour->output(skb);
196
197 if (net_ratelimit())
198 printk(KERN_DEBUG "ip_finish_output2: No header cache
and no neighbour!\n");
199 kfree_skb(skb);
200 return -EINVAL;
201 }
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: ip_finish_outpu2 question
2008-05-14 3:42 ip_finish_outpu2 question Prashanth
@ 2008-05-14 4:34 ` David Miller
2008-05-14 5:23 ` Prashanth
2008-05-14 8:47 ` kalash nainwal
0 siblings, 2 replies; 6+ messages in thread
From: David Miller @ 2008-05-14 4:34 UTC (permalink / raw)
To: bshanth; +Cc: netdev
From: Prashanth <bshanth@gmail.com>
Date: Wed, 14 May 2008 09:12:54 +0530
> hi, In the following function at line 189 , we are getting aligned
> length (hh_alen) for the hardware header , but while doing a
> skb_push() why are we using the hh->hh_len;for ethernet hh_alen would
> be 16 , and hh->hh_len would be 14, since we are doing skb_push() with
> 14 (i.e hh->hh_len), the skb->data will not be aligned right? Can
> someone please shed some light on this. thanks.
We are using 16 for the copy so that we do an aligned
copy. But the ethernet header size is only 14 bytes.
It's safe to copy those extra 2 bytes at the front
since we always will have some extra slack space there.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: ip_finish_outpu2 question
2008-05-14 4:34 ` David Miller
@ 2008-05-14 5:23 ` Prashanth
2008-05-14 5:46 ` David Miller
2008-05-14 8:47 ` kalash nainwal
1 sibling, 1 reply; 6+ messages in thread
From: Prashanth @ 2008-05-14 5:23 UTC (permalink / raw)
To: David Miller; +Cc: netdev
So skb->data will be pointing to an unaligned memory address; atleast
for the ethernet case which has 14 Bytes header length.
because of this my chip is not allowing to do DMA for unaligned memory address.
If we take the case of ethernet , The hh->hh_data will be pointing to
the ethernet header by leaving the first 2 bytes.
HH_DATA_OFF() macro is used for this purpose.
By doing skb_push() only for 14 bytes and making skb->data to point to
unaligned memory will have performance hit,
In my case i was not even able to xmit the packet.So is it not better
to do skb_push() for 16 bytes and make skb->data aligned?
In ip_finish_output2() function it's better to do skb_push() for
aligned length. And let others access the ethernet header
by adding HH_DATA_OFF() to it. Do we face any problems by doing this.
Please fix me if i'm wrong.
Thanks
On Wed, May 14, 2008 at 10:04 AM, David Miller <davem@davemloft.net> wrote:
> From: Prashanth <bshanth@gmail.com>
> Date: Wed, 14 May 2008 09:12:54 +0530
>
>> hi, In the following function at line 189 , we are getting aligned
>> length (hh_alen) for the hardware header , but while doing a
>> skb_push() why are we using the hh->hh_len;for ethernet hh_alen would
>> be 16 , and hh->hh_len would be 14, since we are doing skb_push() with
>> 14 (i.e hh->hh_len), the skb->data will not be aligned right? Can
>> someone please shed some light on this. thanks.
>
> We are using 16 for the copy so that we do an aligned
> copy. But the ethernet header size is only 14 bytes.
>
> It's safe to copy those extra 2 bytes at the front
> since we always will have some extra slack space there.
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: ip_finish_outpu2 question
2008-05-14 5:23 ` Prashanth
@ 2008-05-14 5:46 ` David Miller
0 siblings, 0 replies; 6+ messages in thread
From: David Miller @ 2008-05-14 5:46 UTC (permalink / raw)
To: bshanth; +Cc: netdev
From: Prashanth <bshanth@gmail.com>
Date: Wed, 14 May 2008 10:53:36 +0530
> So skb->data will be pointing to an unaligned memory address;
> atleast for the ethernet case which has 14 Bytes header length.
That's correct.
> because of this my chip is not allowing to do DMA for unaligned
> memory address.
Most chips have an "packet offset" parameter you can feed into the TX
descriptor, and you align the DMA address that is given to the
chip. This allows the chip to do an aligned DMA fetch yet still
be agnostic the the alignment of the packet given to it by the
networking stack.
> So is it not better
> to do skb_push() for 16 bytes and make skb->data aligned?
If we did that skb->data would point to the two garbage bytes
in front of the ethernet header.
> In ip_finish_output2() function it's better to do skb_push() for
> aligned length. And let others access the ethernet header by adding
> HH_DATA_OFF() to it. Do we face any problems by doing this.
No, that would punish good hardware which can handle arbitrary
TX packet alignment for the sake of bad hardware.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: ip_finish_outpu2 question
2008-05-14 4:34 ` David Miller
2008-05-14 5:23 ` Prashanth
@ 2008-05-14 8:47 ` kalash nainwal
2008-05-14 10:03 ` David Miller
1 sibling, 1 reply; 6+ messages in thread
From: kalash nainwal @ 2008-05-14 8:47 UTC (permalink / raw)
To: David Miller; +Cc: bshanth, netdev
On Wed, May 14, 2008 at 10:04 AM, David Miller <davem@davemloft.net> wrote:
> From: Prashanth <bshanth@gmail.com>
> Date: Wed, 14 May 2008 09:12:54 +0530
>
>> hi, In the following function at line 189 , we are getting aligned
>> length (hh_alen) for the hardware header , but while doing a
>> skb_push() why are we using the hh->hh_len;for ethernet hh_alen would
>> be 16 , and hh->hh_len would be 14, since we are doing skb_push() with
>> 14 (i.e hh->hh_len), the skb->data will not be aligned right? Can
>> someone please shed some light on this. thanks.
>
> We are using 16 for the copy so that we do an aligned
> copy. But the ethernet header size is only 14 bytes.
>
I thought memcpy in linux is anyway always alignment safe. no?
-Kalash
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: ip_finish_outpu2 question
2008-05-14 8:47 ` kalash nainwal
@ 2008-05-14 10:03 ` David Miller
0 siblings, 0 replies; 6+ messages in thread
From: David Miller @ 2008-05-14 10:03 UTC (permalink / raw)
To: kalash.nainwal; +Cc: bshanth, netdev
From: "kalash nainwal" <kalash.nainwal@gmail.com>
Date: Wed, 14 May 2008 14:17:58 +0530
> I thought memcpy in linux is anyway always alignment safe. no?
Yes, but an aligned copy is faster.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2008-05-14 10:03 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-05-14 3:42 ip_finish_outpu2 question Prashanth
2008-05-14 4:34 ` David Miller
2008-05-14 5:23 ` Prashanth
2008-05-14 5:46 ` David Miller
2008-05-14 8:47 ` kalash nainwal
2008-05-14 10:03 ` David Miller
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).