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  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]
Date:   Wed, 9 Sep 2020 20:48:07 +0000
From:   Saeed Mahameed <saeedm@...dia.com>
To:     "kuba@...nel.org" <kuba@...nel.org>
CC:     "davem@...emloft.net" <davem@...emloft.net>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "tariqt@...lanox.com" <tariqt@...lanox.com>,
        "maximmi@...lanox.com" <maximmi@...lanox.com>
Subject: Re: [net-next V2 03/12] net/mlx5e: Move mlx5e_tx_wqe_inline_mode to
 en_tx.c

On Wed, 2020-09-09 at 12:28 -0700, Jakub Kicinski wrote:
> On Wed, 9 Sep 2020 19:22:02 +0000 Saeed Mahameed wrote:
> > On Tue, 2020-09-08 at 20:29 -0700, David Miller wrote:
> > > From: David Miller <davem@...emloft.net>
> > > Date: Tue, 08 Sep 2020 20:28:36 -0700 (PDT)
> > >   
> > > > From: Saeed Mahameed <saeedm@...dia.com>
> > > > Date: Tue, 8 Sep 2020 18:27:48 -0700
> > > >   
> > > > > --- a/drivers/net/ethernet/mellanox/mlx5/core/en_tx.c
> > > > > +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_tx.c
> > > > > @@ -232,6 +232,29 @@ mlx5e_txwqe_build_dsegs(struct
> > > > > mlx5e_txqsq
> > > > > *sq, struct sk_buff *skb,
> > > > >  	return -ENOMEM;
> > > > >  }
> > > > >  
> > > > > +static inline bool mlx5e_transport_inline_tx_wqe(struct
> > > > > mlx5_wqe_ctrl_seg *cseg)
> > > > > +{
> > > > > +	return cseg && !!cseg->tis_tir_num;
> > > > > +}
> > > > > +
> > > > > +static inline u8
> > > > > +mlx5e_tx_wqe_inline_mode(struct mlx5e_txqsq *sq, struct
> > > > > mlx5_wqe_ctrl_seg *cseg,
> > > > > +			 struct sk_buff *skb)
> > > > > +{  
> > > > 
> > > > No inlines in foo.c files, please.  
> > > 
> > > I see you're doing this even more later in this series.
> > > 
> > > Please fix all of this up, thank you.  
> > 
> > Maxim really tried here to avoid this without huge performance
> > degradation (~6.4% reduce in packet rate), due to the refactoring
> > patches gcc yields non optimal code, as we explained in the commit
> > messages and cover-letter
> > 
> > Our other option is making the code very ugly with no code reuse in
> > the
> > tx path, so we would really appreciate if you could relax the no-
> > inline 
> > guideline for this series.
> 
> Why are you requesting a whole pass on the series when only _some_
> inlines make a difference here?

I meant for the inilines that are necessary to avoid the performance
drop, Maxim can make the change and remove the unnecessary inline
functions if it is ok with You and Dave.


Powered by blists - more mailing lists