netdev - RE: [PATCH v3 1/6] net: fec: Factorize the .xmit transmit function

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: <f3588131770d48dbbfa8387db06d6c23@BLUPR03MB373.namprd03.prod.outlook.com>
Date:	Thu, 5 Jun 2014 10:21:37 +0000
From:	"fugang.duan@...escale.com" <fugang.duan@...escale.com>
To:	David Laight <David.Laight@...LAB.COM>,
	"davem@...emloft.net" <davem@...emloft.net>
CC:	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"shawn.guo@...aro.org" <shawn.guo@...aro.org>,
	"Fabio.Estevam@...escale.com" <Fabio.Estevam@...escale.com>,
	"ezequiel.garcia@...e-electrons.com" 
	<ezequiel.garcia@...e-electrons.com>,
	"bhutchings@...arflare.com" <bhutchings@...arflare.com>,
	"stephen@...workplumber.org" <stephen@...workplumber.org>,
	"Frank.Li@...escale.com" <Frank.Li@...escale.com>,
	"eric.dumazet@...il.com" <eric.dumazet@...il.com>
Subject: RE: [PATCH v3 1/6] net: fec: Factorize the .xmit transmit function

Hi, David,

From: David Laight David.Laight@...LAB.COM> Data: Thursday, June 05, 2014 5:58 PM
> To: Duan Fugang-B38611; davem@...emloft.net
> Cc: netdev@...r.kernel.org; shawn.guo@...aro.org; Estevam Fabio-R49496;
> ezequiel.garcia@...e-electrons.com; bhutchings@...arflare.com;
> stephen@...workplumber.org; Li Frank-B20596; eric.dumazet@...il.com
> Subject: RE: [PATCH v3 1/6] net: fec: Factorize the .xmit transmit
> function
> 
> From: fugang.duan@...escale.
> > > From: Fugang Duan
> > > > Make the code more readable and easy to support other features
> > > > like SG, TSO, moving the common transmit function to one api.
> > > >
> > > > And the patch also factorize the getting BD index to it own
> function.
> > > >
> > > > Signed-off-by: Fugang Duan <B38611@...escale.com>
> > > > ---
> > > >  drivers/net/ethernet/freescale/fec_main.c |   87
> ++++++++++++++++++-----
> > > ------
> > > >  1 files changed, 54 insertions(+), 33 deletions(-)
> > > >
> > > > diff --git a/drivers/net/ethernet/freescale/fec_main.c
> > > > b/drivers/net/ethernet/freescale/fec_main.c
> > > > index 802be17..32c2276 100644
> > > > --- a/drivers/net/ethernet/freescale/fec_main.c
> > > > +++ b/drivers/net/ethernet/freescale/fec_main.c
> > > > @@ -287,6 +287,25 @@ struct bufdesc *fec_enet_get_prevdesc(struct
> > > > bufdesc
> > > *bdp, struct fec_enet_priva
> > > >  		return (new_bd < base) ? (new_bd + ring_size) :
> new_bd;  }
> > > >
> > > > +static inline
> > > > +int fec_enet_get_bd_index(struct bufdesc *bdp, struct
> > > > +fec_enet_private *fep) {
> > > > +	struct bufdesc *base;
> > > > +	int index;
> > > > +
> > > > +	if (bdp >= fep->tx_bd_base)
> > > > +		base = fep->tx_bd_base;
> > > > +	else
> > > > +		base = fep->rx_bd_base;
> > >
> > > You really don't want the above conditional.
> > > It is known from the call site - but the compiler can't determine
> > > that and remove the test.
> 
> > Can you give me more training for this ?  Sorry, I don't understand
> the means.
> 
> Single 'if' statements can have measurable performance impact on
> ethernet code paths - so it isn't a good idea to add ones that aren't
> strictly required.
> 
> If the function had an extra argument 'tx_ring' (don't add one) which
> would be constant at all the call sites and the code read:
> 	base = tx_ring ? fep->tx_bd_base : fep->rx_bd_base; when the
> compiler inlines the function calls it would be able to optimise away
> the conditional.
> 
> > > You may not want to rely on the tx and rx descriptors being
> > > allocated as a single entity - particularly now that they (probably)
> > > consume more than a single page.
> > >
> > BDs consumes more than single page, but it use "
> dma_alloc_coherent()"
> > to allocate continuous memory, I don't know why it is cannot do it
> like this.
> >
> > > > +
> > > > +	if (fep->bufdesc_ex)
> > > > +		index = (struct bufdesc_ex *)bdp - (struct bufdesc_ex
> *)base;
> > > > +	else
> > > > +		index = bdp - base;
> > >
> > > Save the sizeof the descriptor structure as (say) fep->bufdesc_size
> > > (Possibly replacing bufdesc_ex) and then just calculate:
> > > 	index = ((const char *)bdp - (const char *)base)/fep-
> >bufdesc_size;
> > >
> > > 	David
> > >
> > You means:
> > if (fep->bufdesc_ex)
> > 	bufdesc_size = sizeof(struct bufdesc_ex); else
> > 	bufdesc_size = sizeof(struct bufdesc); index = ((const char *)bdp
> -
> > (const char *)base)/bufdesc_size;
> 
> No, that is still a conditional in the normal path.
> Assign fep->bufdesc_size during initialisation.
> 
> Then end up with something like:
> static
> int fec_enet_get_bd_index(struct bufdesc *base, struct bufdesc *bdp,
> 		struct fec_enet_private *fep)
> {
> 	return ((const char *)bdp - (const char *)base)/fep-
> >bufdesc_size; }
> 
> 	David
> 

You think the conditional has measurable performance impact on ethernet code paths, I agree your thinking.
But in the driver, there have many site/apis use the method. 

So, I don't want to change it for the patch set.  It have no meaningful.
I will submit another patch to solve all APIs with conditional for the driver.

Thanks,
Andy
--
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