[dpdk-dev] input port in mbuf

[dpdk-dev] input port in mbuf

[Liron Himi]

Hi,

We need to save the input port in the mbuf in order to return the buffer to the right hw pool.
For now we use the 'port' in the mbuf as it is supposed to be for this exact purpose.
But we noticed that some applications are override it with the destination port.

What should be the right behavior?
is there another location that that this information can be stored and read only by the ethdev drivers?

Regards,
Liron

Re: [dpdk-dev] input port in mbuf

[Stephen Hemminger]

On Wed, 6 May 2020 19:21:30 +0000
Liron Himi <lironh@marvell.com> wrote:

> Hi,
> 
> We need to save the input port in the mbuf in order to return the buffer to the right hw pool.
> For now we use the 'port' in the mbuf as it is supposed to be for this exact purpose.
> But we noticed that some applications are override it with the destination port.
> 
> What should be the right behavior?
> is there another location that that this information can be stored and read only by the ethdev drivers?
> 
> Regards,
> Liron
> 

There is no requirement that input port is unmodified by the application.

Re: [dpdk-dev] [EXT] Re: input port in mbuf

[Liron Himi]

Fine. Is there another location or option to save this information?

Regards,
Liron

-----Original Message-----
From: Stephen Hemminger <stephen@networkplumber.org> 
Sent: Wednesday, 6 May 2020 22:43
To: Liron Himi <lironh@marvell.com>
Cc: dpdk-dev <dev@dpdk.org>
Subject: [EXT] Re: [dpdk-dev] input port in mbuf

External Email

----------------------------------------------------------------------
On Wed, 6 May 2020 19:21:30 +0000
Liron Himi <lironh@marvell.com> wrote:

> Hi,
> 
> We need to save the input port in the mbuf in order to return the buffer to the right hw pool.
> For now we use the 'port' in the mbuf as it is supposed to be for this exact purpose.
> But we noticed that some applications are override it with the destination port.
> 
> What should be the right behavior?
> is there another location that that this information can be stored and read only by the ethdev drivers?
> 
> Regards,
> Liron
> 

There is no requirement that input port is unmodified by the application.

Re: [dpdk-dev] [EXT] Re: input port in mbuf

[Stephen Hemminger]

On Wed, 6 May 2020 19:48:26 +0000
Liron Himi <lironh@marvell.com> wrote:

> Fine. Is there another location or option to save this information?
> 
> Regards,
> Liron
> 
> -----Original Message-----
> From: Stephen Hemminger <stephen@networkplumber.org> 
> Sent: Wednesday, 6 May 2020 22:43
> To: Liron Himi <lironh@marvell.com>
> Cc: dpdk-dev <dev@dpdk.org>
> Subject: [EXT] Re: [dpdk-dev] input port in mbuf
> 
> External Email
> 
> ----------------------------------------------------------------------
> On Wed, 6 May 2020 19:21:30 +0000
> Liron Himi <lironh@marvell.com> wrote:
> 
> > Hi,
> > 
> > We need to save the input port in the mbuf in order to return the buffer to the right hw pool.
> > For now we use the 'port' in the mbuf as it is supposed to be for this exact purpose.
> > But we noticed that some applications are override it with the destination port.
> > 
> > What should be the right behavior?
> > is there another location that that this information can be stored and read only by the ethdev drivers?
> > 
> > Regards,
> > Liron
> >   
> 
> There is no requirement that input port is unmodified by the application.

The memory pool is already in the mbuf, should go there.

Re: [dpdk-dev] [EXT] Re: input port in mbuf

[Liron Himi]

For performance optimizations, we need to know the input DPDK port as after the buffer was transmitted via our ethdev driver instead of release it back to the memory-pool we can release it to the originated HW pool of the input port. 


Regards,
Liron

-----Original Message-----
From: Stephen Hemminger <stephen@networkplumber.org> 
Sent: Wednesday, 6 May 2020 23:11
To: Liron Himi <lironh@marvell.com>
Cc: dpdk-dev <dev@dpdk.org>
Subject: Re: [EXT] Re: [dpdk-dev] input port in mbuf

On Wed, 6 May 2020 19:48:26 +0000
Liron Himi <lironh@marvell.com> wrote:

