From: Stephen Hemminger <stephen@networkplumber.org>
To: Liron Himi <lironh@marvell.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: l2/l3_len fields
Date: Mon, 24 Jan 2022 09:21:04 -0800 [thread overview]
Message-ID: <20220124092104.07db8409@hermes.local> (raw)
In-Reply-To: <PH0PR18MB4473F4E9A98B6E39E5DECA35C65E9@PH0PR18MB4473.namprd18.prod.outlook.com>
On Mon, 24 Jan 2022 08:39:59 +0000
Liron Himi <lironh@marvell.com> wrote:
> Hi,
>
>
>
> Can you please share the motivation of not filling l2/l3-len fields on PMD's RX function?
>
> PMD already filling the mbuf with parsing info, and the l2/l3-len are also probably part of the HW descriptor, so why no propagate them as well?
>
> The current way for application to find the l2_len (for example) is to examine the ptype using multiple if statement.
>
> However, this may not always work if there are unknown/user headers (e.g. DSA header).
> in addition, some of the examples are not checking the ptype and assumes a specific packet structure.
> e.g. l3-fwd, assumes only ethernet header exist and hardcoded jump by 14B to access the IP header.
> but if VLAN exist it will fail.
>
> checking the l2_len will work in any case.
>
>
> Regards,
> Liron Himi
>
> [A picture containing clipart Description automatically generated]<https://www.marvell.com/>
>
> Park Azorim, Kyriat Arie, Petah Tikva, 49527, Israel
> Mobile: +972.52.3329169
L2 len would be relatively easy since almost all devices are Ethernet only.
L3 len is the problem, many devices don't interpret L3 and below headers.
Only those that have flow type functionality are likely to do that.
next prev parent reply other threads:[~2022-01-24 17:21 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-24 8:39 Liron Himi
2022-01-24 17:21 ` Stephen Hemminger [this message]
2022-01-25 17:38 ` [EXT] " Liron Himi
2022-01-25 21:25 ` Stephen Hemminger
2022-01-26 6:50 ` Liron Himi
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=20220124092104.07db8409@hermes.local \
--to=stephen@networkplumber.org \
--cc=dev@dpdk.org \
--cc=lironh@marvell.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).