RE: [EXT] Re: [PATCH net-next v3 2/4] octeon_ep: PF-VF mailbox version support

[Shinas Rasheed]

> > I'm afraid as to what else can be an alternative? The control net commands
> have to be decoded and passed by the PF driver for the VFs,
> > as only the PFs have access to talk to firmware directly. The VF drivers do
> not have an alternative way to query control net APIs, and may fail
> > if the control net APIs they have are not even recognized by the PF to
> decode them.
> >
> > Either VF commands which the PF can't support can be blocked at the
> source (by the equivalent PF-VF backward compatibility which will exist in VF
> drivers)
> > by this negotiation, or we have to let commands come through and fail
> them, leading to just redundancy in terms of running code. I don't see how
> this negotiation in
> > any way 'limit' the VF drivers.
> >
> > As you said, in essence the VF drivers will have to fallback to v0 for
> backward compatibility if the native host uses some old OS having older PF
> drivers. If not, the
> > commands would come and fail anyways at the PF. Either way, it's an error
> case and this negotiation is just to decide if we are going to allow letting such
> commands in.
> 
> I don't know what netdev maintainers will do with this code, I just
> pointed to this architecture/HW troublesome design.
> 
> Thanks

I understand, thanks for your scrutiny. As I understand, its a case for letting errors run its course by letting
unsupported commands in, or negotiate for a common version and stop earlier on control plane commands which the PF driver just doesn't know. 

Again, thanks for your constructive insight.