Re: changing usbnet's API to better deal with cdc-ncm

[Oliver Neukum <oneukum@suse.de>]

On Friday 07 September 2012 00:09:13 Ming Lei wrote:
> On Thu, Sep 6, 2012 at 4:30 PM, Bjørn Mork <bjorn@mork.no> wrote:
> > Ming Lei <tom.leiming@gmail.com> writes:

> >> Looks the introduced .tx_bundle is not necessary since .tx_fixup is OK.
> >
> > The minidriver does not have any information about tx in progress.  The
> 
> Inside .tx_fixup, the low level driver will get the tx progress information.

That information changes after tx_fixup
 
> > strategy above, which is what cdc_ncm uses today, is fine as long as you
> > always want to wait as long as you always want to fill as many frames as
> > possible in each packet.  But what if the queue is empty and the device
> 
> For cdc_ncm, the wait time is controlled by cdc_ncm driver, see
> cdc_ncm_tx_timeout_start().

Well, that is the mistake. Using a timer is a bad idea.

> If we can abstract some common things about aggregation, it should be
> meaningful. As far as I know, most of aggregation protocol is very different,
> so almost all aggregation work is only done by low level driver, such as
> cdc_ncm.
> 
> If we want to implement some aggregation framework, maybe below is
> one solution, correct me if it is wrong.

It isn't so much wrong as incomplete.

It seems to me we can have

- can queue, buffer not full -> do nothing more
- can queue, buffer full -> transmit
- cannot queue, buffer full -> transmit and then try again to queue

and an error case

- cannot queue, buffer not full

And that's the way I coded it.

	Regards
		Oliver