DPDK patches and discussions
 help / color / mirror / Atom feed
From: Bing Zhao <bingz@nvidia.com>
To: Ferruh Yigit <ferruh.yigit@intel.com>,
	Slava Ovsiienko <viacheslavo@nvidia.com>,
	Matan Azrad <matan@nvidia.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>, Ori Kam <orika@nvidia.com>,
	"Raslan Darawsheh" <rasland@nvidia.com>,
	"stable@dpdk.org" <stable@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH] net/mlx5: fix the eCPRI common header endianness
Date: Mon, 9 Nov 2020 06:01:51 +0000
Message-ID: <CY4PR1201MB007268B7935BA5307102C728D0EA0@CY4PR1201MB0072.namprd12.prod.outlook.com> (raw)
In-Reply-To: <7b10f95c-bd9f-afd9-8925-73552fb37c09@intel.com>

Hi Ferruh,

> -----Original Message-----
> From: Ferruh Yigit <ferruh.yigit@intel.com>
> Sent: Saturday, November 7, 2020 1:41 AM
> To: Bing Zhao <bingz@nvidia.com>; Slava Ovsiienko
> <viacheslavo@nvidia.com>; Matan Azrad <matan@nvidia.com>
> Cc: dev@dpdk.org; Ori Kam <orika@nvidia.com>; Raslan Darawsheh
> <rasland@nvidia.com>; stable@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] net/mlx5: fix the eCPRI common
> header endianness
> 
> External email: Use caution opening links or attachments
> 
> 
> On 11/6/2020 2:10 PM, Bing Zhao wrote:
> > Hi Ferruh,
> >
> > Thanks for your review and comments, PSB.
> >
> >> -----Original Message-----
> >> From: Ferruh Yigit <ferruh.yigit@intel.com>
> >> Sent: Friday, November 6, 2020 7:20 PM
> >> To: Bing Zhao <bingz@nvidia.com>; Slava Ovsiienko
> >> <viacheslavo@nvidia.com>; Matan Azrad <matan@nvidia.com>
> >> Cc: dev@dpdk.org; Ori Kam <orika@nvidia.com>; Raslan Darawsheh
> >> <rasland@nvidia.com>; stable@dpdk.org
> >> Subject: Re: [dpdk-dev] [PATCH] net/mlx5: fix the eCPRI common
> header
> >> endianness
> >>
> >> External email: Use caution opening links or attachments
> >>
> >>
> >> On 11/3/2020 5:41 AM, Bing Zhao wrote:
> >>> The input header of a RTE flow item is with network byte order.
> In
> >> the
> >>> host with little endian, the bit field order are the same as the
> >> byte
> >>> order.
> >>> When checking the an eCPRI message type, the wrong field will be
> >>> selected. Right now, since the whole u32 is being checked and
> for
> >> all
> >>> types, the following implementation is unique. There is no
> >> functional
> >>> risk but it is still an error to fix.
> >>   >
> >>
> >> Isn't the 'ecpri_v' filled by application (CPU), why there is an
> >> assumption that it is big endian?
> >>
> >
> > Yes, this is filled by the application SW. I checked the current
> code of other headers and current implementation.
> > 1. In the testpmd flow example, all the headers of network stack
> like IPv4 are translated into to be in BE, "ARGS_ENTRY_HTON"
> > 2. All fields are with "rte_be*_t"type, even though only a typedef,
> it should be considered in BE.
> > 3. RTE flow will just pass the flow items pointer to the PMD
> drivers, so in the PMD part, the headers should be treated as in BE.
> > So, to my understanding, this is not an assumption but some
> constraint.
> > Correct me if my understanding is wrong.
> 
> I missed in 'cmdline_flow.c' big endian conversion done via 'arg-
> >hton' check, so yes PMD getting big endian values makes sense,
> thanks for clarification.
> 
> >
> >> And even if it is big endian, it should be broken previously
> right?
> >> Since it was checking wrong field as 'type' as you said, why
> there
> >> were no functional risk?
> >
> > In the PMD driver, the first u32 *value containing this type is
> already used for matching. And a checking is used for the following
> "sub-headers"
> > matching. Indeed, the first u32 *mask is used to confirm if the
> following sub-header need to be matched.
> > Since different types will lead to different variants of the
> packets, the switch-of-type is used.
> > But all the 3 types supported in PMD now almost have the same
> results (part of the second u32, remaining will be all 0s).
> > So even if the type of the value is always "0" by mistake, the
> cases are the same and it still works by coincidence.
> 
> if 'type' is '0' I see it works, but what if the 'type' is something
> other than values covered in 'switch', than it may fail matching
> 'sub-headers' and I guess that can happen based on value of 'size'
> field.

Yes, it has the risk. In the past, the packet's length tested didn't expose this issue. So when it change the size upper byte to other value instead of 0/2/5, then the flow will get a failure when being created. Thanks for catching this point.

> 
> Anyway, since you are already fixing it, will you be OK if I drop
> last two sentences from the commit log and proceed?

Sure, thanks a lot for your help.

BR. Bing


      reply	other threads:[~2020-11-09  6:02 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-03  5:41 Bing Zhao
2020-11-05 15:01 ` Raslan Darawsheh
2020-11-06 11:19 ` Ferruh Yigit
2020-11-06 14:10   ` Bing Zhao
2020-11-06 17:41     ` Ferruh Yigit
2020-11-09  6:01       ` Bing Zhao [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=CY4PR1201MB007268B7935BA5307102C728D0EA0@CY4PR1201MB0072.namprd12.prod.outlook.com \
    --to=bingz@nvidia.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=matan@nvidia.com \
    --cc=orika@nvidia.com \
    --cc=rasland@nvidia.com \
    --cc=stable@dpdk.org \
    --cc=viacheslavo@nvidia.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

DPDK patches and discussions

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://inbox.dpdk.org/dev/0 dev/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 dev dev/ https://inbox.dpdk.org/dev \
		dev@dpdk.org
	public-inbox-index dev

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.dpdk.org/inbox.dpdk.dev


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git