From: "Wang, Haiyue" <haiyue.wang@intel.com>
To: "Zhang, AlvinX" <alvinx.zhang@intel.com>, "Guo, Jia" <jia.guo@intel.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>, "stable@dpdk.org" <stable@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH] net/igc: fix Rx packet size error
Date: Mon, 19 Apr 2021 07:43:19 +0000 [thread overview]
Message-ID: <BN8PR11MB3795EAEE4966A6365C1A6A9CF7499@BN8PR11MB3795.namprd11.prod.outlook.com> (raw)
In-Reply-To: <DM6PR11MB389855F1AE23900A908E35079F499@DM6PR11MB3898.namprd11.prod.outlook.com>
> -----Original Message-----
> From: Zhang, AlvinX <alvinx.zhang@intel.com>
> Sent: Monday, April 19, 2021 15:15
> To: Wang, Haiyue <haiyue.wang@intel.com>; Guo, Jia <jia.guo@intel.com>
> Cc: dev@dpdk.org; stable@dpdk.org
> Subject: RE: [PATCH] net/igc: fix Rx packet size error
>
> Hi Haiyue,
>
> Thanks for your review.
>
> > -----Original Message-----
> > From: Wang, Haiyue <haiyue.wang@intel.com>
> > Sent: Friday, April 16, 2021 9:57 AM
> > To: Zhang, AlvinX <alvinx.zhang@intel.com>; Guo, Jia <jia.guo@intel.com>
> > Cc: dev@dpdk.org; stable@dpdk.org
> > Subject: RE: [PATCH] net/igc: fix Rx packet size error
> >
> > > -----Original Message-----
> > > From: Zhang, AlvinX <alvinx.zhang@intel.com>
> > > Sent: Friday, April 16, 2021 09:14
> > > To: Wang, Haiyue <haiyue.wang@intel.com>; Guo, Jia <jia.guo@intel.com>
> > > Cc: dev@dpdk.org; Zhang, AlvinX <alvinx.zhang@intel.com>;
> > > stable@dpdk.org
> > > Subject: [PATCH] net/igc: fix Rx packet size error
> > >
> > > When DEV_RX_OFFLOAD_KEEP_CRC is enabled, the PMD will minus 4 bytes of
> > > CRC from the size of a packet, but the NIC will strip the CRC because
> > > the CRC strip bit in DVMOLR register is not cleared. This will cause
> > > the size of a packet to be 4 bytes less.
> > >
> > > This patch updates the CRC strip bit according to whether
> > > DEV_RX_OFFLOAD_KEEP_CRC is enabled.
> > >
> > > Fixes: a5aeb2b9e225 ("net/igc: support Rx and Tx")
> > > Cc: stable@dpdk.org
> > >
> > > Signed-off-by: Alvin Zhang <alvinx.zhang@intel.com>
> > > ---
> > > drivers/net/igc/igc_txrx.c | 22 +++++++++++++---------
> > > 1 file changed, 13 insertions(+), 9 deletions(-)
> > >
> > > diff --git a/drivers/net/igc/igc_txrx.c b/drivers/net/igc/igc_txrx.c
> > > index c0a5d5e..68b102d 100644
> > > --- a/drivers/net/igc/igc_txrx.c
> > > +++ b/drivers/net/igc/igc_txrx.c
> > > @@ -1290,20 +1290,24 @@ int eth_igc_rx_descriptor_status(void *rx_queue,
> > uint16_t offset)
> > > * This needs to be done after enable.
> > > */
> > > for (i = 0; i < dev->data->nb_rx_queues; i++) {
> > > + uint32_t dvmolr;
> > > +
> > > rxq = dev->data->rx_queues[i];
> > > IGC_WRITE_REG(hw, IGC_RDH(rxq->reg_idx), 0);
> > > - IGC_WRITE_REG(hw, IGC_RDT(rxq->reg_idx),
> > > - rxq->nb_rx_desc - 1);
> > > + IGC_WRITE_REG(hw, IGC_RDT(rxq->reg_idx), rxq->nb_rx_desc - 1);
> > > +
> > > + dvmolr = IGC_READ_REG(hw, IGC_DVMOLR(rxq->queue_id));
> > >
> > > /* strip queue vlan offload */
> > > - if (rxq->offloads & DEV_RX_OFFLOAD_VLAN_STRIP) {
> > > - uint32_t dvmolr;
> > > - dvmolr = IGC_READ_REG(hw, IGC_DVMOLR(rxq->queue_id));
> > > + dvmolr = (rxq->offloads & DEV_RX_OFFLOAD_VLAN_STRIP) ?
> > > + (dvmolr | IGC_DVMOLR_STRVLAN) :
> > > + (dvmolr & ~IGC_DVMOLR_STRVLAN);
> >
> > Just use "if ... else .."to make code readable:
> >
> > if (rxq->offloads & DEV_RX_OFFLOAD_VLAN_STRIP)
> > dvmolr |= IGC_DVMOLR_STRVLAN;
> > else
> > dvmolr &= ~IGC_DVMOLR_STRVLAN;
> >
> >
> > >
> > > - /* If vlan been stripped off, the CRC is meaningless. */
> >
> > Looks like we need to handle CRC & VLAN_STRIP co-exist issue:
> > If user enables VLAN strip, then keep CRC should be rejected,
> > and vice versa.
>
> By default, the DEV_RX_OFFLOAD_KEEP_CRC does not been set,
> so if the user set the DEV_RX_OFFLOAD_KEEP_CRC and DEV_RX_OFFLOAD_VLAN_STRIP bits,
> this means the user really need CRC and VLAN stripped off, although the CRC is meaningless at this
> situation.
> So can we issue some warnings instead of changing the user's settings?
I re-think it again, no need to handle this now, until user complains about something.
Let's just fix the code style issue. ;-)
>
> >
> > > - dvmolr |= IGC_DVMOLR_STRVLAN | IGC_DVMOLR_STRCRC;
> > > - IGC_WRITE_REG(hw, IGC_DVMOLR(rxq->reg_idx), dvmolr);
> > > - }
> > > + dvmolr = (offloads & DEV_RX_OFFLOAD_KEEP_CRC) ?
> > > + (dvmolr & ~IGC_DVMOLR_STRCRC) :
> > > + (dvmolr | IGC_DVMOLR_STRCRC);
> >
> > Just use "if ... else .."to make code readable:
> >
> > if (offloads & DEV_RX_OFFLOAD_KEEP_CRC)
> > dvmolr &= ~IGC_DVMOLR_STRCRC;
> > else
> > dvmolr |= IGC_DVMOLR_STRCRC;
> >
> > > +
> > > + IGC_WRITE_REG(hw, IGC_DVMOLR(rxq->reg_idx), dvmolr);
> > > }
> > >
> > > return 0;
> > > --
> > > 1.8.3.1
next prev parent reply other threads:[~2021-04-19 7:43 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-16 1:14 Alvin Zhang
2021-04-16 1:57 ` Wang, Haiyue
2021-04-19 7:14 ` Zhang, AlvinX
2021-04-19 7:43 ` Wang, Haiyue [this message]
2021-04-20 2:05 ` [dpdk-dev] [PATCH v2] " Alvin Zhang
2021-04-20 2:31 ` Wang, Haiyue
2021-04-21 11:46 ` Zhang, Qi Z
2021-04-20 9:10 ` Chen, LingliX
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=BN8PR11MB3795EAEE4966A6365C1A6A9CF7499@BN8PR11MB3795.namprd11.prod.outlook.com \
--to=haiyue.wang@intel.com \
--cc=alvinx.zhang@intel.com \
--cc=dev@dpdk.org \
--cc=jia.guo@intel.com \
--cc=stable@dpdk.org \
/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).