> -----Original Message-----
> From: Jay Vosburgh <[email protected]>
> Sent: Friday, December 8, 2023 3:31 PM
> To: Ertman, David M <[email protected]>
> Cc: Nguyen, Anthony L <[email protected]>; intel-wired-
> [email protected]; [email protected]; Brandeburg, Jesse
> <[email protected]>; Robert Malz <[email protected]>;
> Heitor Alves de Siqueira <[email protected]>
> Subject: Re: [PATCH iwl-next] ice: alter feature support check for SRIOV and
> LAG
> 
> Ertman, David M <[email protected]> wrote:
> 
> >> -----Original Message-----
> >> From: Nguyen, Anthony L <[email protected]>
> >> Sent: Friday, December 8, 2023 1:18 PM
> >> To: Ertman, David M <[email protected]>; intel-wired-
> >> [email protected]
> >> Cc: [email protected]; Brandeburg, Jesse
> >> <[email protected]>
> >> Subject: Re: [PATCH iwl-next] ice: alter feature support check for SRIOV
> and
> >> LAG
> >>
> >>
> >>
> >> On 12/7/2023 10:21 AM, Dave Ertman wrote:
> >> > Previously, the ice driver had support for using a hanldler for bonding
> >> > netdev events to ensure that conflicting features were not allowed to
> be
> >> > activated at the same time.  While this was still in place, additional
> >> > support was added to specifically support SRIOV and LAG together.
> These
> >> > both utilized the netdev event handler, but the SRIOV and LAG feature
> was
> >> > behind a capabilities feature check to make sure the current NVM has
> >> > support.
> >> >
> >> > The exclusion part of the event handler should be removed since there
> are
> >> > users who have custom made solutions that depend on the non-
> exclusion
> >> of
> >> > features.
> >> >
> >> > Wrap the creation/registration and cleanup of the event handler and
> >> > associated structs in the probe flow with a feature check so that the
> >> > only systems that support the full implementation of LAG features will
> >> > initialize support.  This will leave other systems unhindered with
> >> > functionality as it existed before any LAG code was added.
> >>
> >> This sounds like a bug fix? Should it be for iwl-net?
> >>
> >
> >To my knowledge, this issue has not been reported by any users and was
> found
> >through code inspection.  Would you still recommend iwl-net?
> 
>       We have a customer experiencing intermittent issues with
> transmit timeouts that go away if we disable the LAG integration as
> suggested at [0] (or don't use bonding).  This is on the Ubuntu 5.15
> based distro kernel, not upstream, but it does not manifest with the OOT
> driver, and seems somehow related to the LAG offloading functionality.
> 
>       There was also a post to the list describing similar effects
> last month [1], that one seems to be on an Ubuntu 6.2 distro kernel.
> 
>       Could these issues be plausibly related to the change in this
> patch?
> 
>       -J
>

>From your description, it is plausibly related to this patch.  Looks like we 
>should also
send this to iwl-net.

Tony, do you need me to do anything to facilitate this?

DaveE
 
> [0]
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2036239/comment
> s/40
> [1]
> https://lists.osuosl.org/pipermail/intel-wired-lan/Week-of-Mon-
> 20231120/038096.html
> 
> 
> 
> >DaveE
> >
> >> > Reviewed-by: Jesse Brandeburg <[email protected]>
> >> > Signed-off-by: Dave Ertman <[email protected]>
> >> > ---
> >> >   drivers/net/ethernet/intel/ice/ice_lag.c | 2 ++
> >> >   1 file changed, 2 insertions(+)
> >> >
> >> > diff --git a/drivers/net/ethernet/intel/ice/ice_lag.c
> >> b/drivers/net/ethernet/intel/ice/ice_lag.c
> >> > index 280994ee5933..b47cd43ae871 100644
> >> > --- a/drivers/net/ethernet/intel/ice/ice_lag.c
> >> > +++ b/drivers/net/ethernet/intel/ice/ice_lag.c
> >> > @@ -1981,6 +1981,8 @@ int ice_init_lag(struct ice_pf *pf)
> >> >          int n, err;
> >> >
> >> >          ice_lag_init_feature_support_flag(pf);
> >> > +        if (!ice_is_feature_supported(pf, ICE_F_SRIOV_LAG))
> >> > +                return 0;
> >> >
> >> >          pf->lag = kzalloc(sizeof(*lag), GFP_KERNEL);
> >> >          if (!pf->lag)
> 
> ---
>       -Jay Vosburgh, [email protected]

_______________________________________________
Intel-wired-lan mailing list
[email protected]
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan

Reply via email to