netdev - Re: [PATCH net-next v2 00/12] cdc_ncm: add buffer tuning and stats using ethtool

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 20 May 2014 09:36:57 +0200
From:	Bjørn Mork <bjorn@...k.no>
To:	Lars Melin <larsm17@...il.com>
Cc:	Peter Stuge <peter@...ge.se>, Enrico Mioso <mrkiko.rs@...il.com>,
	David Miller <davem@...emloft.net>, netdev@...r.kernel.org,
	linux-usb@...r.kernel.org, alexey.orishko@...il.com,
	oliver@...kum.org, David.Laight@...lab.com,
	Greg Suarez <gsuarez@...thmicro.com>
Subject: Re: [PATCH net-next v2 00/12] cdc_ncm: add buffer tuning and stats using ethtool

[adding Greg Suarez to the Cc list after noticing that he was missing
 from this thread.  Sorry Greg, that was not my intention.  This
 discussion is just as relevant to cdc_mbim as to cdc_ncm, defining a
 new common userspace API for all the cdc_ncm based drivers]

Bjørn Mork <bjorn@...k.no> writes:
> Lars Melin <larsm17@...il.com> writes:
>
>> Your target audience is embedded systems with limited cpu power and
>> buffer memory, right?
>> If so, then you can't expect them to have ethtool included and their
>> developers are not likely to be happy over having to "waste" another
>> 100KB in order to tune a 20KB driver.
>> My vote goes for sysfs.
>
> That's of course a very good point.
>
> I will argue that you often need ethtool anyway for basic stuff like
> forcing duplex/speed, enabling debug messages, turning on/off pause
> frames etc.  But I don't doubt you know what you are talking about here
> :-)  So I guess many small embedded devices don't include an ethtool
> binary by default.  I do wonder how much we should adapt to that though?
> I understand that you don't see it this way, but others might actually
> see it as an advantage if we're forcing ethtool onto these devices...
>
> Anyway, I'll start looking at an alternative sysfs implementation so we
> can discuss this in terms of actual code.

As this is just a very informal RFC, I'm just attaching the patch to
this mail.  Please test and/or comment.

The patch works for me.  It doesn't remove the ethtool coalescing
support, but I will do that in the final submission if we decide to go
for this sysfs interface instead.

Example output:

 bjorn@...i:~$ grep . /sys/class/net/wwan0/cdc_ncm/*
 /sys/class/net/wwan0/cdc_ncm/rx_max:16384
 /sys/class/net/wwan0/cdc_ncm/tx_max:4096
 /sys/class/net/wwan0/cdc_ncm/tx_timer_usecs:400

I should probably also add a bit more sanity checking of the input for
the final submission. Maybe even make sure the buffers match the
alignment?  Or should that be up to the user?

But we could add information about the device alignment requirements so
that the end user (or userspace application) can make informed decisions.
The whole NTB parameter struct is vital information which is currently only
available for userspace in a debug log message.  Exporting it as a set
of sysfs read only attributes would be nice.  Maybe?  Or am I just
overdoing things now?

It's also tempting to add the 'timer restart count' to this API.  I left
it out of the ethtool based version because I couldn't make it fit
anywhere.  But it is part of the driver's frame aggregation algorithm.

Bjørn

View attachment "0001-net-cdc_ncm-add-sysfs-support-for-buffer-tuning.patch" of type "text/x-diff" (6534 bytes)