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

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]

Message-Id: <20120702.013626.13785263551119133.davem@davemloft.net>
Date:	Mon, 02 Jul 2012 01:36:26 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	ogerlitz@...lanox.com
Cc:	roland@...nel.org, yevgenyp@...lanox.com, oren@...lanox.com,
	netdev@...r.kernel.org, hadarh@...lanox.co.il
Subject: Re: [PATCH net-next 06/10] {NET,IB}/mlx4: Add device managed flow
 steering firmware API

From: Or Gerlitz <ogerlitz@...lanox.com>
Date: Mon, 2 Jul 2012 11:28:18 +0300

> On 7/2/2012 11:14 AM, Roland Dreier wrote:
>> 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.
--
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