iwlwifi and tx info in skb->cb

iwlwifi and tx info in skb->cb

[Johannes Berg]

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

Hi,

I was just trying to make iwlwifi work again with tx info in skb->cb,
but am running into something I don't understand:

What is a TFD, and why can it have multiple SKBs with a single tx
status? I'm referring to:

/* One for each TFD */
struct iwl3945_tx_info {
	struct ieee80211_tx_status status;
	struct sk_buff *skb[MAX_NUM_OF_TBS];
};

I would have expected something like this with 4965 that has aggregation
support (and aggregation is reported just once) but here? Confused.

johannes

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

Re: iwlwifi and tx info in skb->cb

[Tomas Winkler]

On Thu, May 8, 2008 at 1:01 AM, Johannes Berg <johannes@sipsolutions.net> wrote:
> Hi,
>
>  I was just trying to make iwlwifi work again with tx info in skb->cb,
>  but am running into something I don't understand:
>
>  What is a TFD, and why can it have multiple SKBs with a single tx
>  status? I'm referring to:

TFD stands for TX File Descriptor


>  /* One for each TFD */
>  struct iwl3945_tx_info {
>         struct ieee80211_tx_status status;
>         struct sk_buff *skb[MAX_NUM_OF_TBS];
>  };
>
>  I would have expected something like this with 4965 that has aggregation
>  support (and aggregation is reported just once) but here? Confused.

This is for scatter gather. Nothing to do with aggregation. If you get
fragmented frame you can send it out without linearizing in CPU. in
numer of TB - TX buffers (which is limitted bu MAX_NUM_OF_TBS)  But
I'm just over ever explaining :)


Thanks
Tomas

>  johannes
>

Re: iwlwifi and tx info in skb->cb

[Johannes Berg]

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


> >  What is a TFD, and why can it have multiple SKBs with a single tx
> >  status? I'm referring to:
> 
> TFD stands for TX File Descriptor

Huh, "file"?

Anyway,

> This is for scatter gather. Nothing to do with aggregation. If you get
> fragmented frame you can send it out without linearizing in CPU. in
> numer of TB - TX buffers (which is limitted bu MAX_NUM_OF_TBS)  But
> I'm just over ever explaining :)

We don't support that in mac80211 right now, why do you have that there?

johannes

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

Re: iwlwifi and tx info in skb->cb

[Tomas Winkler]

On Thu, May 8, 2008 at 2:30 AM, Johannes Berg <johannes@sipsolutions.net> wrote:
>
>  > >  What is a TFD, and why can it have multiple SKBs with a single tx
>  > >  status? I'm referring to:
>  >
>  > TFD stands for TX File Descriptor
>
>  Huh, "file"?
Sorry,. it's field.
>
>  Anyway,
>
>
>  > This is for scatter gather. Nothing to do with aggregation. If you get
>  > fragmented frame you can send it out without linearizing in CPU. in
>  > numer of TB - TX buffers (which is limitted bu MAX_NUM_OF_TBS)  But
>  > I'm just over ever explaining :)
>
>  We don't support that in mac80211 right now, why do you have that there?

Currently we actively use 2 of them. First for TX command second for
actual frame.  It would be even worth if we need to expand
each packet also for TX command.
Any how hope to make it work one day. There is significant performance
gain in using this at least in the other operating system.


Thanks
Tomas

Tomas

>  johannes
>

Re: iwlwifi and tx info in skb->cb

[Johannes Berg]

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


> >  > This is for scatter gather. Nothing to do with aggregation. If you get
> >  > fragmented frame you can send it out without linearizing in CPU. in
> >  > numer of TB - TX buffers (which is limitted bu MAX_NUM_OF_TBS)  But
> >  > I'm just over ever explaining :)
> >
> >  We don't support that in mac80211 right now, why do you have that there?
> 
> Currently we actively use 2 of them. First for TX command second for
> actual frame.  It would be even worth if we need to expand
> each packet also for TX command.

We will no longer do that after davem and I figure out those allocation
patches.

You should implement TCP checksumming in the hardware. *that* would help
a lot.

johannes

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

Re: iwlwifi and tx info in skb->cb

