Re: [dpdk-dev] [PATCH 1/2] ethdev: add function to adjust number of descriptors

[Thomas Monjalon <thomas@monjalon.net>]

06/07/2017 01:00, Thomas Monjalon:
> 14/06/2017 12:37, Andrew Rybchenko:
> > On 05/25/2017 08:40 PM, Stephen Hemminger wrote:
> > > On Thu, 25 May 2017 16:57:53 +0100
> > > Andrew Rybchenko <arybchenko@solarflare.com> wrote:
> > >
> > >> From: Roman Zhukov <Roman.Zhukov@oktetlabs.ru>
> > >>
> > >> Check that numbers of Rx and Tx descriptors satisfy descriptors limits
> > >> from the Ethernet device information, otherwise adjust them to boundaries.
> > >>
> > >> Signed-off-by: Roman Zhukov <Roman.Zhukov@oktetlabs.ru>
> > >> Signed-off-by: Andrew Rybchenko <arybchenko@solarflare.com>
> > > Seems like new added complexity.
> > 
> > It looks like there is no more comments.
> > 
> > > Why not just allow devices to take the request as a hint and truncate or pad
> > > as needed.
> > 
> > Yes, it is possible solution. In this case rte_eth_rx_queue_info_get() 
> > may be used
> > to get real values. If so, first of all it should be clearly documented 
> > in the
> > rte_eth_rx_queue_setup()/rte_eth_tx_queue_setup() and
> > rte_eth_rx_queue_info_get()/rte_eth_tx_queue_info_get().
> > However, the problem of such approach is non-obvious modification of
> > values specified by the ethdev API caller. Some applications use ring sizes
> > to estimate mbuf pool size and other resources and if real values differ
> > from specified (and it is not taken into account since everything happens
> > silently without any errors) it could be tricky to find out root cause of
> > possible problems. That's why we have chosen approach with extra
> > helper function which does the adjustment.
> 
> Any more comment on this?
> If not, it will be applied soon.
> 
> > > IMHO to be successful DPDK must have as simple as possible API for application.
> > > Good enough and as little more as possible. But other people seem to think
> > > that having the richest and most complex possible API is a good thing.
> 
> I agree it is better to have a simple API.
> However the community process is in favor of code writers.
> We cannot reject a solution if there is no other solution proposed in
> a reasonnable timeframe.

Applied, because we have no better alternative for now,
and it is discussed since March.