13:00:36 <baoli> #startmeeting PCI Passthrough
13:00:37 <openstack> Meeting started Tue Nov 25 13:00:36 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:38 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:00:40 <openstack> The meeting name has been set to 'pci_passthrough'
13:00:50 <baoli> Hi there
13:01:01 <pczesno> hi
13:01:06 <irenab> hi
13:02:35 <baoli> Yongli sent an email to me and he won't be able to join today
13:02:55 <baoli> He told me that he lost some of his work due to computer issues
13:04:17 <baoli> But he probably remember what he did, and will rewrite.
13:04:36 <baoli> Let's get started
13:05:01 <baoli> so we don't have new bugs.
13:06:25 <sadasu> Hi
13:06:37 <baoli> sadasu, Hi
13:09:03 <irenab> I can stay for 30 min only
13:10:20 <baoli> irenab, sure. let's keep it short
13:10:28 <sadasu> r we waiting for more folks to join?
13:10:43 <baoli> sadasu, we've started already. on bugs
13:10:49 <baoli> let's move on
13:10:54 <baoli> #topic reviews
13:11:13 <baoli> anything on reviews?
13:11:44 <irenab> I wanted to discuss default vnic_type on network
13:12:44 <irenab> actually it son blueprints part, so waiting
13:13:03 <baoli> ok, we can move on if nothing for reviews. A few of them wait for +2s to get in
13:13:22 <irenab> baoli: do you join nova meeting?
13:13:29 <baoli> #topic Blueprints
13:13:46 <irenab> maybe worth to ask there for review
13:14:00 <sadasu> yes, mine too and I think everything is kind of on hold until descicion on driver split is decided
13:14:05 <baoli> irenab, that's right. I joined some time
13:14:19 <irenab> Can I start with Network default setting extension?
13:14:26 <baoli> irenab, sure.
13:14:29 <sadasu> irenab: yes
13:15:08 <irenab> I started to draft the spec and need your advise
13:15:52 <irenab> Do you think this should be specific default vnic_type on network level extension or more generic extension to add port default values on network level
13:17:02 <irenab> I am afraid to add generic one may cause long discussion, but do not like to add extension for vnic_type
13:17:19 <irenab> what do you think?
13:17:54 <pczesno> what other settings, besides vnic_type, could use this?
13:18:05 <baoli> irenab, I'm confused with the two choices
13:18:22 <baoli> Can you clarify on the second choice?
13:18:26 <irenab> I think any port extension that has some attribute on port create
13:19:15 <sadasu> I have a more fundamental question, why do we need a default vnic_type at the network level?
13:19:19 <irenab> Second is be able to specify on net-create --default_vnic_type=direct
13:20:06 <irenab> the first is to be adle to provide dictionary containing different key, val on net-create
13:20:44 <irenab> net-create --defaults type=dict {'vnic_type': direct}
13:21:17 * beagles indicates late joining and lurking
13:21:20 <irenab> the dictionaly is general and maybe used for different settings, like dhcp_extra_opts, qos, ...
13:21:32 <sadasu> so the behavior would be once a default_vnic_type is specified on a network, if a port is created on the network, it would have the same vnic_type unless overriden specifically, correct?
13:21:47 <irenab> sadsu:correct
13:21:54 <baoli> irenab, so both choices enhance the net-create command, but with different format.
13:22:20 <irenab> baoli: yes. One choice is general  mechanism, second only for vnic_type
13:23:18 <baoli> irenab, to make it generic, it requires more participation in the discussion. And I agree with it will be hard.
13:23:42 <sadasu> irenab: with port security extension BP, the default values of security groups is manipulated
13:24:01 <irenab> I think to raise it also at ML2 meeting
13:24:16 <irenab> sadasu: what do you mean?
13:24:27 <sadasu> so having a vnic_type specific implementation  is fine...but don't need to go the extension route
13:25:14 <irenab> How can you do it on network without adding extension?
13:25:18 <baoli> irenab, do you know if we have any other default values associated with the network?
13:26:07 <sadasu> actually, the only way I know is through an extension...but I am not sure if there are other solutions
13:26:10 <irenab> baoli: not for SR-IOV , but this maybe useful for other extensions, i.e. dhcp_extra_opts
13:26:52 <sadasu> for example, security groups is also turned on all the time
13:27:06 <baoli> irenab, i think it's worthwhile to circulate the idea around. At least, the dict format open the door for future additions.
13:27:46 <sadasu> so, in Kilo a BP is being proposed to add a port security extension, that would allow the default to be set and overriden for specifci ports
13:28:00 <irenab> baoli: this was my understanding as well. I think I'll try to discuss it at ML2 meeting and proceed with Spec/ML after this
13:28:01 <sadasu> BP is proposed but evolving
13:28:15 <baoli> sadasu, do you have the link?
13:29:21 <baoli> irenab, that sounds good
13:29:45 <irenab> thanks, we can move on
13:30:07 <adrian-hoban> sadasu: I was under the impression that the main purpose of that is to be able to switch off security groups?
13:30:11 <sadasu> #link https://review.openstack.org/99873
13:30:12 <adrian-hoban> #link: https://blueprints.launchpad.net/neutron/+spec/switch-port-security-group
13:30:57 <sadasu> adrian-hoban: agreed. Just wanted to point out another BP that was mucking with the default port settings
13:31:35 <irenab> I didn't add this to agenda, but wanted to take 5 mins to raise QoS on SR-IOV support
13:31:56 <sadasu> so basically saying that irenab's approach is correct :-)
13:32:12 <sadasu> and has precedence
13:33:15 <sadasu> ok..moving on
13:33:38 <irenab> can I just align you with QoS (rate linit) on VF?
13:33:56 <irenab> rate limit
13:34:28 <sadasu> irenab: u still there? You mentioned you had to leave early
13:34:39 <irenab> yes, have few more mins :-)
13:35:17 <irenab> just wanted to say that we plan to add another extension to allow setting rate limit on VF
13:35:21 <baoli> irenab, there is QoS subgroup. Do you think we need specific API for SR-IOV only?
13:35:28 <sadasu> irenab: who is *you* in the previous comment?
13:35:56 <irenab> still trying to figure out if proceed this spec/pathces proposed since Havan for QoS or do more limited extension for rate limit only
13:36:15 <irenab> sadsu: Mellanox :-)
13:36:26 <adrian-hoban_> baoli: I think the implementation details will differ for rate limiting applied to SR-IOV ports
13:36:36 <sadasu> baoli: I think we need to check what is being worked on in the QoS subgroup
13:36:48 <sadasu> irenab's use case is only for rate limit
13:37:17 <baoli> adrian-hoban_, that may be true.
13:37:28 <irenab> I think the main issue from neutron perspective is if to go on QoS service, which may involve many discussions or choose the limited ML2 rate limit on port extension
13:38:24 <baoli> irenab, I see.
13:38:43 <irenab> sadasu: I talked to Sean (QoS leader) during the summit, he is not positive that QoS will be accepted...
13:39:23 <sadasu> irenab: oh...
13:39:24 <irenab> I wanted to check if this is something that maybe interesting for you guys as well
13:39:50 <adrian-hoban_> irenab: Certainly of interest for me
13:40:05 <baoli> irenab, we don't know what we will do on the QoS front yet.
13:40:26 <sadasu> this was an interest from day 1 on the ucsm side, but with way things have been progressing, this went to the back burner
13:40:51 <irenab> great, I plan to discuss it at ML2 meeting as well. I'll update next week
13:40:59 <irenab> sorry, have to go
13:41:04 <irenab> see you next week
13:41:09 <baoli> irenab, see you
13:41:14 <pczesno> irenab, bye
13:41:59 <sadasu> i'll look into details from the ucsm side as well
13:42:21 <sadasu> ireanb: thanks for the review
13:43:25 <baoli> I see that we have the stateless offloads spec up for review.
13:43:58 <pczesno> baoli, yes, what do you think ?
13:44:46 <baoli> pczesno, sorry I haven't got a moment to look at it in details. Will do it this week.
13:45:01 <pczesno> baoli, ok thanks
13:45:28 <baoli> We can move on if nothing else for Blueprints
13:45:42 <pczesno> just a head's up
13:45:43 <baoli> #topic CI Testing
13:45:59 <baoli> pczesno, sorry, please go ahead
13:46:12 <pczesno> i'm working on the spec for the api change in nova to allow specifing vnic_type
13:46:43 <pczesno> i'll should have it "ready" this week
13:47:30 <baoli> pczesno, that sounds good. Did you check the two abandoned patches on the meeting wiki page?
13:47:50 <pczesno> baoli, yes i did
13:48:04 <pczesno> baoli, thanks for the info
13:48:18 <baoli> pczesno, cool. Looking forward to your spec. Please put the link on the wiki
13:48:30 <pczesno> baoli, sure
13:48:58 <sadasu> pczesno: same here..
13:50:00 <baoli> Anything else anyone wants to bring up?
13:50:21 <beagles> yeah, quick question
13:50:45 <beagles> I think I mentioned last week that I'm working on a blueprint for bonding in guests...
13:50:45 <baoli> beagles, sure
13:51:19 <beagles> and while I was outlining I found myself wondering why we can't do some of this stuff now
13:51:52 <baoli> beagles, so can you give us a general idea about it?
13:52:02 <beagles> basically, I was wondering if anyone can think of an obstacle to creating two neutron ports on a dual part SR-IOV device and booting a VM with them
13:52:33 <baoli> beagles, what's a dual part SR-IOV device?
13:52:35 <beagles> assuming that the ports are configured via whitelist as being two different networks
13:52:39 <beagles> dual port sorry
13:52:54 * beagles shakes his head
13:53:24 <pczesno> beagles, currently you cannot enforce that the two ports will come from different pf's
13:53:48 <beagles> are the PFs related to the PCI ids in any way?
13:54:34 <beagles> or maybe it would be better put  does each port have a different PCI id?
13:55:09 <baoli> beagles, I have an two port intel card,
13:55:22 <baoli> and each of them has a different PCI address
13:55:51 <beagles> baoli: yeah, same here
13:55:56 <pczesno> beagles, what's more each virtual function  will have a different pci address
13:56:22 <baoli> But if you put them under two different networks, it's two ports as far as the VM is concerned, right?
13:56:31 * beagles tries to recall all of the PCI whitelist logic
13:56:33 <baoli> How does the bonding take into play here?
13:57:27 <beagles> all we need to do really is get two ports into the VM that get plugged to the right VFs
13:57:36 <beagles> then the bonding is the guest's problem
13:58:22 <pczesno> beagles, sure but you have to guarantee the guest that ports are attached to the same physical network and come from different phys functions
13:58:25 <baoli> beagles, today you can boot VM with two ports, each of them is assigned an IP address
13:58:36 <beagles> ummm why the same network
13:59:06 <beagles> you pretty much certainly DON'T want the same network
13:59:10 <pczesno> beagles, not sure
13:59:56 <baoli> beagles, the neutron view of the two ports has to be consistent wit the Guest's, otherwise, whatever the guest is doing to bond them won't work.
14:00:15 <beagles> well... actually my statement is really kind of neither here nor there.. it depends on what you want the abstractions to mean
14:01:35 <beagles> baoli: yeah... I would assume that whatever assumptions you would normally need to make about a single port  would apply to multiples.. device support, whether bonding them is even workable, etc.
14:02:04 <baoli> Lets continue the discussion next week.
14:02:19 <beagles> baoli: yup.. and I'll have more info then as well.. thanks!
14:02:33 <pczesno> thanks, bye
14:02:38 <baoli> beagles, I guess that we'll see more details once your spec is up.
14:02:55 <baoli> thanks everyone
14:02:59 <baoli> #endmeeting