13:00:04 <baoli> #startmeeting PCI passthrough
13:00:05 <openstack> Meeting started Tue Jul 29 13:00:04 2014 UTC and is due to finish in 60 minutes.  The chair is baoli. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:00:06 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:00:08 <openstack> The meeting name has been set to 'pci_passthrough'
13:00:13 <baoli> Hi there
13:00:33 <irenab> hi
13:02:57 <baoli> Irenab, hi.
13:03:31 <irenab> baoli: any update on use case I raised last meeting, for ovs and SR-IOV VF on same network, same host?
13:04:17 <baoli> Irenab, not yet. Rob seems to be on vacation.
13:04:59 <irenab> baoli: ok
13:05:24 <irenab> hopefully, I will be on vacation next week
13:05:30 <b3nt_pin> hi (beagles... nick temporarily unavailable I guess)
13:05:48 <b3nt_pin> baoli, sorry I just realized I forgot to +1 your patch
13:05:50 <b3nt_pin> rectified
13:06:07 <baoli> Irenab, it's summer, so vacation is nice.
13:06:12 <baoli> beagles, Hi
13:06:13 <b3nt_pin> +1
13:06:27 <irenab> beagles: hi, long time ...
13:06:34 <b3nt_pin> first real pto in around 10 years this time... even though it was just a week it was pretty nice
13:06:58 <b3nt_pin> irenab, yeah... I had a lot of schedule mess ups the last month
13:07:03 <b3nt_pin> sorry  :(
13:07:03 <baoli> beagles, +1 is still much needed, and it's never late.
13:07:10 <b3nt_pin> already done :)
13:07:38 <baoli> beagles, hope you had a great time.
13:07:39 <irenab> baoli: seems patches are in right direction, start to get +1 and +2
13:07:55 <b3nt_pin> for one of them at least... gotta get that PCI one done too.
13:08:05 <baoli> irenab, yea. I noticed a +2 on the bug (which is the first patch the rest depends on)
13:08:20 <b3nt_pin> it's a lot bigger and more out of my realm of familiarity... but still
13:09:08 <b3nt_pin> I noticed a lot of dialog about neutron side changes... progress is good on proliferating support?
13:09:33 <irenab> beagles: HW_VEB MD is merged!
13:09:37 <baoli> Given the number of patches, I have to keep rebasing and daily. Sometimes, there are CI failures that are not related to the change.
13:09:43 <b3nt_pin> irenab, NIFTY!
13:09:59 <b3nt_pin> baoli, ugh... yeah, I hate that
13:10:17 <baoli> yea, irenab did a great job on the neutron side
13:10:18 <irenab> now need to do the right thing with QBH case (sadasu spec)
13:10:53 <irenab> baoli: I still have to add few improvments on agent side, but generally its OK
13:11:02 <baoli> irenab, thanks for the reply on the ml2 md on sriov
13:12:14 <irenab> baoli: You welcome. I would be happy  to help sadasu to insert the QBH part
13:13:02 <irenab> do we think it makes sense to make it single SR-IOV MD to support superset of HW_VEB and QBH?
13:13:49 <irenab> I know we initially decided to make it 2 MDs to move fster, but now when first MD is already merged, we may reconsider
13:14:04 <baoli> irenab, I'm thinking about that too.
13:14:33 <irenab> great minds think alike :-)
13:15:18 <baoli> irenab, an SRIOV MD can be considered to have common part and vendor specific part.
13:16:19 <baoli> so I was thinking that a little bit restructuring of the NicSwitchMD can be used to address the common part.
13:17:39 <irenab> baoli: from the implementation perspective, yes. We need to see from functional perspective if it should support simultaniously different vendor nics, maybe on different network segments
13:18:28 <irenab> it should be OK to mix Intel and Mellanox NICs on the sema network as well
13:18:41 <irenab> s/sema/same
13:19:09 <baoli> irenab, agree.
13:19:38 <baoli> irenab, do you like the hierarchy I mentioned in the email?
13:20:28 <irenab> baoli: hierarchy is good if we want separate MDs.
13:22:18 <irenab> there was some request on review, to allow any pci_vendor_info to be treated by  MD, not checking is should support it. We initally needed it to filter between QBH and HW_VEB MDs
13:22:48 <baoli> irenab, with super MD,  vendor-specific loadable driver is needed
13:23:05 <sadasu> that is useful only in an all sr-iov based cloud
13:23:29 <sadasu> did the person who gave the comment explain why they needed the check to be removed?
13:23:32 <baoli> for a particular vendor/product, we need encaps, if agent required and vendor specific driver.
13:24:21 <irenab> baoli: makes sense. We need option to support list of drivers
13:24:23 <baoli> So the super MD should be able to handle anything that doesn't require a vendor specific "driver"
13:24:50 <irenab> baoli: super MD, you mean HW_VEB?
13:25:42 <baoli> irenab, sorry, I was using super MD to refer to the superset you mentioned earlier.
13:25:54 <irenab> baoli: OK, got it
13:26:32 <baoli> irenab, the list should include all the devices, their encaps, agent required and driver info
13:27:47 <baoli> irenab, with that, the class hierarchy mentioned in the email may not be needed.
13:29:00 <irenab> baoli: when agent is required, it supposed to be for all setup, need to think about it a little more
13:29:25 <irenab> baoi: but generally I like this idea
13:30:03 <baoli> irenab, whether or not agent is required can be configured per vendor device, I'm thinking.
13:31:21 <irenab> baoli: I think it should be per vif_type
13:31:58 <baoli> sadasu, the comments were given on the email thread. You should have received it.
13:32:05 <irenab> baoli: I think we should do something quite intuitive and easily  deployed and see if need more refinment
13:32:14 <sadasu> baoli: yes I saw it
13:32:43 <baoli> irenab, you mean that whether or not agent is required is per vif_type?
13:33:16 <baoli> irenab, the list should be maintained by the developer, not by the delopyer.
13:33:16 <irenab> baoli: yes, and this maybe chosen during deployment
13:34:31 <baoli> irenab, ok, I see. But right now, only mlnx supports the admin change of port status.
13:34:47 <irenab> baoli: I am not sure, since you do not want to change openstack code if Intel adds ability to set VF state
13:35:36 <irenab> so if the deployment is only with Intel or even with Mellanox, but never intended to change VF state, so no agent will be required and not even installed..
13:35:57 <baoli> irenab, I think that agent_required can be set per deployment.
13:36:31 <irenab> baoli: exactly
13:37:43 <irenab> sadsu: we chatted before you joined, that maybe you can leverage already merged MD to add your case there instead of adding new MD
13:37:48 <baoli> irenab: it's just that it may not be useful for certain vendor devices.
13:37:56 <sadasu> baoli, irenab: what if the deployment consists of a mixture of vendors, some of which support agents and others do not?
13:38:32 <sadasu> irenab: I thing that was exactly what was discussed in the commnets for my BP too
13:38:38 <irenab> sadasu: in such case agent will be in use, and just log warning that invoked operation is not supported
13:39:16 <irenab> but as we  said before if agent is required per VIF_TYPE, it won't mess the HW_VEB and QBH cases
13:39:33 <sadasu> irenab: I am not sure this will be accepted esp since this wasn't discussed as part of your original BP
13:39:39 <sadasu> but again I may be wrong
13:40:29 <sadasu> irenab: ok
13:40:46 <sadasu> I will look at the meeting log to see what was discussed before I got here
13:41:16 <sadasu> but, as I had mentioned, the current sr-iov-nic-switch MD is quite specific to mellanox
13:41:23 <irenab> sadsu: the API is there, but vendor may not support it....
13:42:36 <irenab> sadsu: I am not sure it is specific, it just enable additional vendor capanilities. It works fine on Intel NICs, just without changing VF state
13:42:37 <sadasu> irenab: just to be clear, API to support agent you mean?
13:43:05 <sadasu> irenab: yes, it should work for the intel case
13:43:17 <irenab> sadsu: no, api to set VF state to support  port-update admin_state for HW_VEB case
13:43:34 <sadasu> ok got it
13:43:51 <sadasu> so what is the plan going fwd?
13:44:03 <irenab> sadsu: agent_required  is especially configurable option, since Intel currenlty do not support VF state change
13:44:22 <sadasu> are we making any changes to the existing sr-iov-nic-switch MD or do I have to use it in its current state
13:44:40 <baoli> irenab, sadasu, shall we support this restructuring effort in the next phase?
13:44:48 <baoli> I think that we need s neutron spec for it.
13:45:12 <irenab> sadasu: I think its up to you, if you want to leverage existing MD, and it may require some refactoring or add another MD.
13:45:25 <sadasu> irenab: exactly
13:45:46 <irenab> baoli: I am not sure it requires spec.
13:46:14 <sadasu> I will get the vendor_id, product_id checking for free if I inherited from this MD
13:46:46 <irenab> sadsu: yes
13:47:04 <baoli> irenab, if we'd like to do the vendor specific driver with the configuration we just discussed (encaps, driver, etc), I think a neutron spec is deserved.
13:47:45 <irenab> baoli: I think we may discuss it with ML2 team, there is a meeting tomorrow
13:47:51 <sadasu> and the setting of parameters to the set_binding call
13:47:55 <baoli> irenab, sure.
13:48:56 <irenab> baoli: new spec means not be in Juno. And this this purely implementation details
13:49:38 <irenab> sadsu: did you take a look on the MD to see if usable for your needs?
13:50:24 <sadasu> I would have liked for this MD to set the VIF_TYPE and agent type etc in a diff initialization function
13:50:37 <sadasu> instead of default params to the class itself
13:51:00 <baoli> irenab, spec or not, I think what's important is we can agree how to "implement" it.
13:51:00 <sadasu> I don't think this is how a generic MD should be initialized
13:51:19 <irenab> baoli: +2
13:52:00 <baoli> We don't have to rush for it.
13:52:19 <irenab> sadasu: if you see how it can reduce code that you need to add, I think you may refactor the existing MD as pat of your patch
13:52:30 <irenab> s/pat/part
13:52:34 <sadasu> ok...got it...
13:53:11 <baoli> irenab, that's a good way to approach it as well.
13:53:21 <irenab> baoli: I like the idea to make it one SR-IOV MD
13:53:40 <baoli> irenab, we are on the same page.
13:53:41 <sadasu> also in ml2_conf_sriov.ini, the agent_required variable
13:53:50 <irenab> just need to see that it does not hold you from adding support for QBH
13:54:16 <sadasu> how will this wok if we have multiple sr-iov MDs inheriting from this one
13:54:34 <baoli> sadasu, we are talking about a vendor specific driver
13:55:00 <baoli> So essentially, it's SR-IOV MD + vendor specific driver
13:55:11 <baoli> sorry s/driver/drivers/
13:55:15 <sadasu> but the base sr-iov-nic-switch MD has code to read this variable correct?
13:56:01 <baoli> in order to do that, the MD needs to maintain a list of devices, their encaps (QBH versus HW_VEB) and drivers.
13:56:02 <sadasu> each vendor-specific driver should have a variable of its own saying if it needs an agent or not
13:56:07 <irenab> baoli: lets call it vendor specific logic, driver is confusing with MD
13:56:22 <baoli> irenab, sure.
13:57:16 <irenab> baoli, sadsu: but it looks like something much bigger than we initially wanted to support, although seems right thing to do....
13:57:42 <sadasu> irenab: our design is evolving...
13:58:08 <irenab> sadsu: agree, but release dealines not....
13:58:32 <baoli> time is almost up. So let's keep discussing it.
13:58:35 <sadasu> that is where I am still not clear about what we are tackling in this release
13:58:38 <baoli> later
13:58:47 <sadasu> ok...
13:59:04 <sadasu> thanks..I will raed up the discussion at the start of the meeting
13:59:28 <baoli> thanks everyone. see you next time.
13:59:30 <irenab> sadsu: I think the simple way will be reuse the current MD and add the one you intended to add. Later to conslidate and probaly in kilo through all process of spec,...
13:59:35 <baoli> beagles, thanks again for the review.
14:00:04 <irenab> sadasy, baoli: let keep discussion via emails?
14:00:19 <baoli> irenab, sure.
14:00:25 <irenab> sadsu: want to chat with ml2 team tomorrow?
14:00:55 <baoli> I have to do now.
14:01:00 <baoli> #endmeeting