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

Thomas Monjalon thomas at monjalon.net
Thu Jul 6 01:00:57 CEST 2017


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 at solarflare.com> wrote:
> >
> >> From: Roman Zhukov <Roman.Zhukov at 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 at oktetlabs.ru>
> >> Signed-off-by: Andrew Rybchenko <arybchenko at 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.


More information about the dev mailing list