Thread (45 messages) flat view 45 messages, 7 authors, 2012-07-03

Re: [PATCH net-next 06/10] {NET,IB}/mlx4: Add device managed flow steering firmware API

From: David Miller <davem@davemloft.net>
Date: 2012-07-02 08:36:27

From: Or Gerlitz <redacted>
Date: Mon, 2 Jul 2012 11:28:18 +0300
On 7/2/2012 11:14 AM, Roland Dreier wrote:
quoted
What was wrong with Dave's initial suggestion of ethtool? All the
other steering stuff is configured that way, why not this hash?
Roland, as I wrote earlier on this thread --> [...] pointed out in the
change-log, note that this policy is **global** to the HCA, that is
effects all the Ethernet (and down the road, also when adding support
for IPoIB flow-steering, under a config of card with one IB port and
one Eth port) net-devices that relate to that mlx4 device instance.

In a system with (say) one card and two Ethernet ports, where for each
port there's corresponding ethN interface, **both** mlx4_en
net-devices use the same instance of struct mlx4_device, which means
that if we let the user to set through ethtool the flow steering hash
of ethN1 this will evetually change also the hash used for packets
going to ethN2, or in other words, in mlx4 language this param belong
to the mlx4_core module. In that respect, I was thinking on using
sysfs as we do for the port link type and IB mtu, hope this makes
things clearer, SB the relevant code, now with the global module param
which can change to using per mlx4_core device sysfs.
I frankly don't care what your special unique situation is.

You cannot create chipset specific interfaces like module parms
and randomly named sysfs files as an interface to configure your
hardware.

Other chipsets will want the same thing or something similar.

So you must create a real generic interface that other chipsets
in similar situations can hook into as well.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help