[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AM4PR04MB16040D32960405FD16007950ECBC0@AM4PR04MB1604.eurprd04.prod.outlook.com>
Date: Mon, 14 Nov 2016 10:25:13 +0000
From: Madalin-Cristian Bucur <madalin.bucur@....com>
To: David Miller <davem@...emloft.net>
CC: "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"oss@...error.net" <oss@...error.net>,
"ppc@...dchasers.com" <ppc@...dchasers.com>,
"joe@...ches.com" <joe@...ches.com>,
"pebolle@...cali.nl" <pebolle@...cali.nl>,
"joakim.tjernlund@...inera.com" <joakim.tjernlund@...inera.com>
Subject: RE: [PATCH net-next v7 03/10] dpaa_eth: add option to use one buffer
pool set
> From: David Miller [mailto:davem@...emloft.net]
> Sent: Sunday, November 13, 2016 7:46 PM
>
> From: Madalin Bucur <madalin.bucur@....com>
> Date: Fri, 11 Nov 2016 10:20:00 +0200
>
> > @@ -8,3 +8,12 @@ menuconfig FSL_DPAA_ETH
> > supporting the Freescale QorIQ chips.
> > Depends on Freescale Buffer Manager and Queue Manager
> > driver and Frame Manager Driver.
> > +
> > +if FSL_DPAA_ETH
> > +config FSL_DPAA_ETH_COMMON_BPOOL
> > + bool "Use a common buffer pool set for all the interfaces"
> > + ---help---
> > + The DPAA Ethernet netdevices require buffer pools for storing the
> buffers
> > + used by the FMan hardware for reception. One can use a single
> buffer pool
> > + set for all interfaces or a dedicated buffer pool set for each
> interface.
> > +endif # FSL_DPAA_ETH
>
> This in no way belongs in Kconfig. If you want to support this,
> support it wit a run time configuration choice via ethtool flags
> or similar. Do not use debugfs, do not use sysfs, do not use
> module options.
>
> If you put it in Kconfig, distributions will have to pick one way or
> another which means that users who want the other choice lose. This
> never works.
I've introduced this Kconfig option as a backwards compatible option, to
be able to run comparative tests between the independent buffer pool setup
and the previous common buffer pool setup. There are not so many reasons
to use the same buffer pool besides "having the old setup", the memory
saving is marginal, in all other aspects the separate buffer pools setup
fares better.
I'll remove this patch from the next submission. Should anyone care for
this I can add an entry to the feature backlog to add runtime support but
it will be quite low in priority.
Thank you for your review.
Madalin
Powered by blists - more mailing lists