handing cloned frames to netif_rx()?

handing cloned frames to netif_rx()?

[Johannes Berg]

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

In 802.11n, there is a case where multiple data frames are received
aggregated into a single frame (A-MSDU).

Currently, we copy each of these frames out into their own skb, but
because of the alignment with that etc. I started to think that we could
simply pass up a clone of the original skb with start/length adjusted
properly so that it windows only the contained packet.

The buffer would be shared but the data within the original window
(starting with the 802.3 header) could even be written to, it won't be
needed again by mac80211 once it's handed off to netif_rx(). The skb
will obviously have lots of head- and tailroom but that space would be
part of other packets.

Is it ok to do this? Will something freak out if we pass a cloned skb to
netif_rx()?

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: handing cloned frames to netif_rx()?

[Herbert Xu]

Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> wrote:
>
> Is it ok to do this? Will something freak out if we pass a cloned skb to
> netif_rx()?

Sounds OK as long as you stick to the rules of cloned skb's, e.g., not
writing to them unless you've copied it.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: handing cloned frames to netif_rx()?

[Johannes Berg]

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


On Sat, 2008-01-12 at 09:31 +1100, Herbert Xu wrote:
> Johannes Berg <johannes@sipsolutions.net> wrote:
> >
> > Is it ok to do this? Will something freak out if we pass a cloned skb to
> > netif_rx()?
> 
> Sounds OK as long as you stick to the rules of cloned skb's, e.g., not
> writing to them unless you've copied it.

Ok. Yes, we will of course adhere to that, but I was wondering whether
maybe the net stack assumes somewhere that a packet it got from the
driver can be written to w/o copying.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: handing cloned frames to netif_rx()?

[Herbert Xu]

On Fri, Jan 11, 2008 at 11:58:05PM +0100, Johannes Berg wrote:
>
> Ok. Yes, we will of course adhere to that, but I was wondering whether
> maybe the net stack assumes somewhere that a packet it got from the
> driver can be written to w/o copying.

All parts of the rx stack support clone handling because they can always
run after another handler (e.g., AF_PACKET) which may have cloned the
packet.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: handing cloned frames to netif_rx()?

[Johannes Berg]

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


On Sat, 2008-01-12 at 10:01 +1100, Herbert Xu wrote:
> On Fri, Jan 11, 2008 at 11:58:05PM +0100, Johannes Berg wrote:
> >
> > Ok. Yes, we will of course adhere to that, but I was wondering whether
> > maybe the net stack assumes somewhere that a packet it got from the
> > driver can be written to w/o copying.
> 
> All parts of the rx stack support clone handling because they can always
> run after another handler (e.g., AF_PACKET) which may have cloned the
> packet.

Great, thanks for confirming, we'll do that then.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: handing cloned frames to netif_rx()?

[Tomas Winkler]

On Jan 11, 2008 3:17 AM, Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> wrote:
> In 802.11n, there is a case where multiple data frames are received
> aggregated into a single frame (A-MSDU).
>
> Currently, we copy each of these frames out into their own skb, but
> because of the alignment with that etc. I started to think that we could
> simply pass up a clone of the original skb with start/length adjusted
> properly so that it windows only the contained packet.
>
> The buffer would be shared but the data within the original window
> (starting with the 802.3 header) could even be written to, it won't be
> needed again by mac80211 once it's handed off to netif_rx(). The skb
> will obviously have lots of head- and tailroom but that space would be
> part of other packets.
>
> Is it ok to do this? Will something freak out if we pass a cloned skb to
> netif_rx()?
>
This would be great even in regular case. 4965 has ability to deliver
more frames per receiving buffer
Because of A-MSDU we keeps 8K receiving buffers which are
underutilized when A-MSDU is not used.

> johannes
>