> Fine. Is there another location or option to save this information?
> 
> Regards,
> Liron
> 
> -----Original Message-----
> From: Stephen Hemminger <stephen@networkplumber.org> 
> Sent: Wednesday, 6 May 2020 22:43
> To: Liron Himi <lironh@marvell.com>
> Cc: dpdk-dev <dev@dpdk.org>
> Subject: [EXT] Re: [dpdk-dev] input port in mbuf
> 
> External Email
> 
> ----------------------------------------------------------------------
> On Wed, 6 May 2020 19:21:30 +0000
> Liron Himi <lironh@marvell.com> wrote:
> 
> > Hi,
> > 
> > We need to save the input port in the mbuf in order to return the buffer to the right hw pool.
> > For now we use the 'port' in the mbuf as it is supposed to be for this exact purpose.
> > But we noticed that some applications are override it with the destination port.
> > 
> > What should be the right behavior?
> > is there another location that that this information can be stored and read only by the ethdev drivers?
> > 
> > Regards,
> > Liron
> >   
> 
> There is no requirement that input port is unmodified by the application.

The memory pool is already in the mbuf, should go there.

Re: [dpdk-dev] [EXT] Re: input port in mbuf

[Stephen Hemminger]

On Wed, 6 May 2020 20:17:20 +0000
Liron Himi <lironh@marvell.com> wrote:

> For performance optimizations, we need to know the input DPDK port as after the buffer was transmitted via our ethdev driver instead of release it back to the memory-pool we can release it to the originated HW pool of the input port. 

But you can't be sure where the mbuf came from.
It could be a receive on any vendors driver, or it could be from a private pool
that is  used for transmit, or anywhere.

Please reconsider the real nature here; the world is not testpmd, l2fwd, l3fwd etc.
These are the kind of optimizations that break real applications and cause 
more trouble than the benefit for one silly benchmark.

Re: [dpdk-dev] [EXT] Re: input port in mbuf

[Ananyev, Konstantin]

> For performance optimizations, we need to know the input DPDK port as after the buffer was transmitted via our ethdev driver instead of
> release it back to the memory-pool we can release it to the originated HW pool of the input port.

Then I suppose, you can have your own mempool driver,
and do whatever you like there.

> 
> 
> Regards,
> Liron
> 
> -----Original Message-----
> From: Stephen Hemminger <stephen@networkplumber.org>
> Sent: Wednesday, 6 May 2020 23:11
> To: Liron Himi <lironh@marvell.com>
> Cc: dpdk-dev <dev@dpdk.org>
> Subject: Re: [EXT] Re: [dpdk-dev] input port in mbuf
> 
> On Wed, 6 May 2020 19:48:26 +0000
> Liron Himi <lironh@marvell.com> wrote:
> 
> > Fine. Is there another location or option to save this information?
> >
> > Regards,
> > Liron
> >
> > -----Original Message-----
> > From: Stephen Hemminger <stephen@networkplumber.org>
> > Sent: Wednesday, 6 May 2020 22:43
> > To: Liron Himi <lironh@marvell.com>
> > Cc: dpdk-dev <dev@dpdk.org>
> > Subject: [EXT] Re: [dpdk-dev] input port in mbuf
> >
> > External Email
> >
> > ----------------------------------------------------------------------
> > On Wed, 6 May 2020 19:21:30 +0000
> > Liron Himi <lironh@marvell.com> wrote:
> >
> > > Hi,
> > >
> > > We need to save the input port in the mbuf in order to return the buffer to the right hw pool.
> > > For now we use the 'port' in the mbuf as it is supposed to be for this exact purpose.
> > > But we noticed that some applications are override it with the destination port.
> > >
> > > What should be the right behavior?
> > > is there another location that that this information can be stored and read only by the ethdev drivers?
> > >
> > > Regards,
> > > Liron
> > >
> >
> > There is no requirement that input port is unmodified by the application.
> 
> The memory pool is already in the mbuf, should go there.

Re: [dpdk-dev] [EXT] Re: input port in mbuf

[Liron Himi]

Hi,

Sorry for rearising this issue again, please check my comments inline

Liron Himi

-----Original Message-----
From: Stephen Hemminger <stephen@networkplumber.org> 
Sent: Wednesday, 6 May 2020 23:24
To: Liron Himi <lironh@marvell.com>
Cc: dpdk-dev <dev@dpdk.org>
Subject: Re: [EXT] Re: [dpdk-dev] input port in mbuf

On Wed, 6 May 2020 20:17:20 +0000
Liron Himi <lironh@marvell.com> wrote:

> For performance optimizations, we need to know the input DPDK port as after the buffer was transmitted via our ethdev driver instead of release it back to the memory-pool we can release it to the originated HW pool of the input port. 

But you can't be sure where the mbuf came from.
It could be a receive on any vendors driver, or it could be from a private pool that is  used for transmit, or anywhere.

