> -Original Message-
> From: Ferruh Yigit
> Sent: Tuesday, January 30, 2024 13:17
> To: Dariusz Sosnowski ; Stephen Hemminger
>
> Cc: NBU-Contact-Thomas Monjalon (EXTERNAL) ;
> Andrew Rybchenko ; Ori Kam
> ; dev@dpdk.org
> Subject: Re: [RFC] ethdev: fast path a
) ;
>> Andrew Rybchenko ; Ori Kam
>> ; dev@dpdk.org
>> Subject: Re: [RFC] ethdev: fast path async flow API
>>
>> On 1/29/2024 1:38 PM, Dariusz Sosnowski wrote:
>>> Hi all,
>>>
>>>> -Original Message-
>>>> From: Dariusz Sosn
Hi Ferruh,
> -Original Message-
> From: Ferruh Yigit
> Sent: Monday, January 29, 2024 18:36
> To: Dariusz Sosnowski ; Stephen Hemminger
>
> Cc: NBU-Contact-Thomas Monjalon (EXTERNAL) ;
> Andrew Rybchenko ; Ori Kam
> ; dev@dpdk.org
> Subject: Re: [RFC] ethde
w Rybchenko
>> ; Ori Kam ;
>> dev@dpdk.org
>> Subject: RE: [RFC] ethdev: fast path async flow API
>>
>> Hi Stephen,
>>
>> Sorry for such a late response.
>>
>> From: Stephen Hemminger
>> Sent: Thursday, January 4, 2024 02:08
>>&g
Hi all,
> -Original Message-
> From: Dariusz Sosnowski
> Sent: Tuesday, January 23, 2024 12:37
> To: Stephen Hemminger
> Cc: NBU-Contact-Thomas Monjalon (EXTERNAL) ;
> Ferruh Yigit ; Andrew Rybchenko
> ; Ori Kam ;
> dev@dpdk.org
> Subject: RE: [RFC] ethde
Hi Stephen,
Sorry for such a late response.
From: Stephen Hemminger
Sent: Thursday, January 4, 2024 02:08
> On Wed, 3 Jan 2024 19:14:49 +
> Dariusz Sosnowski wrote:
> > In summary, in my opinion extending the async flow API with bulking
> capabilities or exposing the queue directly to the a
Hi Konstantin,
> -Original Message-
> From: Konstantin Ananyev
> Sent: Thursday, January 4, 2024 09:47
> > > This is a blocker, showstopper for me.
> > +1
> >
> > > Have you considered having something like
> > >rte_flow_create_bulk()
> > >
> > > or better yet a Linux iouring style AP
> -Original Message-
> From: Ivan Malov
> Sent: Wednesday, January 3, 2024 19:29
> Hi Dariusz,
>
> I appreciate your response. All to the point.
>
> I have to confess my question was inspired by the 23.11 merge commit in OVS
> mailing list. I first thought that an obvious consumer for th
> > This is a blocker, showstopper for me.
> +1
>
> > Have you considered having something like
> >rte_flow_create_bulk()
> >
> > or better yet a Linux iouring style API?
> >
> > A ring style API would allow for better mixed operations across the board
> > and
> > get rid of the I-cache ov
On Wed, 3 Jan 2024 19:14:49 +
Dariusz Sosnowski wrote:
> In summary, in my opinion extending the async flow API with bulking
> capabilities or exposing the queue directly to the application is not
> desirable.
> This proposal aims to reduce the I-cache overhead in async flow API by
> reusi
> -Original Message-
> From: Stephen Hemminger
> Sent: Thursday, December 28, 2023 18:17
> > However, at the moment I see one problem with this approach.
> > It would require DPDK to expose the rte_eth_dev struct definition,
> > because of implied locking implemented in the flow API.
>
>
Hi Dariusz,
I appreciate your response. All to the point.
I have to confess my question was inspired by the 23.11 merge commit
in OVS mailing list. I first thought that an obvious consumer for
the async flow API could have been OVS but saw no usage of it in
the current code. It was my impression
Hi Ivan,
> Hi Dariusz,
>
> I appreciate the proposal. You say that a reference PMD implementation will
> be made available for 24.03 release. What about the applications?
> Is this supposed to go to upstream code of some applications?
No source code changes are required in applications which alre
> However, at the moment I see one problem with this approach.
> It would require DPDK to expose the rte_eth_dev struct definition,
> because of implied locking implemented in the flow API.
This is a blocker, showstopper for me.
Have you considered having something like
rte_flow_create_bulk(
Hi Dariusz,
I appreciate the proposal. You say that a reference PMD implementation
will be made available for 24.03 release. What about the applications?
Is this supposed to go to upstream code of some applications?
Thank you.
On Thu, 28 Dec 2023, Dariusz Sosnowski wrote:
Hi Stephen,
+/**
+
Hi Stephen,
> > +/**
> > + * @internal
> > + *
> > + * Fast path async flow functions and related data are held in a flat
> > array,
> one entry per ethdev.
> > + * It is assumed that each entry is read-only and cache aligned.
> > + */
> > +struct rte_flow_fp_ops {
> > + void *ctx;
> > +
On Wed, 27 Dec 2023 12:57:09 +0200
Dariusz Sosnowski wrote:
> +/**
> + * @internal
> + *
> + * Fast path async flow functions and related data are held in a flat array,
> one entry per ethdev.
> + * It is assumed that each entry is read-only and cache aligned.
> + */
> +struct rte_flow_fp_ops {
Goal of the proposed API changes is reducing the overhead of performance
critical asynchronous flow API functions at library level.
Specifically the functions which can be called while processing packets
received by the application in data path.
The plan for the changes is as follows:
1. Fast pat
18 matches
Mail list logo
