13:07:04 <irenab> #startmeeting Passthrough
13:07:05 <openstack> Meeting started Tue Jun 17 13:07:04 2014 UTC and is due to finish in 60 minutes.  The chair is irenab. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:07:06 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:07:08 <openstack> The meeting name has been set to 'passthrough'
13:07:47 <irenab> The spec for SR-IOV networking is merged!!!
13:08:46 <heyongli> yeah
13:08:50 <irenab> yjiang51: good morning!
13:09:03 <yjiang51> irenab: :)
13:09:03 <heyongli> thats
13:09:16 <heyongli> good job
13:09:28 <heyongli> any topic？
13:10:07 <irenab> For current spec, seems all work items baoli  intends to cover
13:10:33 <irenab> I am still on neutron MD implementation items.
13:10:53 <irenab> I actually wanted to discuss some Intel case related issue
13:11:10 <sadasu> sure
13:11:16 <heyongli> ok
13:11:49 <yjiang51> irenab: just saw the spec approved? Cool
13:11:55 <irenab> My intention is to cover Intel NIC as part of the Embedded switch Mechanism driver, with VIF_TYPE = HW_VEB.
13:12:14 <irenab> yjiang51: yes, finally :-)
13:13:07 <irenab> I saw sadasu also includes Intel NIC as part of the VM_FEX MD
13:13:17 <sadasu> irenab: I saw that comment on my BP
13:13:27 <irenab> I would like to understand if/where in should be covered
13:13:30 <heyongli> irenab seems meeting not start so mo log
13:14:12 <sadasu> I think the Embedded switch Mechanism driver is applicable to any SR-IOV capable NIC, correct?
13:14:27 <sadasu> so Intel SR-IOV NIC is included as part of it
13:14:51 <yjiang51> irenab: sadasu: what's the VM_FEX MD?
13:14:52 <irenab> heyongli:  I see this : The meeting name has been set to 'passthrough'
13:15:04 <heyongli> ok
13:15:38 <irenab> maybe meeting name is wrong?
13:16:13 <sadasu> irenab: the MD I am working on is the UCS manager MD which supports the Cisco VM-FEX capable card and Intel SR-IOV card
13:16:26 <irenab> sadasu: correct. But if we go for two MD in same deployment, how the PCI info filter will work?
13:17:00 <sadasu> yjiang51: this is the MD we are talking about: https://review.openstack.org/#/c/95236/
13:17:31 <irenab> sadasu: for intel nic, what VIF_TYPE do you plan to push?
13:18:01 <sadasu> ireanb: HW_WEB
13:18:04 <irenab> I just think we should not duplicate the support and identify what is the corrent way to go
13:18:22 <sadasu> yeah...I thought that is what we are trying to do now :-)
13:18:43 <irenab> sadasu: we are allignedas always :-)
13:18:43 <heyongli> yonhong  am on phone please cover me keep log
13:18:53 <irenab> ^aligned
13:19:26 <sadasu> let us look at the specific use case: there is a set of UCS Servers all managed by one UCS Manager
13:19:40 <irenab> sadu: so it actually seems to be a duplication ....
13:19:45 <sadasu> these UCS servers have a mixture of Cisco NICs and Intel NICs
13:20:15 <sadasu> lets go thro this use case for better understanding of duplication
13:20:50 <irenab> sadasu: for the case with non UCS Servers and Intel NICs, what should be deployed?
13:21:08 <sadasu> in my method of implementation, I will need cisco_ucsm MD to take care of both NICs
13:21:39 <sadasu> the customer sees a complete UCS system + UCS manager so includes only the UCSM MD
13:21:55 <sadasu> irenab: your MD
13:22:06 <yjiang51> sadasu: will cisco_ucsm be direct or macvtap? I assume it will be direct, right?
13:22:33 <sadasu> yjiang51: both direct and macvtap
13:22:46 <yjiang51> sadasu: ok.
13:22:46 <irenab> sadasu: seems strange to support it in two MDs....
13:22:56 <sadasu> irenab: I am just trying to say that we need both MDs to support Intel
13:23:05 <irenab> and what if both MDs are deployed?
13:24:01 <irenab> sadasu: will it be some other Product ID?
13:24:10 <sadasu> probability of that use case happening is very low
13:24:53 <yjiang51> sadasu: irenab: how to distinguish if a Intel NIC in UCS or in normal case?
13:24:57 <sadasu> we need to compare that...I can get the product_id of the card supported on each of our systems
13:24:58 <irenab> sadasu: I think we just need
13:25:25 <irenab> to see if there is some limitations or it can be resolved on PCI device filter level
13:25:49 <irenab> yjiang51: correct
13:25:52 <sadasu> irenab: agreed...for which we need the 2 product ids
13:26:17 <irenab> sadasu: if it is the case, it works OK and there is no conflict
13:27:00 <sadasu> irenab: that was my understanding too..hence went ahead with the support in my MD...
13:27:04 <irenab> anyway I will provide config attribute for supported PCI info strings, so it is not hardcoded in any case
13:27:44 <irenab> sadasu: no problem, we just may consider do some code reuse, but can figure out at implementation review
13:27:49 <sadasu> This is specific of the use case where it is completely a UCS system and this MD shud be able to support all NICs supported on UCS
13:28:00 <sadasu> otherwise it will be an incomplete implementation
13:28:14 <sadasu> for all other cases we will you the generic SR-IOV NIC MD
13:28:15 <irenab> sadasu: undrstand it, thanks
13:28:39 <sadasu> irenab: I agree
13:29:11 <irenab> Anyone has other topics to discuss?
13:29:41 <sadasu> irenab: another question
13:29:51 <irenab> sadsu: sure, go ahead
13:30:19 <sadasu> can the generic SR-IOV NIC MD work with any or no L2 agent on the compute node in a multinode setup?
13:31:23 <irenab> sadasu: I plan the agent to support port_state_up changes case, thats why make the MD agent based solution, it is not required for port binding
13:32:13 <irenab> sadsu: do you see the case to run it without support for port state changes
13:32:15 <irenab> ?
13:33:04 <irenab> sadasu: do you mean the muti segment networks?
13:33:35 <sadasu> irenab: no...not multi-segment..
13:33:57 <irenab> sadsu: what do you mean by multi node?
13:34:10 <sadasu> by "support for port state changes" did you mean create_port_* , update_port_* method implementations?
13:34:43 <irenab> sadasu:update_port for currently only admin_state_up attribute
13:35:04 <sadasu> controller node runs neutron server and compute nodes run the agent
13:35:16 <irenab> sadsu: for already bound port to enable/disable traffic
13:36:18 <irenab> sadsu: do you have in mind some use case that agent is not required, and MD can be used?
13:36:41 <sadasu> irenab: brb..
13:36:57 <irenab> sadasu: ?
13:39:23 <irenab> I think we should decide what are the next items to define as part of the sub-team, and/or maybe get requirements from NFV sub-tema?
13:40:34 <yjiang51> irenab: I think NVF sub-team has more than SR-IOV.
13:40:53 <sadasu> sorry...someone was at the door
13:42:03 <sadasu> ireanb: so to answer ur question, in the case of MD, admin state changes are not handles by the L2 agent on the compute node
13:42:18 <irenab> yjiang5: agree. I just think we need identify next features to push, since current spec is approved
13:42:49 <sadasu> ireanb: yjiang5: yes we shud align with the NFV subteam as the next steps
13:43:40 <irenab> I think it worth to push agenda for next meeting
13:43:41 <sadasu> so port state changes has to be handled by my MD
13:44:16 <sadasu> irenab: next NFV meeting?
13:44:33 <irenab> sadsu: Are you talking about consuming Embedded Switch MD without agent for your case?
13:44:54 <irenab> sadasu: no, I meant PCI meeting
13:45:44 <sadasu> irenab: I think I am not sure what your question
13:45:53 <irenab> I think it may be useful to have agenda that we want to cover, now when basic support spec is approved
13:46:13 <sadasu> we can keep this topic for next week
13:46:30 <irenab> sadsu: you previously asked ig agent is a mandatory for generic SR_IOV MD
13:47:15 <sadasu> irenab: yes...I think your answer was that it is needed to handle port state changes
13:48:10 <irenab> sadasu:  yes, but if you have case it maybe usefull without port state chages support, let's consider if/how to make ir
13:48:23 <sadasu> ireanb: ok
13:48:54 <sadasu> irenab: lets add that to next week's agenda...
13:49:04 <irenab> sadasu: +1
13:49:36 <irenab> hopefully I will lend some code update till next week, so we can go over it as well
13:49:50 <sadasu> irenab: cool
13:50:17 <sadasu> should we also add NFV alignment to the agenda also?
13:50:19 <heyongli> drag me into the revie
13:50:36 <irenab> heyongli: sure
13:50:52 <sadasu> irenab: can u take a look at my MD spec again>
13:51:28 <irenab> sadasu: it maybe good idea for NFV allignment, and yes I'll review it the spec
13:52:04 <irenab> any other topic to discuss?
13:52:59 <irenab> shall we close the meeting?
13:53:56 <sadasu> yes...done 87mins early
13:54:00 <sadasu> 7 mins
13:54:21 <irenab> cool. Thank you guys
13:54:31 <irenab> #endmeeting