Re: [dpdk-dev] [PATCH] ethdev: add DBDF action to RTE Flow

[Jerin Jacob <jerinjacobk@gmail.com>]

On Tue, May 26, 2020 at 10:25 PM David Marchand
<david.marchand@redhat.com> wrote:
>
> Hello Jerin, Kiran,

Hello David,

>
> On Thu, Mar 19, 2020 at 10:26 AM Thomas Monjalon <thomas@monjalon.net> wrote:
> > > > > We have the following use case.
> > > > > We have 2 PF's pf0, pf1 and corresponding VF's pf0_vf0 , pf1_vf0. And
> > > > > we have
> > > > > 3 applications running.
> > > > > 1st application on pf0 and pf1
> > > > > 2nd application on pf0_vf0
> > > > > 3rd application on pf1_vf0.
> > > > > We want to direct the traffic matching condition1 from application 1
> > > > > (traffic from both pf0 & pf1) needs to send to  application 2
> > > > > (pf0_vf0) And matching condition2 from application 1 (traffic from
> > > > > both pf0 & pf1) needs to send to application 3 (pf1_vf0).
> > > > > To summarize, we need to send traffic from pf0 to pf1_vf0 and traffic
> > > > > from pf1 to pf0_vf0. In this case This DBDF action will be useful.
> > > > >
> > > >
> > > > It seems that what you are describing it the port action with representors, or any
> > > > other way you wish to implement it.
> > >
> > > Let's say we have a VF with kernel and we want to send the traffic to that VF, then we can't
> > > Use port action. This will be useful in those scenarios.
> >
> > Sorry I don't understand.
> > You mean the VF is managed by a kernel driver while the PF is managed by DPDK?
> > So what prevents having a VF representor?
>
> The discussion did not reach a conclusion.
> Looking at patchwork, I can see it set to "Not Applicable".
>
> Do you still expect some work on this subject?

No. We dont need API change, we can manage with VF representor.

>
>
> Thanks.
>
> --
> David Marchand
>