carl9170.ko RX - DMA, TX - COPY.

carl9170.ko RX - DMA, TX - COPY.

[Andrew V. Stepanov]

Hello.

I'm very surprising, that carl9170.ko uses DMA only for receiving.

Is it possible to use DMA for sending packets in carl9170?

Can anybody shed some light on this?

Thanks!

Re: carl9170.ko RX - DMA, TX - COPY.

[Christian Lamparter]

On Tuesday 03 May 2011 12:50:26 Andrew V. Stepanov wrote:
> I'm very surprising, that carl9170.ko uses DMA only for receiving.
Interesting, how do you arrive on the conclusion?

Regards,
	Chr

Re: carl9170.ko RX - DMA, TX - COPY.

[Christian Lamparter]

(readded ML -  please keep it in your replies)
> On Tuesday 03 May 2011 13:43:56 Andrew V. Stepanov wrote:
> I have ARM board (davinci dm365) with slow CPU.
do you use compat-wireless and what kernel?

> I uses pktgen.ko for testing purposes
For testing, I extensively use  iperf (TCP / UDP). It's a userspace
application and binaries are available for most OS easily.
Furthermore, the data it produces is more comparable to
the applications people actually use.
 
> carl9170.ko shows only 16 MBit/sec emit speed from kernel space,
> without touching user space.
> 
> Other driver rt3070sta.ko (another USB wifi device) shows 166Mb/sec.
The staging rt3070sta driver is no more, for a comparison you would
have to use rt2800usb.
 
> At this time 'top' command shows 100 % CPU load by  "kpktgend_0" thread:
> 2477 root      20   0     0    0    0 R 94.8  0.0   6:10.23 kpktgend_0
> 
> I concluded that carl9170.ko doesn't uses DMA.
> Also, in source code drivers/net/wireless/ath/carl9170, i didn't find
> DMA functions.
 
That's because the USB subsystem takes care of that entirely, so unless
your musb ehci highspeed host does PIO because of incompatibility, there's
no "manual copy" in the TX path [except in cases where there's not enough
headroom/tailroom, or a second virtual interface, etc...].
 
Regards,
	Chr

Re: carl9170.ko RX - DMA, TX - COPY.

[Christian Lamparter]

(readded ML -  KEEP IT in your replies/use reply all)

On Tuesday 03 May 2011 16:17:36 Andrew V. Stepanov wrote:
> On Tue, May 3, 2011 at 8:52 PM, Christian Lamparter
> > > On Tuesday 03 May 2011 13:43:56 Andrew V. Stepanov wrote:
> > > I have ARM board (davinci dm365) with slow CPU.
> > 
> > do you use compat-wireless and what kernel?
I repeat: do you use compat-wireless? and what kernel do you have?

> >> carl9170.ko shows only 16 MBit/sec emit speed from kernel space,
> >> without touching user space.
> >> 
> >> Other driver rt3070sta.ko (another USB wifi device) shows 166Mb/sec.
> > 
> > The staging rt3070sta driver is no more, for a comparison you would
> > have to use rt2800usb.
> > 
> >> At this time 'top' command shows 100 % CPU load by  "kpktgend_0" thread:
> >> 2477 root      20   0     0    0    0 R 94.8  0.0   6:10.23 kpktgend_0
> >> 
> >> I concluded that carl9170.ko doesn't uses DMA.
> >> Also, in source code drivers/net/wireless/ath/carl9170, i didn't find
> >> DMA functions.
> > 
> > That's because the USB subsystem takes care of that entirely, so unless
> > your musb ehci highspeed host does PIO because of incompatibility,
> > there's no "manual copy" in the TX path [except in cases where there's
> > not enough headroom/tailroom, or a second virtual interface, etc...].
> 
> I believe my musb host support HIGH SPEED protocol.
True, but the USB-core in the device[AR9170] is a little bit picky, Also users 
have told me that they had problems in "low-power" conditions. Which is not
that unlikely and maybe one of the reasons AR9170 was replaced so quickly.
[Note: some vendors [Unex?] can sell you other solutions which have some
nifty protocol offload capabilities, so why not get one of those for the setup 
instead?] 

> rt3070sta.ko - also shows up to 6Mbytes/sec output throughput on this
> board.
Again: rt3070sta is gone/obsolete, test with rt2800usb instead!

