DPDK patches and discussions
 help / color / mirror / Atom feed
* [dpdk-dev] input port in mbuf
@ 2020-05-06 19:21 Liron Himi
  2020-05-06 19:42 ` Stephen Hemminger
  0 siblings, 1 reply; 10+ messages in thread
From: Liron Himi @ 2020-05-06 19:21 UTC (permalink / raw)
  To: dpdk-dev; +Cc: 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


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [dpdk-dev] input port in mbuf
  2020-05-06 19:21 [dpdk-dev] input port in mbuf Liron Himi
@ 2020-05-06 19:42 ` Stephen Hemminger
  2020-05-06 19:48   ` [dpdk-dev] [EXT] " Liron Himi
  0 siblings, 1 reply; 10+ messages in thread
From: Stephen Hemminger @ 2020-05-06 19:42 UTC (permalink / raw)
  To: Liron Himi; +Cc: dpdk-dev

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.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [dpdk-dev] [EXT] Re:  input port in mbuf
  2020-05-06 19:42 ` Stephen Hemminger
@ 2020-05-06 19:48   ` Liron Himi
  2020-05-06 20:10     ` Stephen Hemminger
  0 siblings, 1 reply; 10+ messages in thread
From: Liron Himi @ 2020-05-06 19:48 UTC (permalink / raw)
  To: Stephen Hemminger; +Cc: dpdk-dev, 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.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [dpdk-dev] [EXT] Re:  input port in mbuf
  2020-05-06 19:48   ` [dpdk-dev] [EXT] " Liron Himi
@ 2020-05-06 20:10     ` Stephen Hemminger
  2020-05-06 20:17       ` Liron Himi
  0 siblings, 1 reply; 10+ messages in thread
From: Stephen Hemminger @ 2020-05-06 20:10 UTC (permalink / raw)
  To: Liron Himi; +Cc: dpdk-dev

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.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [dpdk-dev] [EXT] Re:  input port in mbuf
  2020-05-06 20:10     ` Stephen Hemminger
@ 2020-05-06 20:17       ` Liron Himi
  2020-05-06 20:23         ` Stephen Hemminger
  2020-05-06 22:10         ` Ananyev, Konstantin
  0 siblings, 2 replies; 10+ messages in thread
From: Liron Himi @ 2020-05-06 20:17 UTC (permalink / raw)
  To: Stephen Hemminger; +Cc: dpdk-dev, 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.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [dpdk-dev] [EXT] Re:  input port in mbuf
  2020-05-06 20:17       ` Liron Himi
@ 2020-05-06 20:23         ` Stephen Hemminger
  2021-01-16 20:01           ` Liron Himi
  2020-05-06 22:10         ` Ananyev, Konstantin
  1 sibling, 1 reply; 10+ messages in thread
From: Stephen Hemminger @ 2020-05-06 20:23 UTC (permalink / raw)
  To: Liron Himi; +Cc: dpdk-dev

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.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [dpdk-dev] [EXT] Re:  input port in mbuf
  2020-05-06 20:17       ` Liron Himi
  2020-05-06 20:23         ` Stephen Hemminger
@ 2020-05-06 22:10         ` Ananyev, Konstantin
  1 sibling, 0 replies; 10+ messages in thread
From: Ananyev, Konstantin @ 2020-05-06 22:10 UTC (permalink / raw)
  To: Liron Himi, Stephen Hemminger; +Cc: dpdk-dev

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [dpdk-dev] [EXT] Re:  input port in mbuf
  2020-05-06 20:23         ` Stephen Hemminger
@ 2021-01-16 20:01           ` Liron Himi
  2021-01-27 16:58             ` Tom Barbette
  0 siblings, 1 reply; 10+ messages in thread
From: Liron Himi @ 2021-01-16 20:01 UTC (permalink / raw)
  To: Stephen Hemminger; +Cc: dpdk-dev, 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?

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [dpdk-dev] [EXT] Re: input port in mbuf
  2021-01-16 20:01           ` Liron Himi
@ 2021-01-27 16:58             ` Tom Barbette
  2021-01-27 17:59               ` Liron Himi
  0 siblings, 1 reply; 10+ messages in thread
From: Tom Barbette @ 2021-01-27 16:58 UTC (permalink / raw)
  To: Liron Himi, Stephen Hemminger; +Cc: dpdk-dev

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


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [dpdk-dev] [EXT] Re: input port in mbuf
  2021-01-27 16:58             ` Tom Barbette
@ 2021-01-27 17:59               ` Liron Himi
  0 siblings, 0 replies; 10+ messages in thread
From: Liron Himi @ 2021-01-27 17:59 UTC (permalink / raw)
  To: Tom Barbette, Stephen Hemminger; +Cc: dpdk-dev, 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


^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2021-01-27 17:59 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-05-06 19:21 [dpdk-dev] input port in mbuf Liron Himi
2020-05-06 19:42 ` Stephen Hemminger
2020-05-06 19:48   ` [dpdk-dev] [EXT] " Liron Himi
2020-05-06 20:10     ` Stephen Hemminger
2020-05-06 20:17       ` Liron Himi
2020-05-06 20:23         ` Stephen Hemminger
2021-01-16 20:01           ` Liron Himi
2021-01-27 16:58             ` Tom Barbette
2021-01-27 17:59               ` Liron Himi
2020-05-06 22:10         ` Ananyev, Konstantin

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