[dpdk-dev] [RFC 19.11 v2 1/3] ethdev: hide key ethdev structures from public API

Bruce Richardson bruce.richardson at intel.com
Tue Sep 10 12:06:59 CEST 2019


On Tue, Sep 10, 2019 at 09:59:51AM +0000, Zapolski, MarcinX A wrote:
> <...>
> > @@ -3994,7 +4054,55 @@ void *
> >  rte_eth_dev_get_sec_ctx(uint16_t port_id);
> > 
> > 
> > -#include <rte_ethdev_core.h>
> > +struct rte_eth_dev_callback;
> > +/** Structure to keep track of registered callbacks */
> > +TAILQ_HEAD(rte_eth_dev_cb_list, rte_eth_dev_callback);
> > +
> > +/**
> > + * Structure used to hold information about the callbacks to be called for a
> > + * queue on RX and TX.
> > + */
> > +struct rte_eth_rxtx_callback {
> > +	struct rte_eth_rxtx_callback *next;
> > +	union{
> > +		rte_rx_callback_fn rx;
> > +		rte_tx_callback_fn tx;
> > +	} fn;
> > +	void *param;
> > +};
> > +
> > +/**
> > + * The generic data structure associated with each ethernet device.
> > + *
> > + * Pointers to burst-oriented packet receive and transmit functions are
> > + * located at the beginning of the structure, along with the pointer to
> > + * where all the data elements for the particular device are stored in shared
> > + * memory. This split allows the function pointer and driver data to be per-
> > + * process, while the actual configuration data for the device is shared.
> > + */
> I would like to raise one more concern (maybe not the smartest thing to do
> involving my own patch, but I will sleep better when this is resolved).
> Does anyone know what the author of this comment had in mind? I could not find
> any code that utilizes this split, and this patch clearly breaks it. If it is
> obsolete, I guess this comment could be removed.

As the comment suggest the split is for multi-process suport. The data
structures for the RX/TX queues etc. all need to be common across
processes, while the function pointers need to be per-process. Originally,
in very early versions of DPDK there was no rte_eth_dev_data structure, all
fields - both data and function pointers - were in rte_eth_dev itself.

/Bruce


More information about the dev mailing list