DPDK patches and discussions
 help / color / mirror / Atom feed
From: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>
To: "Xing, Beilei" <beilei.xing@intel.com>, "dev@dpdk.org" <dev@dpdk.org>
Cc: Feifei Wang <Feifei.Wang2@arm.com>,
	Ruifeng Wang <Ruifeng.Wang@arm.com>,
	"Yigit, Ferruh" <ferruh.yigit@intel.com>,
	"Richardson, Bruce" <bruce.richardson@intel.com>, nd <nd@arm.com>,
	nd <nd@arm.com>
Subject: RE: Questions on i40e TX path
Date: Fri, 11 Feb 2022 04:07:50 +0000	[thread overview]
Message-ID: <DBAPR08MB5814EA4186B768FC53C38BDE98309@DBAPR08MB5814.eurprd08.prod.outlook.com> (raw)
In-Reply-To: <DM6PR11MB3098F81D1AD8055D9652A561F7309@DM6PR11MB3098.namprd11.prod.outlook.com>

<snip>

> >
> > Thank you for your input. Please see few comments inline.
> >
> > > > Subject: Questions on i40e TX path
> > > >
> > > > Hi Beilei,
> > > > 	I want to make sure my understanding of the TX path is correct.
> > > > Following is my understanding.
> > > >
> > > > 1) The RS bit must be set in the TX descriptors to ask the NIC to
> > > > report back the send status.
> > > Not for each Tx descriptor.
> > > According to the datasheet, " The RS flag can be set only on a last
> > > Transmit Data Descriptor of a packet or last Transmit Data
> > > Descriptor of a TSO or last Transmit Data Descriptor of a filter."
> > Yes, understood.
> > When combined with #2 below, we are asking the NIC to report back the
> > send/completion status for a set of packets. This allows for
> > amortization of cost of reporting over the set of packets.
> >
> > >
> > > > 2) The NIC reports the send completion by setting the DTYPE field
> > > > to 0xf. This also indicates that all the earlier descriptors are
> > > > also done sending
> > > the packets.
> > > Yes.
> > >
> > > > 3) The check "if (txq->nb_tx_free < txq->tx_free_thresh)" is
> > > > mainly to ensure that we do not check the "descriptor done" status too
> often.
> > > This condition is to ensure there're enough free descriptors for Tx,
> > > avoid Tx ring full.
> > Ok. I think this check has another purpose as well, though I am not
> > sure if it is intentional. I see that the descriptors are initialized
> > with DTYPE set to 0xF (in function i40e_reset_tx_queue). So, in the
> > very first call to transmit function (for
> > ex: i40e_xmit_fixed_burst_vec), the 'i40e_tx_free_bufs' function would
> > end up checking the DTYPE field, if the above check was not there.
> >
> > In the data sheet, in section 8.4.2.1.1 (transmit data descriptor
> > format), the RS field is described as follows:
> >
> > " Report Status. When set, the hardware reports the DMA completion of
> > the transmit descriptor and its data buffer. Completion is reported by
> > descriptor write back or by head write back as configured by the
> > HEAD_WBEN flag in the transmit context. When it is reported by
> > descriptor write back, the DTYP field is set to 0xF and the RS flag is set."
> >
> > Considering the last sentence, should the code check for both DTYP
> > field and RS field for completion? Currently, the code checks for just
> > the DTYP field (in the function i40e_tx_free_bufs).
> 
> In my understanding, RS bit is set by SW to indicate HW needs to write back. So
> I don't think PMD needs to check RS bit.
> Besides, PMD should have ensured PMD checks DTYPE of the descriptor with RS
> bit only.
This is not ensured for the very first call to the transmit API. All the descriptors are initialized with DTYPE set to 0xF and the RS bit is set to 0. But the check "if (txq->nb_tx_free < txq->tx_free_thresh)" ensures we do not free these descriptors. 

> 
> >
> > >
> > > >
> > > > Is my understanding correct?
> > > >
> > > > Thank you,
> > > > Honnappa

      reply	other threads:[~2022-02-11  4:08 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-09  4:35 Honnappa Nagarahalli
2022-02-09  7:58 ` Xing, Beilei
2022-02-10  4:37   ` Honnappa Nagarahalli
2022-02-11  2:33     ` Xing, Beilei
2022-02-11  4:07       ` Honnappa Nagarahalli [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DBAPR08MB5814EA4186B768FC53C38BDE98309@DBAPR08MB5814.eurprd08.prod.outlook.com \
    --to=honnappa.nagarahalli@arm.com \
    --cc=Feifei.Wang2@arm.com \
    --cc=Ruifeng.Wang@arm.com \
    --cc=beilei.xing@intel.com \
    --cc=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=nd@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).