netdev - Flow control config vs status

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-next>] [day] [month] [year] [list]

Message-ID: <20111007211918.GA7388@mcarlson.broadcom.com>
Date:	Fri, 7 Oct 2011 14:19:18 -0700
From:	"Matt Carlson" <mcarlson@...adcom.com>
To:	"Ben Hutchings" <bhutchings@...arflare.com>
cc:	netdev <netdev@...r.kernel.org>
Subject: Flow control config vs status

Hi Ben.  I've been encountering with a small problem with how ethtool
handles flow control settings.

When the admin runs 'ethtool -A ...', ethtool will run an
ETHTOOL_GPAUSEPARAM query, check the new settings against the 'old',
and then issue ETHTOOL_SPAUSEPARAM if they don't match.  My problem is
that the tg3 driver returns the flow control status in a
ETHTOOL_GPAUSEPARAM query, not the configuration.

So, as an example of the problem, if the local side sets
'ethtool -A ethx rx on tx on autoneg on', and then the remote side sets
'ethtool -A ethy rx off tx off autoneg off', the link will autoneg to rx
off, tx off.  Then, the local side will be unable to turn off rx or tx
flow control because ethtool will act on the current link flow control
status, not the config.

The tg3 isn't the only driver that reports flow control status through
ETHTOOL_GPAUSEPARAM.  The e1000e, bnx2, and bnx2x drivers do this as
well.

The ETHTOOL_GSET query does make room for flow control advertisements,
but a device doesn't have to advertise its flow control settings if flow
control autoneg is turned off.  I'm thinking this interface doesn't
really solve the problem.

Any recommendations?

--
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