[dpdk-dev] A question about (poor) rte_ethdev internal rx/tx callbacks design

Adrien Mazarguil adrien.mazarguil at 6wind.com
Mon Nov 13 11:39:27 CET 2017


On Sat, Nov 11, 2017 at 09:18:45PM +0400, Ilya Matveychikov wrote:
> Folks,
> 
> Are you serious with it:
> 
> typedef uint16_t (*eth_rx_burst_t)(void *rxq,
> 				   struct rte_mbuf **rx_pkts,
> 				   uint16_t nb_pkts);
> typedef uint16_t (*eth_tx_burst_t)(void *txq,
> 				   struct rte_mbuf **tx_pkts,
> 				   uint16_t nb_pkts);
> 
> I’m not surprised that every PMD stores port_id in every and each queue as having just the queue as an argument doesn’t allow to get the device. So the question is - why not to use something like:
> 
> typedef uint16_t (*eth_rx_burst_t)(void *dev, uint16_t queue_id,
> 				   struct rte_mbuf **rx_pkts,
> 				   uint16_t nb_pkts);
> typedef uint16_t (*eth_tx_burst_t)(void *dev, uint16_t queue_id,
> 				   struct rte_mbuf **tx_pkts,
> 				   uint16_t nb_pkts);

I assume it's since the rte_eth_[rt]x_burst() wrappers already pay the price
for that indirection, doing it twice would be redundant.

Basically the cost of storing a back-pointer to dev or a queue index in each
Rx/Tx queue structure is minor compared to saving a couple of CPU cycles
wherever we can.

I'm not saying its the only solution nor the right approach, it's only one
possible explanation for this API.

-- 
Adrien Mazarguil
6WIND


More information about the dev mailing list