Re: [dpdk-dev] [PATCH v2 0/3] ethdev: configure SR-IOV VF from host

[Thomas Monjalon <thomas@monjalon.net>]

03/11/2019 16:27, Ananyev, Konstantin:
> 
> > > > If we consider what Intel did, i.e. configure VF in place of
> > > > representor for some operations, there are two drawbacks:
> > > > - confusing that some ops apply to representor, others apply to VF
> > > > - some ops are not possible on representor (because targetted to VF)
> > > >
> > > > I still feel that the addition of one single bit in the port ID is an
> > > > elegant solution to target either the VF or its representor.
> > >
> > > Since we already have a confusion about what is configured when operations
> > > are performed on a representor port we have 2 options:
> > 
> > I don't agree we have. I don't think there is any design note or API doc that says the ethdev configuration on representor should be applied
> > on VF (please share if I missed it).
> > The fact that there are some drivers that implemented it doesn't mean it is correct.
> 
> Well, it means that at least authors and reviewers of these patches,
> plus probably next-net maintainers believe that it is correct.
> At least they did - when patch was applied.
> If that is not clearly stated in the doc - it might be just the gap in the documentation,

Gap in the documentation? We should state that the config should be applied
to the port specified with port_id and no other one? Funny

> that needs to be fixed, not a mandate to break existing behavior.

So because you managed to have a wrong patch applied in your PMD,
you want to make it the generic API in ethdev?
What a process!

Hey guys, if you want to change an API behaviour in a way others don't,
you just have to implement what you want in your PMD silently,
then you will be able to change the API to comply with your behaviour.
Wonderful.
If we allow such practice, DPDK is dead.