[Tomas Winkler]

On Thu, May 8, 2008 at 5:05 PM, Johannes Berg <johannes@sipsolutions.net> wrote:
>
>  > >  > This is for scatter gather. Nothing to do with aggregation. If you get
>  > >  > fragmented frame you can send it out without linearizing in CPU. in
>  > >  > numer of TB - TX buffers (which is limitted bu MAX_NUM_OF_TBS)  But
>  > >  > I'm just over ever explaining :)
>  > >
>  > >  We don't support that in mac80211 right now, why do you have that there?
>  >
>  > Currently we actively use 2 of them. First for TX command second for
>  > actual frame.  It would be even worth if we need to expand
>  > each packet also for TX command.
>
>  We will no longer do that after davem and I figure out those allocation
>  patches.

Not sure these things are connected. TX command is allocated fixed for each TFD.

>  You should implement TCP checksumming in the hardware. *that* would help
>  a lot.

There is already pretty much deal of link layer in software to reduce
the cost and the complexity of the HW for these softmac NICs so
this would be kind of strange investment...but I didn't invest much
thoughts into yet.
There are probably other means to utilize scatter gather DMA then TCP
off loading. Are they any other source of scattered packets maybe
iovec?


Tomas

Re: iwlwifi and tx info in skb->cb

[Johannes Berg]

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


> >  > Currently we actively use 2 of them. First for TX command second for
> >  > actual frame.  It would be even worth if we need to expand
> >  > each packet also for TX command.
> >
> >  We will no longer do that after davem and I figure out those allocation
> >  patches.
> 
> Not sure these things are connected. TX command is allocated fixed for each TFD.

Ah, no, I misread that. Well, I think it might still help to say you
need N bytes headroom and use those since you wouldn't have to allocate
an extra skb.

> >  You should implement TCP checksumming in the hardware. *that* would help
> >  a lot.
> 
> There is already pretty much deal of link layer in software to reduce
> the cost and the complexity of the HW for these softmac NICs so
> this would be kind of strange investment...but I didn't invest much
> thoughts into yet.
> There are probably other means to utilize scatter gather DMA then TCP
> off loading. Are they any other source of scattered packets maybe
> iovec?

Well as far as I know those too would be zero-copy IO which only works
if you have TCP checksumming in hardware.

johannes

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

Re: iwlwifi and tx info in skb->cb

[Tomas Winkler]

>  Ah, no, I misread that. Well, I think it might still help to say you
>  need N bytes headroom and use those since you wouldn't have to allocate
>  an extra skb.

There actually might be a benefit in doing this but it is quite a
change in design which means not now.

>
>  > >  You should implement TCP checksumming in the hardware. *that* would help
>  > >  a lot.
>  >
>  > There is already pretty much deal of link layer in software to reduce
>  > the cost and the complexity of the HW for these softmac NICs so
>  > this would be kind of strange investment...but I didn't invest much
>  > thoughts into yet.
>  > There are probably other means to utilize scatter gather DMA then TCP
>  > off loading. Are they any other source of scattered packets maybe
>  > iovec?
>
>  Well as far as I know those too would be zero-copy IO which only works
>  if you have TCP checksumming in hardware.

I've just scanned the thread that was explaining why is this necessary
I will read it more carefully... I have just feeling that all this
wlan stuff just fits very awkwardly into current networking stack.

Tomas

Re: iwlwifi and tx info in skb->cb

[Johannes Berg]

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


> I've just scanned the thread that was explaining why is this necessary
> I will read it more carefully... I have just feeling that all this
> wlan stuff just fits very awkwardly into current networking stack.

That's not really related to wireless at all, if you want to do
zero-copy IO then you need to checksum when the stuff hits the wire
which means out of hardware buffers, which some hardware (including
802.11) doesn't support so you need to copy, nothing wireless specific
here :)

Anyway, with the changes davem and I are making to actually save the
*extra* copy we should be doing well. That's where you want to look for
improvements.

johannes

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

Re: iwlwifi and tx info in skb->cb

[Tomas Winkler]