[L.H.] I'm only referring to PP2->PP2 flow on an Armada platform. For any other flow the transmitted buffer will be returned to its 'mb'.

Please reconsider the real nature here; the world is not testpmd, l2fwd, l3fwd etc.
These are the kind of optimizations that break real applications and cause more trouble than the benefit for one silly benchmark.

[L.H.] I don't want to influence application usage, this is why I asked if there is a location in the mbuf where a driver can put its own info. Like the private area for the application, but just for the input driver.
And if there is no such location right now, will it be acceptable to introduce such one?

Re: [dpdk-dev] [EXT] Re: input port in mbuf

[Tom Barbette]

[-- Attachment #1: Type: text/plain, Size: 1700 bytes --]

Le 16/01/2021 à 21:01, Liron Himi a écrit :
> Hi,
>
> Sorry for rearising this issue again, please check my comments inline
>
> Liron Himi
>
> -----Original Message-----
> From: Stephen Hemminger <stephen@networkplumber.org>
> Sent: Wednesday, 6 May 2020 23:24
> To: Liron Himi <lironh@marvell.com>
> Cc: dpdk-dev <dev@dpdk.org>
> Subject: Re: [EXT] Re: [dpdk-dev] input port in mbuf
>
> On Wed, 6 May 2020 20:17:20 +0000
> Liron Himi <lironh@marvell.com> wrote:
>
>> For performance optimizations, we need to know the input DPDK port as after the buffer was transmitted via our ethdev driver instead of release it back to the memory-pool we can release it to the originated HW pool of the input port.
> But you can't be sure where the mbuf came from.
> It could be a receive on any vendors driver, or it could be from a private pool that is  used for transmit, or anywhere.
>
> [L.H.] I'm only referring to PP2->PP2 flow on an Armada platform. For any other flow the transmitted buffer will be returned to its 'mb'.
>
> Please reconsider the real nature here; the world is not testpmd, l2fwd, l3fwd etc.
> These are the kind of optimizations that break real applications and cause more trouble than the benefit for one silly benchmark.
>
> [L.H.] I don't want to influence application usage, this is why I asked if there is a location in the mbuf where a driver can put its own info. Like the private area for the application, but just for the input driver.
> And if there is no such location right now, will it be acceptable to introduce such one?
Isn't  it the purpose of RTE Mbuf dynamic fields ? You could register a 
field that only your driver knows about.

Re: [dpdk-dev] [EXT] Re: input port in mbuf

[Liron Himi]

-----Original Message-----
From: Tom Barbette <barbette@kth.se> 
Sent: Wednesday, 27 January 2021 18:59
To: Liron Himi <lironh@marvell.com>; Stephen Hemminger <stephen@networkplumber.org>
Cc: dpdk-dev <dev@dpdk.org>
Subject: Re: [dpdk-dev] [EXT] Re: input port in mbuf

Le 16/01/2021 à 21:01, Liron Himi a écrit :
> Hi,
>
> Sorry for rearising this issue again, please check my comments inline
>
> Liron Himi
>
> -----Original Message-----
> From: Stephen Hemminger <stephen@networkplumber.org>
> Sent: Wednesday, 6 May 2020 23:24
> To: Liron Himi <lironh@marvell.com>
> Cc: dpdk-dev <dev@dpdk.org>
> Subject: Re: [EXT] Re: [dpdk-dev] input port in mbuf
>
> On Wed, 6 May 2020 20:17:20 +0000
> Liron Himi <lironh@marvell.com> wrote:
>
>> For performance optimizations, we need to know the input DPDK port as after the buffer was transmitted via our ethdev driver instead of release it back to the memory-pool we can release it to the originated HW pool of the input port.
> But you can't be sure where the mbuf came from.
> It could be a receive on any vendors driver, or it could be from a private pool that is  used for transmit, or anywhere.
>
> [L.H.] I'm only referring to PP2->PP2 flow on an Armada platform. For any other flow the transmitted buffer will be returned to its 'mb'.
>
> Please reconsider the real nature here; the world is not testpmd, l2fwd, l3fwd etc.
> These are the kind of optimizations that break real applications and cause more trouble than the benefit for one silly benchmark.
>
> [L.H.] I don't want to influence application usage, this is why I asked if there is a location in the mbuf where a driver can put its own info. Like the private area for the application, but just for the input driver.
> And if there is no such location right now, will it be acceptable to introduce such one?
Isn't  it the purpose of RTE Mbuf dynamic fields ? You could register a 
field that only your driver knows about.
[L.H.] Thanks, I will explore this option