Re: [Cerowrt-devel] [discuss] [cdc_ncm] Refactoring cdc_ncm

Re: [Cerowrt-devel] [discuss] [cdc_ncm] Refactoring cdc_ncm

[Dave Taht]

I would like to see folk poking to bufferbloat on LTE, and this looks
like a decent/chip and driver to fiddle with.

Is anyone here using that device? I am under the impression you can
only order them from overseas...

On Mon, Jan 19, 2015 at 8:51 AM, Enrico Mioso <mrkiko.rs@gmail.com> wrote:
> Hi guys.
> I am noticing that in kernel 3.19rc4, the driver from huawei,
> hw_cdc_driver
> is not able to perform the call to
> netif_msg_ifup anymore (receives error -13).
> This to say that it would be very important to continue the work on
> refactoring cdc_ncm.c driver to let it work with newer huawei devices such
> as the E3372 even at full rates.
> I received some acks regarding the patches I sent last time - and I am
> grateful to you all maintainers / reviewers. I have actually not received
> acks for all the patches so I preferred waiting and not continously
> re-sending again.
> This also happened due to me getting very busy lately with studying.
> So the situation is getting complicated.
> I sent this mail to everyone just to keep you up-to-date. Don't worry.
> Any help from any developer interested would be very apreciated.
> I would need some mentoring or help in general with coding.
>
> Thank you all very much.
>
> Sincerely.
>
> Enrico
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Dave Täht

thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks

Re: [Cerowrt-devel] [discuss] [cdc_ncm] Refactoring cdc_ncm

[Enrico Mioso]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2355 bytes --]

Thank you guys for the reply and the interest.
Please keep me on CC as I am not subscribed to any list.
However - here we are not trying to work around the big problem that is bufferbloat.
We are trying to change the way the cdc_ncm.c driver generate frames. We need to let it order parts of the packet in a different way.
However - any kind of work is welcome and apreciated of course!
And this could be the right moment to pick in some discussion about this.


On Mon, 19 Jan 2015, Dave Taht wrote:

> Date: Mon, 19 Jan 2015 18:47:23
> From: Dave Taht <dave.taht@gmail.com>
> To: Enrico Mioso <mrkiko.rs@gmail.com>,
>     "cerowrt-devel@lists.bufferbloat.net"
>     <cerowrt-devel@lists.bufferbloat.net>
> Subject: Re: [discuss] [cdc_ncm] Refactoring cdc_ncm
> 
> I would like to see folk poking to bufferbloat on LTE, and this looks
> like a decent/chip and driver to fiddle with.
>
> Is anyone here using that device? I am under the impression you can
> only order them from overseas...
>
> On Mon, Jan 19, 2015 at 8:51 AM, Enrico Mioso <mrkiko.rs@gmail.com> wrote:
>> Hi guys.
>> I am noticing that in kernel 3.19rc4, the driver from huawei,
>> hw_cdc_driver
>> is not able to perform the call to
>> netif_msg_ifup anymore (receives error -13).
>> This to say that it would be very important to continue the work on
>> refactoring cdc_ncm.c driver to let it work with newer huawei devices such
>> as the E3372 even at full rates.
>> I received some acks regarding the patches I sent last time - and I am
>> grateful to you all maintainers / reviewers. I have actually not received
>> acks for all the patches so I preferred waiting and not continously
>> re-sending again.
>> This also happened due to me getting very busy lately with studying.
>> So the situation is getting complicated.
>> I sent this mail to everyone just to keep you up-to-date. Don't worry.
>> Any help from any developer interested would be very apreciated.
>> I would need some mentoring or help in general with coding.
>>
>> Thank you all very much.
>>
>> Sincerely.
>>
>> Enrico
>> --
>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>
>
> -- 
> Dave Täht
>
> thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks
>

Re: [Cerowrt-devel] [discuss] [cdc_ncm] Refactoring cdc_ncm

[Valdis.Kletnieks]

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

On Mon, 19 Jan 2015 19:28:48 +0100, Enrico Mioso said:

> We are trying to change the way the cdc_ncm.c driver generate frames. We need
> to let it order parts of the packet in a different way.

You're going to have to repeat that, and explain why you think re-ordering parts
of the packet is going to work.  (Hint - what happens when this packet with
oddly ordered parts arrives at a host that is expecting RFC-standard ordering?)

[-- Attachment #2: Type: application/pgp-signature, Size: 848 bytes --]

Re: [Cerowrt-devel] [discuss] [cdc_ncm] Refactoring cdc_ncm

[Enrico Mioso]

First of all: hello to everyone and good evening.
I put you in CC Bjorn so that you can also follow this conversation.
Please all of you - keep me in CC, I am not subscribed to any list.

So - let explain it from the beginning. Sorry if I didn't do this before.

Some USB dongle modems / might be chipsets?, use the NCM protocol: an USB 
specification, whose main goal was to allow for grouping of more than one 
ethernet frame in a single USB packet, thus allowing for more efficiency and 
performance.
you can find it at http://www.usb.org/
after some juggling around. Or look at the URL I specified in my first patch in 
case.

An NCM packet is formed of different parts: I remember the acronyms, not their 
meaning. Still you can see them in the specs.
- DPE
- NDP
- and so on;

the position of some of these parts is "arbitrary": not specified in the specs.
The device system (running Linux) and the firmware, can infact put them 
practically where they want.
However, some particular devices, like the E3372 and possibly other devices, 
require the NDP part of the packet being placed at the end. Wituout this, the 
device will not validate packets, not answer to them.

So the need for modifying / refactoring the cdc_ncm.c driver occurred: in that 
driver infact, some parts of the NCM logic and the "driver code" are not 
separate enough in my point of view.
And more - the NCM logic itself, would need to be refactored out, so that it 
can be made more flexible in the future, adaptable to newer devices as problems 
arise.
In particular, contrary to what the driver does in it's current state, my goals 
would be, in order of importance:
- completely separate ncm-related code from the rest
- changing the way in which the {tx,rx}_fixup functions handle frames they 
{build / prepare to send,receive incoming} frames.
   This, to allow for queuing up frames and building the NCM packet all at once
   when needed.

The driver uses a smart solution to coalesce frames in one packet, as 
implemente by Bjorn, to which I am grate for this work also.

So - sorry if I've been boring.
Any help would be _greatly_ welcome.
Enrico

Re: [Cerowrt-devel] [discuss] [cdc_ncm] Refactoring cdc_ncm

[Enrico Mioso]

A follow-up note: it would be also fine if we could support both 16 and 32 bit NCM protocol.
Why?
Because you never know.

Enrico

Re: [Cerowrt-devel] [discuss] [cdc_ncm] Refactoring cdc_ncm

[Enrico Mioso]

A third follow-up: if you can just point me out to some interesting functions I might use to do these things, it would be ok.
I am thinking that you woudln't use the list framework of the kernel in the 
networking subsystem for queuing packets.
I know - I am misinformed a lot.

Thank you,
Enrico


On Tue, 20 Jan 2015, Valdis.Kletnieks@vt.edu wrote:

> Date: Tue, 20 Jan 2015 17:13:38
> From: Valdis.Kletnieks@vt.edu
> To: Enrico Mioso <mrkiko.rs@gmail.com>
> Cc: Dave Taht <dave.taht@gmail.com>,
>     "cerowrt-devel@lists.bufferbloat.net"
>     <cerowrt-devel@lists.bufferbloat.net>
> Subject: Re: [Cerowrt-devel] [discuss] [cdc_ncm] Refactoring cdc_ncm
> 
> On Mon, 19 Jan 2015 19:28:48 +0100, Enrico Mioso said:
>
>> We are trying to change the way the cdc_ncm.c driver generate frames. We need
>> to let it order parts of the packet in a different way.
>
> You're going to have to repeat that, and explain why you think re-ordering parts
> of the packet is going to work.  (Hint - what happens when this packet with
> oddly ordered parts arrives at a host that is expecting RFC-standard ordering?)
>