> carl9170.ko - shows only 2 Mbytes/sec output throughput with 100%
> CPU utilization (kpktgend_0 thread).
Well, looks like you will have to enable profiling to find the bottleneck.
Is oprofile available for your target, or are there any other profiling
tools you can use [there should be some, given that you have a DEV board]? 

> User space programs can recive data with 4 MBytes/sec on carl9170.ko.
Heh, did you know that the RX-path actually has to "memcpy" all incoming
data? In this regard, the rx result should be even worse....

> On Intel platform with carl9170.ko I can send data with 8Mbytes/sec
> and recive 11Mbytes/sec (restriction of 100MBps ethernet hub).
ok, so the device/cable isn't broken.

Regards,
	Chr

Re: carl9170.ko RX - DMA, TX - COPY.

[Christian Lamparter]

On Tuesday 03 May 2011 17:41:49 Andrew V. Stepanov wrote:
> On Tue, May 3, 2011 at 11:18 PM, Christian Lamparter
> <chunkeey@googlemail.com> wrote:
> > (readded ML -  KEEP IT in your replies/use reply all)
> >> >> carl9170.ko shows only 16 MBit/sec emit speed from kernel space,
> >> >> without touching user space.
> >> >> 
> >> >> Other driver rt3070sta.ko (another USB wifi device) shows 166Mb/sec.
> >> > 
> >> > The staging rt3070sta driver is no more, for a comparison you would
> >> > have to use rt2800usb.
> >> > 
> >> >> At this time 'top' command shows 100 % CPU load by  "kpktgend_0"
> >> >> thread: 2477 root      20   0     0    0    0 R 94.8  0.0   6:10.23
> >> >> kpktgend_0
> >> >> 
> >> >> I concluded that carl9170.ko doesn't uses DMA.
> >> >> Also, in source code drivers/net/wireless/ath/carl9170, i didn't find
> >> >> DMA functions.
> >> > 
> >> > That's because the USB subsystem takes care of that entirely, so
> >> > unless your musb ehci highspeed host does PIO because of
> >> > incompatibility, there's no "manual copy" in the TX path [except in
> >> > cases where there's not enough headroom/tailroom, or a second virtual
> >> > interface, etc...].
> >> 
> >> I believe my musb host support HIGH SPEED protocol.
> > 
> > True, but the USB-core in the device[AR9170] is a little bit picky, Also
> > users have told me that they had problems in "low-power" conditions.
> > Which is not that unlikely and maybe one of the reasons AR9170 was
> > replaced so quickly. [Note: some vendors [Unex?] can sell you other
> > solutions which have some nifty protocol offload capabilities, so why
> > not get one of those for the setup instead?]
> 
> I'm looking for any solutions that capable to emit with 8MBytes/sec
> speed from DDR2 from my board.
Wait, wait wait... haven't you said in your previous mail that a USB 2.0
flash stick "maxed" at just 6MB/s? I don't think you will come anywhere
close to 8MB/s with this setup then, unless you can swap the USB WIFI
for a AHB/PCI(e) device and even it might struggle.

> Can you give me more information about this solutions ?
Well, dnua-93f for example, however I doubt it will do better than 6MB/s
in the same setup [also note: this is a 1x1 dongle]. So, you'll have to
do some "research" first this time...

> >> rt3070sta.ko - also shows up to 6Mbytes/sec output throughput on this
> >> board.
> > 
> > Again: rt3070sta is gone/obsolete, test with rt2800usb instead!
> 
> I have tested all tree drivers:
> 
> [...]
> rt2800usb - from compat-wireless
> 
> All drivers shows poor performance even on Intel platform
> (6 Mbytes/sec).
Uh, last time I checked I had no problems getting 80Mbit TCP tp out of
a WUSB600 (rt3070, I think?) with an old Pentium M laptop. Maybe you
should contact Ivo/Helmut about the "poor" performance.

> >> carl9170.ko - shows only 2 Mbytes/sec output throughput with 100%
> >> CPU utilization (kpktgend_0 thread).
> > 
> > Well, looks like you will have to enable profiling to find the
> > bottleneck. Is oprofile available for your target, or are there any
> > other profiling tools you can use [there should be some, given that you
> > have a DEV board]?
> 
> I can compile kernel with any configuration.
> I have board http://support.spectrumdigital.com/boards/evmdm365/reve/
Ok? So what are you waiting for? Get your profiling tool working and 
look for the bottleneck, you certainly can't miss it! Good Luck!

