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  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, 27 May 2014 13:07:29 +0200
From:	Bjørn Mork <bjorn@...k.no>
To:	netdev@...r.kernel.org
Cc:	linux-usb@...r.kernel.org,
	Alexey Orishko <alexey.orishko@...il.com>,
	Oliver Neukum <oliver@...kum.org>,
	Enrico Mioso <mrkiko.rs@...il.com>,
	David Laight <David.Laight@...LAB.COM>,
	Lars Melin <larsm17@...il.com>,
	Greg Suarez <gsuarez@...thmicro.com>
Subject: Re: [PATCH net-next 8/8] net: cdc_ncm: document the sysfs API

Peter Stuge <peter@...ge.se> writes:

> Bjørn Mork wrote:
>> +++ b/Documentation/ABI/testing/sysfs-class-net-cdc_ncm
>> @@ -0,0 +1,143 @@
>> +What:		/sys/class/net/<iface>/cdc_ncm/min_tx_pkt
>> +Date:		May 2014
>> +KernelVersion:	3.16
>> +Contact:	Bjørn Mork <bjorn@...k.no>
>> +Description:
>> +		The driver will pad frames longer than this to tx_max,
>                                            ^^^^^^
> longer or shorter?

longer.  If it is shorter then it is sent as-is.  I guess this setting
could use a bit more explanation here.


>
>> +What:		/sys/class/net/<iface>/cdc_ncm/rx_max
>> +Date:		May 2014
>> +KernelVersion:	3.16
>> +Contact:	Bjørn Mork <bjorn@...k.no>
>> +Description:
>> +		The maximum NCM Transfer Block (NTB) size for RX.
>> +		Cannot exceed the maximum value supported by the
>> +		device. Must allow at least one max sized datagram
>> +		plus headers.
>> +
>> +		The actual limits are device dependent.  See
>> +		dwNtbInMaxSize.
>> +
>> +		Note: Some devices will silently ignore changes to
>> +		this value, resulting in oversized NTBs and
>> +		corresponding framing errors.
>
> That behavior makes the setting only so-so useful. Could the driver
> know which devices do this, or is it inconsistent even across
> individual devices which are otherwise indistinguishable?

I have no idea, and I don't know how to find out.  I've observed the
failure on one of my MBIM modems.  That's all I know.

I believe the setting still is useful for all spec compliant devices,
and even most of the others.  The firmware bug does make it difficult to
do any automagic tuning.  But it's not impossible.  The tuning
application can do a bit of probing and looking at the frame error
counter.

>> +What:		/sys/class/net/<iface>/cdc_ncm/tx_timer_usecs
>> +Date:		May 2014
>> +KernelVersion:	3.16
>> +Contact:	Bjørn Mork <bjorn@...k.no>
>> +Description:
>> +		Datagram aggregation timeout in µs. The driver will
>> +		wait up to 3 times this timeout for more datagrams to
>> +		aggregate before transmitting a NTB frame.
>                                               ^
> "an NTB frame" might be better since N sounds like "enn".


OK

>> +
>> +		Valid range: 5 to 4000000
>> +
>> +		Set to 0 to disable aggregation.
>> +
>> +The following read only attributes all represent fields of the
>
> read-only?

OK


Thanks for reviewing this.



Bjørn
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists