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.carls...@tietoevry.com> > Sent: Wednesday, October 2, 2024 12:05 PM > To: Stephen Hemminger <step...@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 <step...@networkplumber.org> > Sent: Wednesday, October 2, 2024 5:29 PM > To: Mikael R Carlsson <mikael.r.carls...@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.carls...@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.
