On Thu, Nov 21, 2019 at 5:45 PM Stephen Hemminger
<step...@networkplumber.org> wrote:
>
> On Thu, 21 Nov 2019 16:12:55 +0100
> David Marchand <david.march...@redhat.com> wrote:
>
> > -     uint16_t                nb_rx_desc[MAX_QUEUE_ID+1]; /**< per queue rx 
> > desc number */
> > -     uint16_t                nb_tx_desc[MAX_QUEUE_ID+1]; /**< per queue tx 
> > desc number */
> > -     struct rte_eth_rxconf   rx_conf[MAX_QUEUE_ID+1]; /**< per queue rx 
> > configuration */
> > -     struct rte_eth_txconf   tx_conf[MAX_QUEUE_ID+1]; /**< per queue tx 
> > configuration */
> > +     uint16_t                nb_rx_desc[RTE_MAX_QUEUES_PER_PORT+1]; /**< 
> > per queue rx desc number */
> > +     uint16_t                nb_tx_desc[RTE_MAX_QUEUES_PER_PORT+1]; /**< 
> > per queue tx desc number */
> > +     struct rte_eth_rxconf   rx_conf[RTE_MAX_QUEUES_PER_PORT+1]; /**< per 
> > queue rx configuration */
> > +     struct rte_eth_txconf   tx_conf[RTE_MAX_QUEUES_PER_PORT+1]; /**< per 
> > queue tx configuration */
>
> Why not  put all the per-queue stuff together in one structure
> and put it at the end. Then dynamically size based on number of queues?

This is something that could be done.
At first glance, the code is relying on those arrays being contiguous,
but it should not be a problem.
The reason for the size '+1' is not obvious to me.
Not saying that would be difficult to investigate and fix/rework all this.

My approach seems the quickest and less risky after rc3.
I can look at this post 19.11 (but volunteers are welcome, testpmd
needs some love).


-- 
David Marchand

Reply via email to