Oh, just a sec, before you start: there's a possibility that the attached 
patch [below the cut line] from a different user helps a bit as well.

Regards,
     Chr
---
diff --git a/drivers/net/wireless/ath/carl9170/usb.c 
b/drivers/net/wireless/ath/carl9170/usb.c
index 2fb53d0..b5e73ae 100644
--- a/drivers/net/wireless/ath/carl9170/usb.c
+++ b/drivers/net/wireless/ath/carl9170/usb.c
@@ -485,7 +485,7 @@ static int carl9170_usb_send_rx_irq_urb(struct ar9170 *ar)
 
 	usb_fill_int_urb(urb, ar->udev, usb_rcvintpipe(ar->udev,
 			 AR9170_USB_EP_IRQ), ibuf, AR9170_USB_EP_CTRL_MAX,
-			 carl9170_usb_rx_irq_complete, ar, 1);
+			 carl9170_usb_rx_irq_complete, ar, 10);
 
 	urb->transfer_flags |= URB_FREE_BUFFER;
 
@@ -614,7 +614,7 @@ int __carl9170_exec_cmd(struct ar9170 *ar, struct 
carl9170_cmd *cmd,
 
 	usb_fill_int_urb(urb, ar->udev, usb_sndintpipe(ar->udev,
 		AR9170_USB_EP_CMD), cmd, cmd->hdr.len + 4,
-		carl9170_usb_cmd_complete, ar, 1);
+		carl9170_usb_cmd_complete, ar, 10);
 
 	if (free_buf)
 		urb->transfer_flags |= URB_FREE_BUFFER;

Re: carl9170.ko RX - DMA, TX - COPY.

[Christian Lamparter]

On Wednesday 04 May 2011 12:31:45 Andrew V. Stepanov wrote:
> I think main problem is unaligment skbuff.
> But, I don't know how to fix this.
> 
well, you can't really fix it, unless musb now allows unaligned dma.
AR9170 has its own rules about alignment and in this case they
clash with the ones of your system.

What you could do: enable WDS or play around with NET_IP_ALIGN 0 if
your arch supports it [unlikely, given that it is an ARM]

Regards,
	Chr

Re: carl9170.ko RX - DMA, TX - COPY

[Christian Lamparter]

On Wednesday 04 May 2011 18:52:58 Andrew V. Stepanov wrote:
> I think it is possible to align SKB frames in carl9170.ko driver.
> 
> rt2800usb do such think in next way:
> 
> void rt2x00queue_align_frame(struct sk_buff *skb)
> {
> »···unsigned int frame_length = skb->len;
> »···unsigned int align = ALIGN_SIZE(skb, 0);
> 
> »···if (!align)
> »···»···return;
> 
> »···skb_push(skb, align);
> »···memmove(skb->data, skb->data + align, frame_length);
> »···skb_trim(skb, frame_length);
> }
> 
> What do you think about this?
No that's wrong, here's the comment from rt2x00queue.c

"When DMA allocation is required we should guarantee to the
 driver that the DMA is aligned to a 4-byte boundary.
 However some drivers require L2 padding to pad the payload
 rather then the header. This could be a requirement for
 PCI and USB devices, while header alignment only is valid
 for PCI devices."

Do you see the difference there; header alignment is only needed
for PCI whereas rt2800usb hw/fw allows just the L2 data to be
padded and sadly AR9170 hw does not have this feature. 

Also, someone <https://patchwork.kernel.org/patch/98997/> added
bounce buffers to musb some time ago, so why not use this approach
instead? The advantage is that you won't need to modify any other
drivers when you will (inevitable) replace the device with a
better one, right?

Regards,
	Chr

Re: carl9170.ko RX - DMA, TX - COPY

[Christian Lamparter]

On Friday 06 May 2011 14:13:39 Andrew V. Stepanov wrote:
> What is:
> 
>  ar->fw.tx_stream = true;
> 
What about it? it's a configurable feature. It can be used to 
upload several frames in one urb-[tansfer], but I never looked into
usb sg and it wasn't enabled in the original vendor driver either.

Currently, It just adds another 4 byte [tag + len] to the headroom so
it won't make a difference in your case anyway...

Regards,
	Christian