On Fri, May 9, 2008 at 1:30 AM, Johannes Berg <johannes@sipsolutions.net> wrote:
>
>  > I've just scanned the thread that was explaining why is this necessary
>  > I will read it more carefully... I have just feeling that all this
>  > wlan stuff just fits very awkwardly into current networking stack.
>
>  That's not really related to wireless at all, if you want to do
>  zero-copy IO then you need to checksum when the stuff hits the wire
>  which means out of hardware buffers, which some hardware (including
>  802.11) doesn't support so you need to copy, nothing wireless specific
>  here :)
>

The FCS/CRS checksum of the wireless packet is performed in the HW but
why should I care about IP layer?

>  Anyway, with the changes davem and I are making to actually save the
>  *extra* copy we should be doing well. That's where you want to look for
>  improvements.

This is just for the bridging case, isn't it?

Tomas

Re: iwlwifi and tx info in skb->cb

[Johannes Berg]

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


> >  That's not really related to wireless at all, if you want to do
> >  zero-copy IO then you need to checksum when the stuff hits the wire
> >  which means out of hardware buffers, which some hardware (including
> >  802.11) doesn't support so you need to copy, nothing wireless specific
> >  here :)
> >
> 
> The FCS/CRS checksum of the wireless packet is performed in the HW but
> why should I care about IP layer?

Because the data you're sending is sent via TCP?

> >  Anyway, with the changes davem and I are making to actually save the
> >  *extra* copy we should be doing well. That's where you want to look for
> >  improvements.
> 
> This is just for the bridging case, isn't it?

No, this is for TCP and everything else too.

If you don't believe me, read the thread, I don't want to re-iterate it
all.

johannes

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

Re: iwlwifi and tx info in skb->cb

[Johannes Berg]

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

On Fri, 2008-05-09 at 01:17 +0200, Johannes Berg wrote:
> > >  That's not really related to wireless at all, if you want to do
> > >  zero-copy IO then you need to checksum when the stuff hits the wire
> > >  which means out of hardware buffers, which some hardware (including
> > >  802.11) doesn't support so you need to copy, nothing wireless specific
> > >  here :)
> > >
> > 
> > The FCS/CRS checksum of the wireless packet is performed in the HW but
> > why should I care about IP layer?
> 
> Because the data you're sending is sent via TCP?

Basically, it boils down to this:

If you want to checksum the data in software then you need to checksum a
snapshot of the data and not allow the application to modify it after
you have checksummed it, so you need to make a copy and then checksum it
after copying. But if you're making a copy anyway, you can put it all
into one buffer too.

johannes

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

Re: iwlwifi and tx info in skb->cb

[David Miller]

From: "Tomas Winkler" <tomasw@gmail.com>
Date: Fri, 9 May 2008 02:16:14 +0300

> On Fri, May 9, 2008 at 1:30 AM, Johannes Berg <johannes@sipsolutions.net> wrote:
> >  Anyway, with the changes davem and I are making to actually save the
> >  *extra* copy we should be doing well. That's where you want to look for
> >  improvements.
> 
> This is just for the bridging case, isn't it?

No, all cases.

We're repeating a lot of information for you, over and over
again, it seems.  Developers often find this frustrating,
especially when they are trying to get their own work done.

Re: iwlwifi and tx info in skb->cb

[Tomas Winkler]

On Fri, May 9, 2008 at 2:20 AM, David Miller <davem@davemloft.net> wrote:
> From: "Tomas Winkler" <tomasw@gmail.com>
>  Date: Fri, 9 May 2008 02:16:14 +0300
>
>
>  > On Fri, May 9, 2008 at 1:30 AM, Johannes Berg <johannes@sipsolutions.net> wrote:
>
> > >  Anyway, with the changes davem and I are making to actually save the
>  > >  *extra* copy we should be doing well. That's where you want to look for
>  > >  improvements.
>  >
>  > This is just for the bridging case, isn't it?
>
>  No, all cases.
>
>  We're repeating a lot of information for you, over and over
>  again, it seems.  Developers often find this frustrating,
>  especially when they are trying to get their own work done.
>
Hey it's just second time and I explicitly wrote I will read the email
again, you choose to answer... anyway thanks for the answer :)

Tomas