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: <BL0PR11MB3122FF228A65C85EA784A1FEBD789@BL0PR11MB3122.namprd11.prod.outlook.com>
Date: Mon, 15 May 2023 07:28:08 +0000
From: "Pucha, HimasekharX Reddy" <himasekharx.reddy.pucha@...el.com>
To: "Drewek, Wojciech" <wojciech.drewek@...el.com>,
	"intel-wired-lan@...ts.osuosl.org" <intel-wired-lan@...ts.osuosl.org>
CC: "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: RE: [Intel-wired-lan] [PATCH iwl-next] ice: Remove LAG+SRIOV mutual
 exclusion

> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@...osl.org> On Behalf Of Wojciech Drewek
> Sent: Friday, May 12, 2023 2:37 PM
> To: intel-wired-lan@...ts.osuosl.org
> Cc: netdev@...r.kernel.org
> Subject: [Intel-wired-lan] [PATCH iwl-next] ice: Remove LAG+SRIOV mutual exclusion
>
> From: Dave Ertman <david.m.ertman@...el.com>
>
>There was a change previously to stop SR-IOV and LAG from existing on the same interface.  This was to prevent the violation of LACP (Link Aggregation Control Protocol).  The method to achieve this was to add a no-op Rx handler onto the netdev when SR-IOV VFs were present, thus blocking bonding, bridging, etc from claiming the interface by adding its own Rx handler.  Also, when an interface was added into a aggregate, then the SR-IOV capability was set to false.
>
> There are some users that have in house solutions using both SR-IOV and bridging/bonding that this method interferes with (e.g. creating duplicate VFs on the bonded interfaces and failing between them when the interface fails over).
>
> It makes more sense to provide the most functionality possible, the restriction on co-existence of these features will be removed.  No additional functionality is currently being provided beyond what existed before the co-existence restriction was put into place.  It is up to the end user to not implement a solution that would interfere with existing network protocols.
>
> Reviewed-by: Michal Swiatkowski <michal.swiatkowski@...ux.intel.com>
> Signed-off-by: Dave Ertman <david.m.ertman@...el.com>
> Signed-off-by: Wojciech Drewek <wojciech.drewek@...el.com>
> ---
> .../device_drivers/ethernet/intel/ice.rst     | 18 -------
> drivers/net/ethernet/intel/ice/ice.h          | 19 -------
> drivers/net/ethernet/intel/ice/ice_lag.c      | 12 -----
> drivers/net/ethernet/intel/ice/ice_lag.h      | 53 -------------------
> drivers/net/ethernet/intel/ice/ice_lib.c      |  2 -
> drivers/net/ethernet/intel/ice/ice_sriov.c    |  4 --
> 6 files changed, 108 deletions(-)
>

Tested-by: Pucha Himasekhar Reddy <himasekharx.reddy.pucha@...el.com> (A Contingent worker at Intel)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