<div dir="ltr"><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jul 25, 2014 at 5:43 AM, Robert Li (baoli) <span dir="ltr"><<a href="mailto:baoli@cisco.com" target="_blank">baoli@cisco.com</a>></span> wrote:<br>
<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">Hi Kyle,<br>
<br>
Sorry I missed your queries on the IRC channel today. I was thinking about<br>
this whole BP. After chatting with Irena this morning, I think that I<br>
understand what this BP is trying to achieve overall. I also had a chat<br>
with Sandhya afterwards. I¹d like to discuss a few things in here:<br>
<br>
‹ Sandhya¹s MD is going to support cisco¹s VMFEX. Overall her code¹s<br>
structure would look like very much similar to Irena¹s patch in part 1.<br>
However, she cannot simply inherit from SriovNicSwitchMechanismDriver. The<br>
differences for her code are: 1) get_vif_details() would populate<br>
profileid (rather than vlanid), 2) she¹d need to do vmfex specific<br>
processing in try_to_bind(). We¹re thinking that with a little of<br>
generalization, SriovNicSwitchMechanismDriver() (with a changed name such<br>
as SriovMechanismDriver()) can be used both for nic switch and vmfex. It<br>
would look like in terms of class hierarchy:<br>
SriovMechanismDriver<br>
SriovNicSwitchMechanismDriver<br></blockquote><div><br></div><div> SriovNicSwitchMellanoxMechanismDriver<br></div><div> SriovNicSwitchIntelMechanismDriver</div>
<div> SriovNicSwitchEmulexMechanismDriver</div><div><br></div><div>do you also mean that for nicswitch besides QBR? If so I think this make sense, and user can choose to only load vendor agnostic "SriovNicSwitchMD" and "SriovQBRMD", without any PCI vendor info. Also we need a vendor agnostic agent, which just use standard linux "ip link" command to config NIC. However, if users want to use advanced features provided by vendor, they can load inherited vendor specific MD and similarly config in agent side.</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">
SriovQBRMechanismDriver<br>
SriovCiscoVmfexMechanismDriver<br>
<br>
Code duplication would be reduced significantly. The change would be:<br>
‹ make get_vif_details an abstract method in SriovMechanismDriver<br>
‹ make an abstract method to perform specific bind action required<br>
by a particular adaptor indicated in the PCI vendor info<br>
‹ vif type and agent type should be set based on the PCI vendor<br>
info<br>
<br>
A little change of patch part 1 would achieve the above<br>
<br>
‹ Originally I thought that SR-IOV port¹s status would be depending on<br>
the Sriov Agent (patch part 2). After chatting with Irena, this is not the<br>
case. So all the SR-IOV ports will be active once created or bound<br>
according to the try_to_bind() method. In addition, the current Sriov<br>
Agent (patch part 2) only supports port admin status change for mlnx<br>
adaptor. I think these caveats need to be spelled out explicitly to avoid<br>
any confusion or misunderstanding, at least in the documentation.<br>
<br>
‹ Sandhya has planned to support both intel and vmfex in her MD. This<br>
requires a hybrid sriov mech driver that populates vif details based on<br>
the PCI vendor info in the port. Another way to do this is to run two MDs<br>
in the same time, one supporting intel, the other vmfex. This would work<br>
well with the above classes. But it requires change of the two config<br>
options (in Irena¹s patch part one) so that per MD config options can be<br>
specified. I¹m not sure if this is practical in real deployment (meaning<br>
use of SR-IOV adaptors from different vendors in the same deployment), but<br>
I think it¹s doable within the existing ml2 framework.<br></blockquote><div><br></div><div>Absolutely, this is a mandatory requirement by many customers! They don't care which vendor the NIC is from at all.</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">
<br>
we¹ll go over the above in the next sr-iov IRC meeting as well.<br>
<br>
Thanks,<br>
Robert<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
On 7/24/14, 1:55 PM, "Kyle Mestery (Code Review)" <<a href="mailto:review@openstack.org">review@openstack.org</a>><br>
wrote:<br>
<br>
>Kyle Mestery has posted comments on this change.<br>
><br>
>Change subject: ML2 mechanism driver for SR-IOV capable NIC based<br>
>switching, Part 2<br>
>......................................................................<br>
><br>
><br>
>Patch Set 3: Code-Review+2 Workflow+1<br>
><br>
>I believe Irena has answered all of Robert's questions. Any subsequent<br>
>issues can be handled as a followup.<br>
><br>
>--<br>
>To view, visit <a href="https://review.openstack.org/107651" target="_blank">https://review.openstack.org/107651</a><br>
>To unsubscribe, visit <a href="https://review.openstack.org/settings" target="_blank">https://review.openstack.org/settings</a><br>
><br>
>Gerrit-MessageType: comment<br>
>Gerrit-Change-Id: I533ccee067935326d5837f90ba321a962e8dc2a6<br>
>Gerrit-PatchSet: 3<br>
>Gerrit-Project: openstack/neutron<br>
>Gerrit-Branch: master<br>
>Gerrit-Owner: Berezovsky Irena <<a href="mailto:irenab@mellanox.com">irenab@mellanox.com</a>><br>
>Gerrit-Reviewer: Akihiro Motoki <<a href="mailto:motoki@da.jp.nec.com">motoki@da.jp.nec.com</a>><br>
>Gerrit-Reviewer: Arista Testing <<a href="mailto:arista-openstack-test@aristanetworks.com">arista-openstack-test@aristanetworks.com</a>><br>
>Gerrit-Reviewer: Baodong (Robert) Li <<a href="mailto:baoli@cisco.com">baoli@cisco.com</a>><br>
>Gerrit-Reviewer: Berezovsky Irena <<a href="mailto:irenab@mellanox.com">irenab@mellanox.com</a>><br>
>Gerrit-Reviewer: Big Switch CI <<a href="mailto:openstack-ci@bigswitch.com">openstack-ci@bigswitch.com</a>><br>
>Gerrit-Reviewer: Brocade CI <<a href="mailto:openstack_gerrit@brocade.com">openstack_gerrit@brocade.com</a>><br>
>Gerrit-Reviewer: Brocade OSS CI <DL-GRP-VYATTA-OSS@Brocade.com><br>
>Gerrit-Reviewer: Cisco Neutron CI <<a href="mailto:cisco-openstack-neutron-ci@cisco.com">cisco-openstack-neutron-ci@cisco.com</a>><br>
>Gerrit-Reviewer: Freescale CI <<a href="mailto:fslosci@freescale.com">fslosci@freescale.com</a>><br>
>Gerrit-Reviewer: Hyper-V CI <<a href="mailto:hyper-v_ci@microsoft.com">hyper-v_ci@microsoft.com</a>><br>
>Gerrit-Reviewer: Jenkins<br>
>Gerrit-Reviewer: Kyle Mestery <<a href="mailto:mestery@mestery.com">mestery@mestery.com</a>><br>
>Gerrit-Reviewer: Mellanox External Testing<br>
><<a href="mailto:mlnx-openstack-ci@dev.mellanox.co.il">mlnx-openstack-ci@dev.mellanox.co.il</a>><br>
>Gerrit-Reviewer: Metaplugin CI Test <<a href="mailto:metaplugintest@gmail.com">metaplugintest@gmail.com</a>><br>
>Gerrit-Reviewer: Midokura CI Bot <<a href="mailto:lucas@midokura.com">lucas@midokura.com</a>><br>
>Gerrit-Reviewer: NEC OpenStack CI <<a href="mailto:nec-openstack-ci@iaas.jp.nec.com">nec-openstack-ci@iaas.jp.nec.com</a>><br>
>Gerrit-Reviewer: Neutron Ryu <<a href="mailto:ryu-openstack-review@lists.sourceforge.net">ryu-openstack-review@lists.sourceforge.net</a>><br>
>Gerrit-Reviewer: One Convergence CI <<a href="mailto:oc-neutron-test@oneconvergence.com">oc-neutron-test@oneconvergence.com</a>><br>
>Gerrit-Reviewer: PLUMgrid CI <<a href="mailto:plumgrid-ci-os@plumgrid.com">plumgrid-ci-os@plumgrid.com</a>><br>
>Gerrit-Reviewer: Tail-f NCS Jenkins <<a href="mailto:tobbe@tail-f.com">tobbe@tail-f.com</a>><br>
>Gerrit-Reviewer: vArmour CI Test <<a href="mailto:openstack-ci-test@varmour.com">openstack-ci-test@varmour.com</a>><br>
>Gerrit-HasComments: No<br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">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>
</blockquote></div><br></div></div>