On Jan 2, 2008 9:12 PM, Ivo van Doorn <ivdoorn@xxxxxxxxx> wrote:
> Hi,
>
> > Happy New Year!
>
> You too. :)
>
> > I was out since Saturday just before you sent your
> > message, sorry for the late reply.
> >
> > > header_size = ieee80211_get_hdrlen_from_skb(entry->skb);
> > > if (header_size % 4 == 2) {
> > > /*
> > > * Move entire frame 2 bytes to the front.
> > > */
> > > skb_push(entry->skb, 2);
> > > memmove(entry->skb->data, entry->skb->data + 2,
> > > entry->skb->len - 2);
> > > }
> >
> > That doesn't really look right, I'd think the skb will be two bytes too
> > long after this.
> For PCI drivers I could indeed optimize the code by making the memcpy
> perform the operation on the 4 byte aligned code. But for this I need
> to check what is better, RX directly into a skbuff and use memmove
> or RX into DMA and use memcpy to a skbuff.
> But for USB this is not possible, since it directly performs the RX into
> the skbuff already, so I either have to change that or perform memmove anyway.
>
> > If you absolutely can't get the hardware to do it and would otherwise do
> > DMA right into the skb we should try to evaluate the performance hit on
> > platforms where unaligned access *is* possible to be able to balance it
> > against the performance hit caused by the memmove(). Ultimately, though,
> > I value correctness on all platforms over performance on some, hence the
> > warning when unaligned packets are handed up to mac80211.
>
> Overall correctness sounds as the best solution to me too.
I see it now happening in iw4965
I didn't test the copy solution yet but in 11n rates I see as a show
stopper. All 11n packets are QoS packets.
I haven't encounter a problems in net stack yet so I think this
solution is a bit drastic.
Thanks
Tomas
Tomas
> Ivo
-
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
