RE: [net-next 1/6] ixgbe: Do not allow LRO or MTU change with XDP

2018-07-26 Thread Nguyen, Anthony L
> From: Jakub Kicinski [mailto:jakub.kicin...@netronome.com]
> Sent: Thursday, July 26, 2018 2:47 PM
> On Thu, 26 Jul 2018 14:21:08 -0700, Jakub Kicinski wrote:
> > On Thu, 26 Jul 2018 10:40:45 -0700, Jeff Kirsher wrote:
> > > From: Tony Nguyen 
> > >
> > > XDP does not support jumbo frames or LRO.  These checks are being
> > > made outside the driver when an XDP program is loaded, however,
> > > there is nothing preventing these from changing after an XDP program is
> loaded.
> > > Add the checks so that while an XDP program is loaded, do not allow
> > > MTU to be changed or LRO to be enabled.
> > >
> > > Signed-off-by: Tony Nguyen 
> > > Tested-by: Andrew Bowers 
> > > Signed-off-by: Jeff Kirsher 
> > > ---
> > >  drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 10 ++
> > >  1 file changed, 10 insertions(+)
> > >
> > > diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> > > b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> > > index 5a6600f7b382..c42256e91997 100644
> > > --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> > > +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> > > @@ -6469,6 +6469,11 @@ static int ixgbe_change_mtu(struct net_device
> > > *netdev, int new_mtu)  {
> > >   struct ixgbe_adapter *adapter = netdev_priv(netdev);
> > >
> > > + if (adapter->xdp_prog) {
> > > + e_warn(probe, "MTU cannot be changed while XDP program is
> loaded\n");
> > > + return -EPERM;
> >
> > EPERM looks wrong, EINVAL is common.  Also most drivers will just
> > check the bounds like you do in ixgbe_xdp_setup(), allowing the change
> > if new MTU still fits constraints.
> >
> > FWIW are the IXGBE_FLAG_SRIOV_ENABLED and IXGBE_FLAG_DCB_ENABLED
> flag
> > changes also covered while xdp is enabled?  Quick grep doesn't reveal
> > them being checked against xdp_prog other than in ixgbe_xdp_setup().
> 
> Ah, I didn't make the review in time :)  Could you follow up?

Yes, I'll make a follow-on patch to address your comments.


RE: [net-next v3 1/5] ixgbe: Ensure MAC filter was added before setting MACVLAN

2017-07-19 Thread Nguyen, Anthony L


> -Original Message-
> From: Joe Perches [mailto:j...@perches.com]
> Sent: Wednesday, July 19, 2017 3:55 AM
> Subject: Re: [net-next v3 1/5] ixgbe: Ensure MAC filter was added before 
> setting
> MACVLAN
> 
> On Tue, 2017-07-18 at 18:23 -0700, Jeff Kirsher wrote:
> > This patch adds a check to ensure that adding the MAC filter was
> > successful before setting the MACVLAN.  If it was unsuccessful,
> > propagate the error.
> []
> > diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
> > b/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
> []
> > @@ -681,6 +681,7 @@ static int ixgbe_set_vf_macvlan(struct
> > ixgbe_adapter *adapter,  {
> > struct list_head *pos;
> > struct vf_macvlans *entry;
> > +   s32 retval = 0;
> 
> This function returns int, why use s32 here?
> 
> > if (index <= 1) {
> > list_for_each(pos, >vf_mvs.l) { @@ -721,14 +722,15
> @@
> > static int ixgbe_set_vf_macvlan(struct ixgbe_adapter *adapter,
> > if (!entry || !entry->free)
> > return -ENOSPC;
> >
> > -   entry->free = false;
> > -   entry->is_macvlan = true;
> > -   entry->vf = vf;
> > -   memcpy(entry->vf_macvlan, mac_addr, ETH_ALEN);
> > -
> > -   ixgbe_add_mac_filter(adapter, mac_addr, vf);
> > +   retval = ixgbe_add_mac_filter(adapter, mac_addr, vf);
> > +   if (retval >= 0) {
> > +   entry->free = false;
> > +   entry->is_macvlan = true;
> > +   entry->vf = vf;
> > +   memcpy(entry->vf_macvlan, mac_addr, ETH_ALEN);
> > +   }
> >
> > -   return 0;
> > +   return retval;
> 
> This is also backwards logic from typical style and unnecessarily indents 
> code.
> 
>   retval = ixgbe_add_mac_filter(adapter, mac_addr, vf);
>   if (retval < 0)
>   return retval;
> 
>   entry->free = false;
>   entry->is_macvlan = true;
>   entry->vf = vf;
>   memcpy(entry->vf_macvlan, mac_addr, ETH_ALEN);>
> 
>   return 0;
> }
> 
> This patch also sets the return value to a possible positive value.
> 
> Is that really desired?
> 
> The only code that seems to use a possible positive value also limits its 
> return to
> 0
> 
> static int ixgbe_uc_sync(struct net_device *netdev, const unsigned char 
> *addr) {
>   struct ixgbe_adapter *adapter = netdev_priv(netdev);
>   int ret;
> 
>   ret = ixgbe_add_mac_filter(adapter, addr, VMDQ_P(0));
> 
>   return min_t(int, ret, 0);
> }
> 

Hi Joe,

Thanks for the review.  I'll make those changes and get a v2 resubmitted.

Thanks,
Tony