RE: Relation between DPDK queue and descriptors

["Pathak, Pravin" <pravin.pathak@intel.com>]

Hi Mikael -
ChatGpt provides a good description of the relation between these two. If you ask ChatGPT to do a deep dive, it will provide a good bit of programming and optimization details.
Regards
Pravin


> -----Original Message-----
> From: Mikael R Carlsson <mikael.r.carlsson@tietoevry.com>
> Sent: Wednesday, October 2, 2024 12:05 PM
> To: Stephen Hemminger <stephen@networkplumber.org>
> Cc: users@dpdk.org
> Subject: RE: Relation between DPDK queue and descriptors
> 
> Hi!
> 
> Thanks for the response.
> 
> I think I get the descriptor part, but what is the relation to queues? If the
> hardware supports 1024 descriptors and I need 6 queues, do I have 1024
> descriptors on each TX queue?
> 
>   / Mikael
> 
> 
> -----Original Message-----
> From: Stephen Hemminger <stephen@networkplumber.org>
> Sent: Wednesday, October 2, 2024 5:29 PM
> To: Mikael R Carlsson <mikael.r.carlsson@tietoevry.com>
> Cc: users@dpdk.org
> Subject: Re: Relation between DPDK queue and descriptors
> 
> On Wed, 2 Oct 2024 15:21:45 +0000
> Mikael R Carlsson <mikael.r.carlsson@tietoevry.com> wrote:
> 
> > Hi experts!
> >
> > I have a hard time to finds a good documentation about the relation
> between DPDK TX queue and descriptors.
> >
> > Queue as in rte_eth_tx_queue_setup
> > Descriptor as in rte_eth_dev_adjust_nb_rx_rx_desc
> >
> > We suspect we run out of descriptors in TX path, we are not sure here. We
> use more than one TX queue. Will we get more descriptors if we only use one
> single TX queue? Does anyone know if there is some good documentation
> regarding the TX queue and the descriptors?
> >
> >   / Mikael
> >
> 
> A typical driver has a hardware ring buffer between the driver and the
> hardware.
> One ring for transmit, and another for receive.
> The entries in the ring are hardware specific data structure called descriptors.
> Each descriptor usually has physical memory address, size, and flags.
> 
> The number of Rx descriptors determines the number of unread frames the
> driver can hold. Too small, and you risk dropping packets; too large and under
> stress load the driver can end up buffering excessively causing latency
> (bufferbloat).
> Similar on Tx but less of a problem because typically the network is faster than
> the application can send packets.