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

quoted

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,

quoted

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

quoted

if the control net APIs they have are not even recognized by the PF to

decode them.

quoted

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)

quoted

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

quoted

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

quoted

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.