* [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: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
* 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
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
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.