l2/l3_len fields

l2/l3_len fields

[Liron Himi]

[-- Attachment #1.1: Type: text/plain, Size: 949 bytes --]

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


[-- Attachment #1.2: Type: text/html, Size: 4416 bytes --]

[-- Attachment #2: image003.jpg --]
[-- Type: image/jpeg, Size: 1464 bytes --]

Re: l2/l3_len fields

[Stephen Hemminger]

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.

RE: [EXT] Re: l2/l3_len fields

[Liron Himi]

-----Original Message-----
From: Stephen Hemminger <stephen@networkplumber.org> 
Sent: Monday, 24 January 2022 19:21
To: Liron Himi <lironh@marvell.com>
Cc: dev@dpdk.org
Subject: [EXT] Re: l2/l3_len fields

External Email

----------------------------------------------------------------------
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.

[L.H.] Not sure I understand what you mean.
what will be easy? Easy for the application to calculate the l2_len?

Re: [EXT] Re: l2/l3_len fields

[Stephen Hemminger]

On Tue, 25 Jan 2022 17:38:42 +0000
Liron Himi <lironh@marvell.com> wrote:

> -----Original Message-----
> From: Stephen Hemminger <stephen@networkplumber.org> 
> Sent: Monday, 24 January 2022 19:21
> To: Liron Himi <lironh@marvell.com>
> Cc: dev@dpdk.org
> Subject: [EXT] Re: l2/l3_len fields
> 
> External Email
> 
> ----------------------------------------------------------------------
> 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.
> 
> [L.H.] Not sure I understand what you mean.
> what will be easy? Easy for the application to calculate the l2_len?
> 

If the hardware doesn't support doing it directly, then if the application needs
these it should do the calculations itself. Many chips don't support reporting L2 and L3 lengths
in the receive result.

RE: [EXT] Re: l2/l3_len fields

[Liron Himi]

-----Original Message-----
From: Stephen Hemminger <stephen@networkplumber.org> 
Sent: Tuesday, 25 January 2022 23:25
To: Liron Himi <lironh@marvell.com>
Cc: dev@dpdk.org
Subject: Re: [EXT] Re: l2/l3_len fields

On Tue, 25 Jan 2022 17:38:42 +0000
Liron Himi <lironh@marvell.com> wrote:

> -----Original Message-----
> From: Stephen Hemminger <stephen@networkplumber.org>
> Sent: Monday, 24 January 2022 19:21
> To: Liron Himi <lironh@marvell.com>
> Cc: dev@dpdk.org
> Subject: [EXT] Re: l2/l3_len fields
> 
> External Email
> 
> ----------------------------------------------------------------------
> 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.
> 
> [L.H.] Not sure I understand what you mean.
> what will be easy? Easy for the application to calculate the l2_len?
> 

If the hardware doesn't support doing it directly, then if the application needs these it should do the calculations itself. 
Many chips don't support reporting L2 and L3 lengths in the receive result.

[L.H.] I agree with that. However, today those fields are marked as TX-offload only, so even if HW can provide the information, the driver doesn't fill them and application are not looking at it.
So maybe a good approach is to support both options.
i.e. how about add new RX offload flag for this functionality and if HW support it than application can use those fields, otherwise application can continue with the ptype approach.
make sense?