All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Bjørn Mork" <bjorn@mork.no>
To: joey ming <joey.zming@gmail.com>
Cc: jim_baxter@mentor.com, Alexey Orishko <alexey.orishko@gmail.com>,
	netdev@vger.kernel.org, zhao.ming9@zte.com.cn
Subject: Re: the side effect of using copy skb instead of skb_clone in cdc ncm/mbim driver
Date: Wed, 09 Jul 2014 18:01:45 +0200	[thread overview]
Message-ID: <87zjgih66u.fsf@nemi.mork.no> (raw)
In-Reply-To: <CAOa2BBwVxcC_WoAqExRgEX57BwkikOL_sOBnjus+udNzVB0zqw@mail.gmail.com> (joey ming's message of "Wed, 9 Jul 2014 22:55:05 +0800")

[didn't notice earlier, but Alexey's address was wrong - I fixed it on
this reply]

joey ming <joey.zming@gmail.com> writes:

> thanks for your reply.
> from my test results, perhaps the ncm protocol is the same efficiency with
> cdc-ecm. But Alexey(alexey.orishko@stericsson.com) said his experiment two
> years ago:"One real-world example was modem for 21+6Mbit/s what used 100%
> CPU with ECM responsible for approx. 40% of the MIPS used. Using NCM
> instead CPU was only at approx. 65% utilization. Which allowed multiple
> other functions to be added and significantly increased the usability and
> value of the modem". I don't know why the test result was differ so large.
> Is that correct that cdc-ncm is effctive than cdc-ecm for low speed device
> but not for high speed device?

Alexey's results were on modem hardware, and I am guessing the OS wasn't
Linux.  I have no doubt that you can increase efficiency if you can take
a fixed size big NCM buffer, and make the radio interface write packets
directly into it using the alignment of your choice, before you just
give the whole buffer to a USB controller.  You mostly don't have to
involve the CPU at all.  So NCM is probably a great win for the modems,
and you are right: That is likely why this aggregating protocol was
invented.

But little of this is applicable to the typical Linux implementation,
whether it runs on a host or a device.  Big USB buffers do not help much
on the USB controllers, and they are just a hassle other places because
it's difficult to pass partial buffers around.

And I think modem hardware now has become so much more powerful that the
same applies to it as well.


Bjørn

  parent reply	other threads:[~2014-07-09 16:01 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAOa2BBy4t_17J7G5bBpAZZpBWZYh+Cpc6Fn4u+9cV98M8CZ5gw@mail.gmail.com>
2014-07-08  7:03 ` the side effect of using copy skb instead of skb_clone in cdc ncm/mbim driver Bjørn Mork
     [not found]   ` <CAOa2BBwVxcC_WoAqExRgEX57BwkikOL_sOBnjus+udNzVB0zqw@mail.gmail.com>
2014-07-09 16:01     ` Bjørn Mork [this message]
2014-07-09 23:41       ` Alexey Orishko
2014-07-10  8:50         ` David Laight

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87zjgih66u.fsf@nemi.mork.no \
    --to=bjorn@mork.no \
    --cc=alexey.orishko@gmail.com \
    --cc=jim_baxter@mentor.com \
    --cc=joey.zming@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=zhao.ming9@zte.com.cn \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.