<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span><br>
<br>
Good questions. I'm also looking for the linux bridge MD, SRIOV MD...<br>
Who will be responsible for these drivers?<br>
<br>
</span>Excellent question. In my opinion, 'technology' specific but not vendor specific MD (like SRIOV) should not be maintained by specific vendor. It should be accessible for all interested parties for contribution.<br></blockquote><div><br></div><div>I don't think that anyone is making the suggestion of making these drivers develop in silos, but instead one of the objective is to allow them to evolve more rapidly, and in the open, where anyone can participate.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span><br>
The OVS driver is maintained by Neutron community, vendor specific hardware driver by vendor, SDN controllers driver by their own community or vendor. But there are also other drivers like SRIOV, which are general for a lot of vendor agonitsc backends, and can't be maintained by a certain vendor/community.<br></span></blockquote><div><br></div><div>Certain technologies, like the ones mentioned above may require specific hardware; even though they may not be particularly associated with a specific vendor, some sort of vendor support is indeed required, like 3rd party CI. So, grouping them together under an hw-accelerated umbrella, or whichever other name that sticks, may make sense long term should the number of drivers really ramp up as hinted below.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span>
<br>
So, it would be better to keep some "general backend" MD in tree besides SRIOV. There are also vif-type-tap, vif-type-vhostuser, hierarchy-binding-external-VTEP ... We can implement a very thin in-tree base MD that only handle "vif bind" which is backend agonitsc, then backend provider is free to implement their own service logic, either by an backend agent, or by a driver derived from the base MD for agentless scenery.<br>
<br>
</span>Keeping general backend MDs in tree sounds reasonable.<br>
<div><div>Regards<br>
<br>
> Many thanks,<br>
>      Neil<br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div></div></div>