From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 503E821F0AE for ; Tue, 20 Jan 2015 10:20:54 -0800 (PST) Received: by mail-we0-f181.google.com with SMTP id q58so39606948wes.12 for ; Tue, 20 Jan 2015 10:20:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:date:to:cc:subject:in-reply-to:message-id:references :mime-version:content-type; bh=LehItnsSxmSUBpF0JKkibq3N28Ds9Keb6BDiebIdQEw=; b=g8HPAn/IvUGqdOXzKXoWRL2K0DXI20YZ0zQOesiKOyc2HEDTn30PvopXc2wacKZUcR zSRJ3KhY/FZFUvUPGPnDdeJr0zHno0LmOfcbI76/ZotqavYyaBrAgasJKNZrsht0Y3F2 5hJg+CLlqctBXrVVLQg6NVJFaXTkr7cM/2N3Qwh9oCcUjuv2/ZdorZFgDDzVVopJLyHG L+yt/5vXPABYRDbelCmHU7RQ31g8gzi5L1ZRQes048rVh0riiOqSQd78SIYDqCIW4Nof srlV1L0/KYg2idw84KRs4GBP0csO14dstegLCvSBll1fz8jwS2wsCa5o2jDUrrVqLpks AZLw== X-Received: by 10.194.75.195 with SMTP id e3mr17959342wjw.44.1421778052726; Tue, 20 Jan 2015 10:20:52 -0800 (PST) Received: from eeec.lan (host180-253-dynamic.8-87-r.retail.telecomitalia.it. [87.8.253.180]) by mx.google.com with ESMTPSA id i3sm4005174wie.23.2015.01.20.10.20.51 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 20 Jan 2015 10:20:51 -0800 (PST) From: Enrico Mioso X-Google-Original-From: Enrico Mioso Date: Tue, 20 Jan 2015 19:21:34 +0100 (CET) X-X-Sender: mrkiko@localhost.localdomain To: Valdis.Kletnieks@vt.edu In-Reply-To: <5605.1421770418@turing-police.cc.vt.edu> Message-ID: References: <877fy7myfb.fsf@nemi.mork.no> <54811670.5030703@audiocodes.com> <8761dqjuuh.fsf@nemi.mork.no> <5605.1421770418@turing-police.cc.vt.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: bjorn@mork.no, "cerowrt-devel@lists.bufferbloat.net" Subject: Re: [Cerowrt-devel] [discuss] [cdc_ncm] Refactoring cdc_ncm X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2015 18:21:23 -0000 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