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!
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
On Tuesday 03 May 2011 17:41:49 Andrew V. Stepanov wrote:
> On Tue, May 3, 2011 at 11:18 PM, Christian Lamparter
> <[email protected]> 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;
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