On 27/05/20 17:49 +0200, Ilya Maximets wrote: > On 4/20/20 9:26 AM, Roni Bar Yanai wrote: > > Hi Ben, Ilya > > > > Going back to this thread. We've tried app-ctl approach and it fails on > > consistency > > problem. Orchestrator can configure on full system init, but now executing > > local > > restart will lose the configuration (again for bifurcated driver it is not > > problem). > > > > The requirement for setting VF mac through the representor, comes from > > different > > use cases such as Open Stack and Kubernetes. VF is used with pass-through > > and > > untrusted user VM/Pod/Container . The MAC address is set by the orchestrator > > only. For Linux use case there is ip tool for doing that, and Linux takes > > care of the > > consistency. For OVS-DPDK with port representor, there is no way to > > configure VF MAC > > address (except of for bifurcated drivers). > > > > The requirement is to enable orchestrator configuration of VF MAC address > > in DPDK, > > when working with port representor. > > The solution should handle the generic use case and not bifurcated drivers > > only. > > The MAC should be kept and configured in case of OVS restart. > > > > Maybe we can go back to the first solution and open set MAC to port > > representors > > only. We treat the solution as a generic solution and ignore bifurcated > > drivers. > > When user configure the representor MAC (which is a reflection of the VF), > > the > > VF MAC is configured. The MAC address is saved in the DB. In case of > > returning back > > to kernel there is no problem because the DB MAC applies only for DPDK > > representor. > > For bifurcated driver, user can cause in consistency, but this is a unique > > case and > > we cannot defend against misuse of bifurcated drivers. > > > > Any thoughts? > > This is a DPDK specific issue. Since appctl commnad is not suitable and > common > 'mac' configuration via database is a controversial solution, I'd suggest > having > a scary-named netdev-dpdk specific knob to avoid abusing it for any other > usecase. > For example, something like other_config:dpdk-vf-mac in the interface table. > And > the code should, probably, reject attempts to change mac address on > non-representors. > Probably, the name of the knob should reflect that somehow. > > What do you think?
Hello Ilya, I tried to read back the history about this subject but it's a little scattered so apologies if I am repeating past comments. I understand that you want to confine this issue to the specific case of VF MAC. Your solution addresses it but does not mitigate the split-brain potential of bifurcated drivers. The split-brain issue is inherent to those drivers. I believe making a feature more narrow and more difficult to find to side-step an intractable problem will only muddy the water. The confusion for bifurcated drivers is already there for other interface states, such as MTU. At this point wouldn't it be better to be consistent in the risk involved, and expect users not to contradict themselves when using their ports in OvS? > > One more note here: You mentioned untrusted VFs and containers. Last time I > checked > DPDK sources I didn't see any "mac address administratively set" concept like > it > done in kernel drivers, so the untrusted VM or container could easily change > the > configured mac address. i.e. configuration from the OVS side is only part of > the > solution that is required. > > Best regards, Ilya Maximets. > I have looked at the VF specific configurations in DPDK, this concept is currently addressed by vendor-specific APIs for a few drivers only. I will propose a standard API for VF trusted mode (among others of those VF APIs) to allow integration in upper layers, so that vendors can align themselves. Best regards, -- Gaëtan Mellanox _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
