[dpdk-dev,1/2] ethdev: add function to adjust number of descriptors
Checks
Commit Message
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>
---
lib/librte_ether/rte_ethdev.c | 37 ++++++++++++++++++++++++++++++++++
lib/librte_ether/rte_ethdev.h | 20 ++++++++++++++++++
lib/librte_ether/rte_ether_version.map | 7 +++++++
3 files changed, 64 insertions(+)
Comments
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.
Why not just allow devices to take the request as a hint and truncate or pad
as needed.
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.
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.
> 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.
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.
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.
@@ -3472,3 +3472,40 @@ rte_eth_dev_l2_tunnel_offload_set(uint8_t port_id,
-ENOTSUP);
return (*dev->dev_ops->l2_tunnel_offload_set)(dev, l2_tunnel, mask, en);
}
+
+static void
+rte_eth_dev_adjust_nb_desc(uint16_t *nb_desc,
+ const struct rte_eth_desc_lim *desc_lim)
+{
+ if (desc_lim->nb_align != 0)
+ *nb_desc = RTE_ALIGN_CEIL(*nb_desc, desc_lim->nb_align);
+
+ if (desc_lim->nb_max != 0)
+ *nb_desc = RTE_MIN(*nb_desc, desc_lim->nb_max);
+
+ *nb_desc = RTE_MAX(*nb_desc, desc_lim->nb_min);
+}
+
+int
+rte_eth_dev_adjust_nb_rx_tx_desc(uint8_t port_id,
+ uint16_t *nb_rx_desc,
+ uint16_t *nb_tx_desc)
+{
+ struct rte_eth_dev *dev;
+ struct rte_eth_dev_info dev_info;
+
+ RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
+
+ dev = &rte_eth_devices[port_id];
+ RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->dev_infos_get, -ENOTSUP);
+
+ rte_eth_dev_info_get(port_id, &dev_info);
+
+ if (nb_rx_desc != NULL)
+ rte_eth_dev_adjust_nb_desc(nb_rx_desc, &dev_info.rx_desc_lim);
+
+ if (nb_tx_desc != NULL)
+ rte_eth_dev_adjust_nb_desc(nb_tx_desc, &dev_info.tx_desc_lim);
+
+ return 0;
+}
@@ -4609,6 +4609,26 @@ rte_eth_dev_get_port_by_name(const char *name, uint8_t *port_id);
int
rte_eth_dev_get_name_by_port(uint8_t port_id, char *name);
+/**
+ * Check that numbers of Rx and Tx descriptors satisfy descriptors limits from
+ * the ethernet device information, otherwise adjust them to boundaries.
+ *
+ * @param port_id
+ * The port identifier of the Ethernet device.
+ * @param nb_rx_desc
+ * A pointer to a uint16_t where the number of receive
+ * descriptors stored.
+ * @param nb_tx_desc
+ * A pointer to a uint16_t where the number of transmit
+ * descriptors stored.
+ * @return
+ * - (0) if successful.
+ * - (-ENOTSUP, -ENODEV or -EINVAL) on failure.
+ */
+int rte_eth_dev_adjust_nb_rx_tx_desc(uint8_t port_id,
+ uint16_t *nb_rx_desc,
+ uint16_t *nb_tx_desc);
+
#ifdef __cplusplus
}
#endif
@@ -156,3 +156,10 @@ DPDK_17.05 {
rte_eth_xstats_get_names_by_id;
} DPDK_17.02;
+
+DPDK_17.08 {
+ global:
+
+ rte_eth_dev_adjust_nb_rx_tx_desc;
+
+} DPDK_17.05;