[dpdk-dev] [PATCH v4 1/2] librte_ether: add internal callback functions

Iremonger, Bernard bernard.iremonger at intel.com
Wed Oct 5 19:04:49 CEST 2016


Hi Thomas,

<snip>

> Subject: Re: [dpdk-dev] [PATCH v4 1/2] librte_ether: add internal callback
> functions
> 
> 2016-10-04 15:52, Bernard Iremonger:
> > add _rte_eth_dev_callback_process_vf function.
> > add _rte_eth_dev_callback_process_generic function
> >
> > Adding a callback to the user application on VF to PF mailbox message,
> > allows passing information to the application controlling the PF when
> > a VF mailbox event message is received, such as VF reset.
> 
> I have some difficulties to parse this explanation.
> Please could you reword it and precise the direction of the message and the
> use case context?

I will reword the explanation and add use case context.
 
> > --- a/lib/librte_ether/rte_ethdev.c
> > +++ b/lib/librte_ether/rte_ethdev.c
> > @@ -2510,6 +2510,20 @@ void
> >  _rte_eth_dev_callback_process(struct rte_eth_dev *dev,
> >  	enum rte_eth_event_type event)
> >  {
> > +	return _rte_eth_dev_callback_process_generic(dev, event, NULL); }
> > +
> > +void
> > +_rte_eth_dev_callback_process_vf(struct rte_eth_dev *dev,
> > +	enum rte_eth_event_type event, void *param) {
> > +	return _rte_eth_dev_callback_process_generic(dev, event, param);
> }
> 
> This function is just adding a parameter, compared to the legacy
> _rte_eth_dev_callback_process.
> Why calling it process_vf?

The parameter is just being added for the VF event, the handling of the other events is unchanged.

> And by the way, why not just replacing the legacy function?
> As it is a driver interface, there is no ABI restriction.

I thought there would be an ABI issue if the legacy function is replaced.
The _rte_eth_dev_callback_process is exported in DPDK 2.2 and used in the following PMD's, lib and app:

app/test/virtual_pmd
drivers/net/e1000
drivers/net/ixgbe
drivers/net/mlx5
drivers/net/vhost
drivers/net/virtio
lib/librte_ether

 Adding a parameter to _rte_eth_dev_callback_process()  will impact all of the above.
Will this cause an ABI issue?

> > +
> > +void
> > +_rte_eth_dev_callback_process_generic(struct rte_eth_dev *dev,
> > +	enum rte_eth_event_type event, void *param) {
> [...]
> > --- a/lib/librte_ether/rte_ethdev.h
> > +++ b/lib/librte_ether/rte_ethdev.h
> > @@ -3026,6 +3026,7 @@ enum rte_eth_event_type {
> >  				/**< queue state event (enabled/disabled)
> */
> >  	RTE_ETH_EVENT_INTR_RESET,
> >  			/**< reset interrupt event, sent to VF on PF reset */
> > +	RTE_ETH_EVENT_VF_MBOX,  /**< PF mailbox processing callback */
> >  	RTE_ETH_EVENT_MAX       /**< max value of this enum */
> >  };
> 
> Either we choose to have a "generic" VF event well documented, or it is just
> a specific event with a tip on where to find the doc.
> Here we need at least to know how to handle the argument.

It is a specific event for VF to PF messages, details on the function and arguments are in the rte_ethdev.h file.
 
> > +/**
> > + * @internal Executes all the user application registered callbacks. Used
> by:
> > + * _rte_eth_dev_callback_process and
> _rte_eth_dev_callback_process_vf
> > + * It is for DPDK internal user only. User application should not
> > +call it
> > + * directly.
> > + *
> > + * @param dev
> > + *  Pointer to struct rte_eth_dev.
> > + * @param event
> > + *  Eth device interrupt event type.
> > + *
> > + * @param param
> > + *  parameters to pass back to user application.
> > + *
> > + * @return
> > + *  void
> > + */
> > +void
> > +_rte_eth_dev_callback_process_generic(struct rte_eth_dev *dev,
> > +				enum rte_eth_event_type event, void
> *param);
> 
> This is really an internal function and should not be exported at all.

Both new functions are internal I  will make them static and remove them from the map file.
When the functions are made static, should the function declarations be moved from rte_ethdev.h to rte_ethdev.c ?

Thanks for the review.

Regards,

Bernard.



More information about the dev mailing list