Open Stack

On Fri, Jul 25, 2014 at 5:43 AM, Robert Li (baoli) <baoli at cisco.com> wrote:

> Hi Kyle,
>
> Sorry I missed your queries on the IRC channel today. I was thinking about
> this whole BP. After chatting with Irena this morning, I think that I
> understand what this BP is trying to achieve overall. I also had a chat
> with Sandhya afterwards. I¹d like to discuss a few things in here:
>
>   ‹ Sandhya¹s MD is going to support cisco¹s VMFEX. Overall her code¹s
> structure would look like very much similar to Irena¹s patch in part 1.
> However, she cannot simply inherit from SriovNicSwitchMechanismDriver. The
> differences for her code are: 1) get_vif_details() would populate
> profileid (rather than vlanid), 2) she¹d need to do vmfex specific
> processing in try_to_bind(). We¹re thinking that with a little of
> generalization, SriovNicSwitchMechanismDriver() (with a changed name such
> as SriovMechanismDriver()) can be used both for nic switch and vmfex. It
> would look like in terms of class hierarchy:
>              SriovMechanismDriver
>                     SriovNicSwitchMechanismDriver
>


SriovNicSwitchMellanoxMechanismDriver
                                        SriovNicSwitchIntelMechanismDriver
                                        SriovNicSwitchEmulexMechanismDriver

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.


>                     SriovQBRMechanismDriver
>                          SriovCiscoVmfexMechanismDriver
>
> Code duplication would be reduced significantly. The change would be:
>        ‹ make get_vif_details an abstract method in SriovMechanismDriver
>        ‹ make an abstract method to perform specific bind action required
> by a particular adaptor indicated in the PCI vendor info
>        ‹ vif type and agent type should be set based on the PCI vendor
> info
>
> A little change of patch part 1 would achieve the above
>
>   ‹ Originally I thought that SR-IOV port¹s status would be depending on
> the Sriov Agent (patch part 2). After chatting with Irena, this is not the
> case. So all the SR-IOV ports will be active once created or bound
> according to the try_to_bind() method. In addition, the current Sriov
> Agent (patch part 2) only supports port admin status change for mlnx
> adaptor. I think these caveats need to be spelled out explicitly to avoid
> any confusion or misunderstanding, at least in the documentation.
>
>   ‹ Sandhya has planned to support both intel and vmfex in her MD. This
> requires a hybrid sriov mech driver that populates vif details based on
> the PCI vendor info in the port. Another way to do this is to run two MDs
> in the same time, one supporting intel, the other vmfex. This would work
> well with the above classes. But it requires change of the two config
> options (in Irena¹s patch part one) so that per MD config options can be
> specified. I¹m not sure if this is practical in real deployment (meaning
> use of SR-IOV adaptors from different vendors in the same deployment), but
> I think it¹s doable within the existing ml2 framework.
>

Absolutely, this is a mandatory requirement by many customers! They don't
care which vendor the NIC is from at all.


>
> we¹ll go over the above in the next sr-iov IRC meeting as well.
>
> Thanks,
> Robert
>
>
>
>
>
>
>
>
>
> On 7/24/14, 1:55 PM, "Kyle Mestery (Code Review)" <review at openstack.org>
> wrote:
>
> >Kyle Mestery has posted comments on this change.
> >
> >Change subject: ML2 mechanism driver for SR-IOV capable NIC based
> >switching, Part 2
> >......................................................................
> >
> >
> >Patch Set 3: Code-Review+2 Workflow+1
> >
> >I believe Irena has answered all of Robert's questions. Any subsequent
> >issues can be handled as a followup.
> >
> >--
> >To view, visit https://review.openstack.org/107651
> >To unsubscribe, visit https://review.openstack.org/settings
> >
> >Gerrit-MessageType: comment
> >Gerrit-Change-Id: I533ccee067935326d5837f90ba321a962e8dc2a6
> >Gerrit-PatchSet: 3
> >Gerrit-Project: openstack/neutron
> >Gerrit-Branch: master
> >Gerrit-Owner: Berezovsky Irena <irenab at mellanox.com>
> >Gerrit-Reviewer: Akihiro Motoki <motoki at da.jp.nec.com>
> >Gerrit-Reviewer: Arista Testing <arista-openstack-test at aristanetworks.com
> >
> >Gerrit-Reviewer: Baodong (Robert) Li <baoli at cisco.com>
> >Gerrit-Reviewer: Berezovsky Irena <irenab at mellanox.com>
> >Gerrit-Reviewer: Big Switch CI <openstack-ci at bigswitch.com>
> >Gerrit-Reviewer: Brocade CI <openstack_gerrit at brocade.com>
> >Gerrit-Reviewer: Brocade OSS CI <DL-GRP-VYATTA-OSS at Brocade.com>
> >Gerrit-Reviewer: Cisco Neutron CI <cisco-openstack-neutron-ci at cisco.com>
> >Gerrit-Reviewer: Freescale CI <fslosci at freescale.com>
> >Gerrit-Reviewer: Hyper-V CI <hyper-v_ci at microsoft.com>
> >Gerrit-Reviewer: Jenkins
> >Gerrit-Reviewer: Kyle Mestery <mestery at mestery.com>
> >Gerrit-Reviewer: Mellanox External Testing
> ><mlnx-openstack-ci at dev.mellanox.co.il>
> >Gerrit-Reviewer: Metaplugin CI Test <metaplugintest at gmail.com>
> >Gerrit-Reviewer: Midokura CI Bot <lucas at midokura.com>
> >Gerrit-Reviewer: NEC OpenStack CI <nec-openstack-ci at iaas.jp.nec.com>
> >Gerrit-Reviewer: Neutron Ryu <ryu-openstack-review at lists.sourceforge.net>
> >Gerrit-Reviewer: One Convergence CI <oc-neutron-test at oneconvergence.com>
> >Gerrit-Reviewer: PLUMgrid CI <plumgrid-ci-os at plumgrid.com>
> >Gerrit-Reviewer: Tail-f NCS Jenkins <tobbe at tail-f.com>
> >Gerrit-Reviewer: vArmour CI Test <openstack-ci-test at varmour.com>
> >Gerrit-HasComments: No
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140725/8a299b92/attachment.html>