| *** kleini_ is now known as kleini | 06:13 | |
| ralonsoh | gmann, hi, I have the results of the doodle poll for the Neutron scheduling | 07:46 |
|---|---|---|
| ralonsoh | and the operator hour | 07:46 |
| ralonsoh | gmann, how can I request that in https://ptg.opendev.org/ptg.html ? | 07:47 |
| zigo | Does anyone have a clue why I'm getting this in networking-bagpipe's autopkgtest? | 08:04 |
| zigo | https://ci.debian.net/data/autopkgtest/testing/amd64/n/networking-bagpipe/26529457/log.gz | 08:04 |
| ralonsoh | zigo, we removed the automatic config options registry when the conf module where loaded | 08:08 |
| ralonsoh | that means you need to explicitly load this config var in this test, most probably | 08:08 |
| zigo | ralonsoh: So that's really a bug in networking-bagpipe... | 08:09 |
| ralonsoh | in this UT, yes | 08:10 |
| zigo | ralonsoh: Could you point at the code that needs to be added? Like, in another plugin, for example? | 08:20 |
| ralonsoh | zigo, let me check | 08:21 |
| zigo | Thanks. | 08:21 |
| ralonsoh | zigo, I can't reproduce it locally | 08:32 |
| zigo | :/ | 08:33 |
| ralonsoh | is this a CI execution? | 08:33 |
| zigo | Debian CI yes. | 08:33 |
| zigo | ie, what's in debian/tests ... | 08:33 |
| ralonsoh | if you run tox -py38, that works fine | 08:33 |
| zigo | Debian Unstable / testing has Pythyon 3.10 (but it doesn't seem the issue here is the interpreter version) | 08:34 |
| zigo | BTW, the "it works with tox" is a bit like "it works on my laptop" to me... :) | 08:34 |
| ralonsoh | no, this is the UT environment for the unit tests | 08:35 |
| ralonsoh | this is how the projects run those tests | 08:35 |
| zigo | Yeah, which is limited to the way the OpenStack CI runs ... :) | 08:35 |
| ralonsoh | no, you can execute the same commands | 08:35 |
| * zigo tries again to build the package locally | 08:36 | |
| ralonsoh | ok, I reproduced it | 08:36 |
| ralonsoh | running "python -m stestr run --parallel --subunit networking_bagpipe\.tests\.unit.*" | 08:36 |
| ralonsoh | but we can't change the code or the tests to fix this execution method | 08:37 |
| zigo | That's what my packaging does... | 08:37 |
| zigo | https://salsa.debian.org/openstack-team/neutron-plugins/networking-bagpipe/-/blob/debian/zed/debian/tests/unittests | 08:37 |
| zigo | pkgos-dh_auto_test is just a small wrapper that starts stestr (or testrepository if the package still uses that...). | 08:38 |
| zigo | Weird, the tests are passing on my laptop too... | 08:38 |
| zigo | I'll re-trigger the checks and see how it goes. | 08:42 |
| zigo | It passed on arm64, which is weird, probably that's the only arch that had up-to-date dependencies. | 08:42 |
| lajoskatona | ralonsoh: you can do such thing via the #openinfra-events channel | 09:06 |
| lajoskatona | ralonsoh: https://opendev.org/openstack/ptgbot/src/branch/master | 09:07 |
| lajoskatona | ralonsoh: for what commands work for the PTGBot | 09:08 |
| ralonsoh | lajoskatona, ah, let me check the doc | 09:10 |
| ralonsoh | lajoskatona, do you know how to book the operator hour? | 09:35 |
| ralonsoh | I've done the neutron part | 09:35 |
| ralonsoh | btw, thanks a lot | 09:36 |
| lajoskatona | ralonsoh: +1 | 09:42 |
| lajoskatona | ralonsoh: no idea for the operators hour, perhaps slaweq, as he has TC background | 09:44 |
| ralonsoh | lajoskatona, I need to register this path | 09:44 |
| ralonsoh | I'm on it now | 09:44 |
| opendevreview | Merged openstack/neutron master: Port provisioning should retry only for VM ports https://review.opendev.org/c/openstack/neutron/+/859645 | 11:46 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron stable/zed: Port provisioning should retry only for VM ports https://review.opendev.org/c/openstack/neutron/+/859914 | 11:48 |
| slaweq | ralonsoh I will find email with info about it but in about 1h as I need to leave for some time now | 12:10 |
| ralonsoh | slaweq, don't worry, is done | 12:59 |
| ralonsoh | thanks! | 12:59 |
| opendevreview | Lajos Katona proposed openstack/neutron master: Update grenade skip level jobs for new release https://review.opendev.org/c/openstack/neutron/+/859991 | 13:22 |
| slaweq | ralonsoh great, thx :) | 13:26 |
| lajoskatona | ralonsoh: I updated my calendar :-) | 13:35 |
| ralonsoh | perfect! | 13:36 |
| *** dasm|off is now known as dasm | 13:39 | |
| lajoskatona | #startmeeting neutron_drivers | 14:01 |
| opendevmeet | Meeting started Fri Sep 30 14:01:19 2022 UTC and is due to finish in 60 minutes. The chair is lajoskatona. Information about MeetBot at http://wiki.debian.org/MeetBot. | 14:01 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 14:01 |
| opendevmeet | The meeting name has been set to 'neutron_drivers' | 14:01 |
| lajoskatona | o/ | 14:01 |
| mlavalle | o/ | 14:01 |
| rubasov | o/ | 14:01 |
| amotoki | o/ | 14:01 |
| ralonsoh | hi | 14:01 |
| haleyb | hi | 14:02 |
| slaweq | hi | 14:02 |
| lajoskatona | I think we can start | 14:03 |
| lajoskatona | [RFE] Expose Open vSwitch other_config column in the API (#link https://bugs.launchpad.net/neutron/+bug/1990842 ) | 14:03 |
| lajoskatona | rubasov: perhaps you have some background for this RFE ? | 14:04 |
| rubasov | sure | 14:04 |
| rubasov | this is basically another telco performance tuning idea | 14:04 |
| rubasov | the biggest drawback is clearly that it would expose backend specific info in the API | 14:05 |
| rubasov | but I could not come with an idea to make this backend agnostic | 14:05 |
| slaweq | would it be exposed for everyone or admin only? | 14:05 |
| rubasov | so instead tried to go the very explicit way | 14:05 |
| rubasov | I believe binding_profile is accessible for every user | 14:06 |
| lajoskatona | binding-profile is admin only, isn't it? | 14:06 |
| amotoki | yes, it is only for admin by the default policy. | 14:07 |
| slaweq | admin only, yes | 14:07 |
| slaweq | I just checked it | 14:07 |
| rubasov | sorry for the misinformation then :-) | 14:07 |
| slaweq | so IMO it's not that big deal if we will expose it for admin users | 14:07 |
| ralonsoh | we should avoid writing in the binding profile, this should be populated only by Nova | 14:08 |
| slaweq | maybe we can add another field to the port? | 14:08 |
| ralonsoh | if we want to add a specific port config, we can create a new extension and pass this in other parameter, not the binding profile | 14:08 |
| slaweq | like "extra_config" or something like that | 14:08 |
| slaweq | or "tunnables" | 14:08 |
| lajoskatona | slaweq: thanks, I did the same to be sure :-) | 14:09 |
| slaweq | and then each backend may use it for something else if needed | 14:09 |
| rubasov | I am okay with that, though it's new to me that binding_profile is exclusive to nova | 14:09 |
| lajoskatona | sounds reasonable, as binding profile seems sometimes overloaded | 14:09 |
| mlavalle | yeah, that makes it a bit more agnostic | 14:09 |
| ralonsoh | rubasov, we have been using it incorrectly, but this field should be populated only by Nova | 14:10 |
| rubasov | okay, that explains my vague memories | 14:10 |
| rubasov | and also okay, I can come up with a new port attribute for this | 14:10 |
| lajoskatona | In this case we should have a spec with the details | 14:11 |
| ralonsoh | do we want to implement a generic field for this, that could be used in a future for other features? | 14:12 |
| lajoskatona | ralonsoh: you mean to write any dict to other-config or similar? | 14:13 |
| ralonsoh | e.g.: port[extra_config] = {ovs_other_config: {}, 'future_other_config': {} } | 14:13 |
| rubasov | and I guess if the new field is also admin only, then we can expose the whole other_config, not just tx_steering | 14:13 |
| ralonsoh | right | 14:13 |
| rubasov | or port[backend_tuning] = {ovs: ..., ...} | 14:13 |
| ralonsoh | that's a good proposal too | 14:14 |
| ralonsoh | but yes, we need a spec for this, I think | 14:14 |
| slaweq | yes, it should be admin only | 14:14 |
| rubasov | sure, spec is the next step if drivers agree with the basic idea | 14:14 |
| slaweq | and if we are going to add new field then question about api extension is already answered - yes, we need extension :) | 14:15 |
| rubasov | okay :-) | 14:15 |
| lajoskatona | Yeah, let's vote to have the formalities then | 14:15 |
| lajoskatona | +1 from me for new extension and port field | 14:16 |
| lajoskatona | and spec :-) | 14:16 |
| amotoki | +1 for adding a new extension for a port field. | 14:16 |
| mlavalle | +1 | 14:16 |
| haleyb | +1 | 14:16 |
| ralonsoh | +1 | 14:16 |
| slaweq | +1 | 14:17 |
| lajoskatona | Thanks, I will update the RFE, and thanks rubasov for proposing this topic | 14:17 |
| lajoskatona | I have one more (I hope) small thing which was not in the agenda originally | 14:18 |
| mlavalle | it seems we all love our telco users | 14:18 |
| lajoskatona | Add new vif type linkvirt_ovs https://review.opendev.org/c/openstack/neutron-lib/+/859573 | 14:18 |
| slaweq | mlavalle yeah, we have to :) | 14:18 |
| lajoskatona | nova-spec: https://review.opendev.org/c/openstack/nova-specs/+/859290 | 14:18 |
| rubasov | if anyone has opinions on the discussion topics left in the launchpad ticket, please share there even before I upload the spec | 14:18 |
| rubasov | and thanks everyone for your attention | 14:19 |
| mlavalle | slaweq: come on, it's not that we have to. We genuinly love them ;-) | 14:19 |
| slaweq | 😀 | 14:19 |
| haleyb | they pay the bills :) | 14:19 |
| slaweq | haleyb exactly ;) | 14:19 |
| *** dkehn__ is now known as dkehn | 14:19 | |
| lajoskatona | ok, so the small topic is for "Add new vif type linkvirt_ovs", which is for napatech smartnic | 14:20 |
| lajoskatona | The proposed a neutron-lib change: https://review.opendev.org/c/openstack/neutron-lib/+/859573 | 14:21 |
| lajoskatona | and they have a nova spec: https://review.opendev.org/c/openstack/nova-specs/+/859290 | 14:21 |
| lajoskatona | As I checked for similar changes we have no spec or RFE in the past (at least what I found) | 14:21 |
| lajoskatona | question is it enough that the nova-spec describes this change or shall we ask some formal writing for neutron too? | 14:22 |
| slaweq | IMHO it's enough | 14:22 |
| lajoskatona | I found the metronome smartnic as similar "project: https://review.opendev.org/q/topic:netronome-smartnic-enablement | 14:22 |
| lajoskatona | slaweq: ok, thanks | 14:22 |
| ralonsoh | if each manufacturer is going to create its own plugin method, we'll have a problem in Nova-Neutron | 14:23 |
| lajoskatona | then, let's continue with it on the n-lib change review | 14:23 |
| slaweq | ralonsoh why? | 14:23 |
| ralonsoh | because we'll need to create a plug method for each one | 14:23 |
| ralonsoh | at least in os-vif | 14:24 |
| ralonsoh | and probably in the ML2 plugin, like with smartnics | 14:24 |
| ralonsoh | and, of course, we can't test it in the CI | 14:24 |
| ralonsoh | anyway, this is rant, nothing else | 14:25 |
| lajoskatona | ralonsoh: thanks | 14:25 |
| lajoskatona | ralonsoh: good to keep in mind that we should have problems with the integration of other hardwares like this | 14:25 |
| lajoskatona | that's it from me, thanks for the discussion of this topic | 14:26 |
| lajoskatona | #topic On Demand Agenda | 14:26 |
| lajoskatona | Do you have anything to discuss? | 14:26 |
| liuyulong | Hi, there | 14:26 |
| lajoskatona | liuyulong: Hi | 14:27 |
| lajoskatona | welcome | 14:27 |
| liuyulong | I have a technical question. | 14:27 |
| slaweq | ralonsoh ok, I see now | 14:27 |
| liuyulong | Something about smart NIC offloading and neutron tunning bridge. | 14:27 |
| liuyulong | Since neutron can support vlan and vxlan tunnel in one same host | 14:28 |
| liuyulong | did you guys played with smartnics for vlan and vxlan offloading in same host? | 14:29 |
| liuyulong | We have tested neutron ovs bridge topology. | 14:29 |
| * slaweq needs to drop for another meeting, sorry | 14:29 | |
| slaweq | have a great weekend! | 14:29 |
| slaweq | o/ | 14:29 |
| lajoskatona | slaweq: Bye | 14:29 |
| liuyulong | But since the vxlan ports are set in br-tunning, but some NICs may need tunnel to be set in br-int. | 14:30 |
| mlavalle | o/ | 14:30 |
| rubasov | I have a colleague who wanted to, but had problems with that nova unconditionally chooses the vlan segment, but he wanted offload on the vxlan segment | 14:30 |
| liuyulong | So I suppose if we can move the tunnels to br-int instead. | 14:30 |
| ralonsoh | sorry, br-tunning is the bridge for tunneled networks? | 14:30 |
| liuyulong | yes, we test it, but the vxlan UDP_4789 packets cannot be transimit to vxlan tunnel in br-tunning. | 14:31 |
| rubasov | (but his problem was only present when using multi-segment networks) | 14:31 |
| ralonsoh | but why you can't transmit those packets to the tunnel bridge? | 14:32 |
| liuyulong | #link https://github.com/openvswitch/ovs/blob/master/Documentation/howto/userspace-tunneling.rst | 14:32 |
| liuyulong | this is the vtep_IP and bridge settings. | 14:33 |
| liuyulong | For vxlan offloading, we test it in same configuration. | 14:33 |
| liuyulong | Not sure why it is not, maybe its a ovs/ovs-dpdk bug. | 14:33 |
| liuyulong | #link https://docs.nvidia.com/networking/pages/viewpage.action?pageId=80592948#OVSOffloadUsingASAP%C2%B2Direct-OffloadingVXLANEncapsulation/DecapsulationActions | 14:34 |
| ralonsoh | ok, so the problem is that you are using HW offload with DPDK | 14:34 |
| liuyulong | This is the NIC vendors' setting, it is basically same to the OVS guides. | 14:34 |
| ralonsoh | in this case you need to manually use the trick used in DPDK | 14:35 |
| ralonsoh | sending the tunneled traffic trhough the physical bridge | 14:35 |
| ralonsoh | because you can't send the tunneled traffic to the kernel (you'll lost the advantage of DPDK) | 14:36 |
| liuyulong | ovs-dpdk with rte_flow to offload to the NIC eswitch. | 14:36 |
| liuyulong | The topoloy can work is: PF---> br-physial-> br-int(with vxlan ports) | 14:37 |
| liuyulong | The topology can not work: PF--->br-physial ----> br-int --- br-tun (with vxlan ports) | 14:37 |
| ralonsoh | this is not the architecture (but I would need to check that) | 14:38 |
| ralonsoh | PF -> br-phy -> br-tun -> br-int | 14:38 |
| liuyulong | PF---> br-physial-> br-int(with vxlan ports), in such case, both packets from vlan tenant networks and vxlan networks can all get offloaded. | 14:38 |
| ralonsoh | you need to send the traffic to br-tun for the VXLAN-VLAN conversion | 14:39 |
| liuyulong | ralonsoh, yes, I want to send packets to br-tun in the 2nd topolgy. But it does not. | 14:40 |
| ralonsoh | I don't find the document now, but please check how it was described in networkin-ovs-dpdk | 14:41 |
| liuyulong | So, my question will be, if it is acceptable to move vxlan tunnel ports to br-int with some configurations if users want to use offloading features. | 14:42 |
| ralonsoh | why? you don't need that | 14:42 |
| liuyulong | ralonsoh, you can see the verdors' page. | 14:42 |
| liuyulong | Because "The topology can not work: PF--->br-physial ----> br-int --- br-tun (with vxlan ports)" | 14:43 |
| ralonsoh | PF -> br-phy -> br-tun -> br-int | 14:43 |
| ralonsoh | check how is done now with DPDK and tunneled networks | 14:43 |
| liuyulong | Then " PF -> br-phy -> br-tun -> br-int" how vlan networks go? | 14:44 |
| ralonsoh | via br-phy | 14:44 |
| liuyulong | To where? | 14:44 |
| lajoskatona | to br-int from br-phy, not? | 14:44 |
| liuyulong | Then a loop created. | 14:44 |
| ralonsoh | you can use a second phy bridge for this tunneled traffic | 14:45 |
| liuyulong | But offloading packets can only to ONE single NIC... | 14:45 |
| ralonsoh | ok, so you can have one network | 14:45 |
| ralonsoh | choose one: vlan or tunneled | 14:46 |
| liuyulong | But why? Neutron natively supports vlan and vxlan in same node at same time. | 14:46 |
| ralonsoh | but not via the same interface | 14:47 |
| liuyulong | ovs-dpdk can not offload flows to multiple NIC. | 14:48 |
| ralonsoh | maybe you can use nic partioning | 14:49 |
| ralonsoh | if that is supported in that HW | 14:49 |
| mlavalle | lajoskatona: maybe time to close the meeting? This conversation can continue in the channel anyway | 14:49 |
| ralonsoh | right | 14:49 |
| liuyulong | OK | 14:49 |
| lajoskatona | malavalle: yeah, thanks | 14:50 |
| lajoskatona | ralonsoh, liuyulong: thanks for the discussion, but let's close the meeting to keep others time | 14:50 |
| liuyulong | I have no ideas about nic partioning. I will google it. But I don't think it can work in offloading case. | 14:50 |
| liuyulong | Sure | 14:50 |
| liuyulong | Thanks for the time. | 14:50 |
| lajoskatona | Thanks for attending the meeting | 14:51 |
| lajoskatona | #endmeeting | 14:51 |
| opendevmeet | Meeting ended Fri Sep 30 14:51:07 2022 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 14:51 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/neutron_drivers/2022/neutron_drivers.2022-09-30-14.01.html | 14:51 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/neutron_drivers/2022/neutron_drivers.2022-09-30-14.01.txt | 14:51 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/neutron_drivers/2022/neutron_drivers.2022-09-30-14.01.log.html | 14:51 |
| lajoskatona | Have a nice weekend, bye | 14:51 |
| mlavalle | liuyulong: you don't need to go or stop the conversation. I just suggested to close the meeting so we don't forget and let it running several days. It's happened in the past | 14:51 |
| mlavalle | liuyulong: by all means, carry on | 14:52 |
| liuyulong | Yes, It's fine. | 14:52 |
| lajoskatona | liuyulong: you can even add a topic for the PTG pad if you think there's something we can discuss during the october PTG | 14:52 |
| mlavalle | that is also an option | 14:53 |
| ralonsoh | https://etherpad.opendev.org/p/neutron-antelope-ptg | 14:53 |
| ralonsoh | ^^ this is the right place to have this conversation | 14:53 |
| ralonsoh | and with a wider audience | 14:53 |
| liuyulong | So, if you guys have any chance to test offloading cases. It will be nice. | 14:53 |
| rubasov | ralonsoh: btw do you have some sources for why binding_profile is exclusive to nova? I was just following the api-ref in proposing binding_profile earlier and currently there's nothing there about this. I would happily update the api-ref though with this info | 14:54 |
| ralonsoh | sean-k-mooney, ^ maybe Sean can provide better info about this | 14:54 |
| rubasov | okay, thanks | 14:55 |
| amotoki | IIRC port binding was defined for nova-neutron communications and it is not for API users -to- network backend communications. | 14:57 |
| amotoki | on the other hand, bidning profle is defined as a dict so it tends to be interpreted as blob and backend implementations tried to use to pass infomration via neutron APi to the backend. | 14:58 |
| amotoki | it is not a free area so we need to draw a line at some point. | 14:58 |
| amotoki | that's my memory. | 14:58 |
| amotoki | but perhaps it is not documented well. | 14:58 |
| amotoki | rubasov: the above is my understanding, but I could not find a good source so far..... | 14:59 |
| rubasov | amotoki: makes sense, thanks | 15:00 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: Since OVN 20.06, config is stored in "Chassis.other_config" https://review.opendev.org/c/openstack/neutron/+/859642 | 15:19 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron stable/yoga: Script to remove duplicated port bindings https://review.opendev.org/c/openstack/neutron/+/859996 | 15:23 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron stable/xena: Script to remove duplicated port bindings https://review.opendev.org/c/openstack/neutron/+/859997 | 15:24 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron stable/wallaby: Script to remove duplicated port bindings https://review.opendev.org/c/openstack/neutron/+/859998 | 15:35 |
| *** dkehn__ is now known as dkehn | 15:48 | |
| opendevreview | Arnau Verdaguer proposed openstack/neutron master: [ovn migrationa] Use ecsda ssh key instead of rsa https://review.opendev.org/c/openstack/neutron/+/860002 | 16:03 |
| sean-k-mooney | ralonsoh: re binding-profile it was intoduced to allow the hypervior to proived infomation to the network backend in a 1 way manner where only they hypervior driver shal write to it. in otherwards the assumtion is that since the info contained in it was create by nova/zun or ironic and no other user is allwoed to add info to it or modify it that it is safe to use that info | 16:08 |
| sean-k-mooney | directly | 16:09 |
| sean-k-mooney | so its a security risky to allow anything else to modify its content | 16:09 |
| sean-k-mooney | or to use it for other uses as it coudl cause name collions | 16:09 |
| sean-k-mooney | port-bindigns on the other hand provide 1 way comunciaton form neutron to nova | 16:10 |
| ralonsoh | sean-k-mooney, you mean nova to neutron, right? | 16:10 |
| sean-k-mooney | no | 16:10 |
| sean-k-mooney | well indirecly | 16:10 |
| sean-k-mooney | the binding profile was created orginally to pass info form nova to the sriov nic agent | 16:11 |
| sean-k-mooney | but the content was ment to be potentially backend specific | 16:11 |
| sean-k-mooney | so its unversioned form the neutron api point fo view | 16:12 |
| sean-k-mooney | so you can thinke of binding-deails as neutron->nova and binding-profile as nova->neutron or neutron network backend | 16:13 |
| ralonsoh | sean-k-mooney, should we provide this info in other object field? | 16:13 |
| ralonsoh | from Neutron I mean | 16:13 |
| sean-k-mooney | i dont see why that woudl be helpful | 16:14 |
| sean-k-mooney | https://github.com/openstack/neutron-lib/blob/master/neutron_lib/api/definitions/portbindings.py#L31-L34 | 16:14 |
| ralonsoh | you said Neutron shouldn't modify the binding profile | 16:14 |
| sean-k-mooney | correct it never should | 16:14 |
| sean-k-mooney | neutron should only modify the bindin details field | 16:15 |
| ralonsoh | https://github.com/openstack/neutron-lib/blob/master/neutron_lib/api/definitions/portbindings.py#L27 | 16:15 |
| ralonsoh | ? | 16:15 |
| sean-k-mooney | yes https://github.com/openstack/neutron-lib/blob/master/neutron_lib/api/definitions/portbindings.py#L24-L27 | 16:15 |
| sean-k-mooney | is for neutron to nova/ironic/zun comunciation | 16:16 |
| sean-k-mooney | binding:vif_details is entirly generated by neutron via the mech drivers | 16:16 |
| sean-k-mooney | and neutron can add any info it wants there | 16:16 |
| ralonsoh | we really need to document this, we are again in A release and we still have these questions | 16:16 |
| sean-k-mooney | well its documented in the comments of the api extension | 16:17 |
| sean-k-mooney | we have two abuses of the binding:profile today | 16:17 |
| ralonsoh | I know | 16:17 |
| sean-k-mooney | trusted_vfs and hardware offloads | 16:17 |
| sean-k-mooney | ill fix hardware offload this cycle | 16:17 |
| ralonsoh | yes, we need to fix that in the next release | 16:18 |
| sean-k-mooney | i might be able to backport it too by the way | 16:18 |
| sean-k-mooney | ill need to discuss that with the nova core team | 16:18 |
| sean-k-mooney | i.e. will this be a bugfix or feature | 16:18 |
| ralonsoh | sean-k-mooney, please, propose this topic for the x-team sessions | 16:18 |
| sean-k-mooney | sure i can | 16:18 |
| ralonsoh | https://etherpad.opendev.org/p/neutron-antelope-ptg | 16:19 |
| sean-k-mooney | i confirmed we already have the infor from libvirt | 16:19 |
| ralonsoh | there is, at the botton, a x-team topic section | 16:19 |
| sean-k-mooney | so i was just going to add all the nic feature flags to the bining profile | 16:19 |
| ralonsoh | is already there | 16:19 |
| ralonsoh | maybe I can move it | 16:19 |
| sean-k-mooney | am im still off today but ill try and get a poc patch up before the ptg | 16:20 |
| sean-k-mooney | i hope it will be accpeted as a bugfix and i can just backport it basically to every supproted release | 16:20 |
| sean-k-mooney | by the way ovs-dpdk can have multiple physical nics | 16:22 |
| sean-k-mooney | and you can have vxlan and vlan traffic served by ovs-dpdk with differnt nic for each if you like | 16:23 |
| sean-k-mooney | ralonsoh: lajoskatona: ^ | 16:24 |
| ralonsoh | sean-k-mooney, yes, but you need several nics, right? | 16:24 |
| sean-k-mooney | so its totally fine to have 1 nic and use it for both vxlan and vlan with ovs dpdk or you can have two nics and use one for each | 16:24 |
| sean-k-mooney | nope | 16:24 |
| sean-k-mooney | you only need one | 16:24 |
| ralonsoh | you can redirect the tunnelled traffic through br-phy | 16:25 |
| sean-k-mooney | if you only have one nic for dpdk then you assign the tunnel_endpoint ip to the br-ex | 16:25 |
| ralonsoh | do you have docs aboyt this? | 16:25 |
| ralonsoh | if I'm not wrong, this is what was configured by the devstack scripts of networking-ovs-dpdk | 16:26 |
| sean-k-mooney | its the default config we used to do in networking-ovs-dpdk and tripleo should do it | 16:26 |
| ralonsoh | right | 16:26 |
| ralonsoh | so there we have the description of how to implement it | 16:26 |
| ralonsoh | deploy it | 16:26 |
| ralonsoh | liuyulong, ^ | 16:26 |
| sean-k-mooney | so both networking-ovs-dpdk and tripleo should do it today and i think i implemted it in kolla to | 16:26 |
| ralonsoh | sean-k-mooney, did we test vlan and tunnelled traffic at the same time? | 16:27 |
| sean-k-mooney | all you really have to do is bring up the bridge local interface on the bridge with the dpdk port | 16:27 |
| sean-k-mooney | and then assign the tunnel local ip to that bridge | 16:27 |
| ralonsoh | ah ok, so assign to the phy interface the tunnel IP | 16:27 |
| sean-k-mooney | no traffic will flow over that bride local port via the kernel | 16:27 |
| sean-k-mooney | not quite | 16:27 |
| sean-k-mooney | the tunnel ip is on the ovs bridge | 16:28 |
| sean-k-mooney | not the dpdk interface since the dpdk interface is not bound to a kernel driver | 16:28 |
| ralonsoh | yes | 16:28 |
| sean-k-mooney | ovs has a undocumented | 16:28 |
| ralonsoh | but what bridge? | 16:28 |
| sean-k-mooney | feature | 16:28 |
| ralonsoh | the physical bridge | 16:28 |
| sean-k-mooney | br-phy | 16:28 |
| ralonsoh | ok yes | 16:28 |
| sean-k-mooney | whichi normally call br-ex | 16:28 |
| ralonsoh | right | 16:28 |
| sean-k-mooney | anyway teh undocumented feature is as follows | 16:29 |
| sean-k-mooney | when using tunneling ovs queries the routing table to determin the interface to use to transmit the encaulated packet | 16:29 |
| sean-k-mooney | if the ip is asstined to an ovs bridge instead of sending the packet to the kernel | 16:30 |
| sean-k-mooney | a outport action (not output) | 16:30 |
| sean-k-mooney | is added that instead enques the packet logically on the recive queue of the bridge interface | 16:30 |
| sean-k-mooney | so at the openflow level it looks like the packet is encapulstated on teh br-tun | 16:31 |
| sean-k-mooney | and then recived on the br-phy | 16:31 |
| sean-k-mooney | and then the normal action sends it to the dpdk interface due to maclarning/arp | 16:31 |
| ralonsoh | at this point, this is the overlay traffic | 16:31 |
| sean-k-mooney | at the dataplane leave because the br-phy is connected to the br-int with a patch port and the br-int is connect to the br-tun via a ptach port | 16:32 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron stable/yoga: [stable-only] Add writer DB context to "add_provisioning_component" https://review.opendev.org/c/openstack/neutron/+/860005 | 16:32 |
| sean-k-mooney | what actully get generated in teh dataplane flows is push vxlan header and ouput dpdk1 | 16:32 |
| ralonsoh | right, yes | 16:32 |
| sean-k-mooney | so there is no copying or anything all the bridge get collapsed into a singel dpdk dataplane and ovs just pushes the header and transmits it out the physical interface | 16:33 |
| sean-k-mooney | this only works this way if all 3 bridge are joined via patch ports | 16:33 |
| sean-k-mooney | if you are using the br-phy for vlan trafic neutron will do that for you if using the ovs agent | 16:34 |
| ralonsoh | we don't (shouldn't) support any other bridge connectivity | 16:34 |
| ralonsoh | yes | 16:34 |
| sean-k-mooney | well neutorn only does it automatically if you list the bridge in the brige physnet mappings | 16:35 |
| sean-k-mooney | otherwise it will jsut be a standalone bridge | 16:35 |
| sean-k-mooney | in which case you packet go via the kernel | 16:35 |
| ralonsoh | ok, I'll check that on Monday | 16:36 |
| ralonsoh | I need to leave now, sorry | 16:36 |
| ralonsoh | thanks a lot! | 16:36 |
| sean-k-mooney | so becauses im lazy and dont feel like creating the patch port by hand i alsway enbale both vlan and vxlan so that neutron will do it | 16:36 |
| sean-k-mooney | no worries | 16:36 |
| sean-k-mooney | just one other thing | 16:37 |
| ralonsoh | yeah | 16:37 |
| sean-k-mooney | you can do the exact same toplogy for kernel ovs or ovs hardware offload | 16:37 |
| sean-k-mooney | if you dont want the vxlan trafic to go over the managemnt interface | 16:37 |
| ralonsoh | actually that was the topic: HWOL and DPDK | 16:37 |
| sean-k-mooney | and instead use the ovs interface | 16:37 |
| sean-k-mooney | basically the rule is if you want your tunnel and vlan/flat traffic to go over the saem interface put the tunnel_ip on the ovs bridge (br-phy/br-ex) | 16:38 |
| sean-k-mooney | it will work the same for all backends | 16:39 |
| sean-k-mooney | if all the bridge have patch ports and ovs sees the tunnel ip is on an ovs bridge it will use the optimisation | 16:39 |
| opendevreview | Fernando Royo proposed openstack/neutron master: Check subnet overlapping after add router interface https://review.opendev.org/c/openstack/neutron/+/859143 | 16:40 |
| opendevreview | kiran pawar proposed openstack/neutron-lib master: Use oslo_context.from_dict() for context generation https://review.opendev.org/c/openstack/neutron-lib/+/859813 | 17:15 |
| gmann | ralonsoh: thanks, I think you all set for booked slot. please let me know if still any help needed | 18:06 |
| opendevreview | Luis Tomas Bolivar proposed openstack/ovn-octavia-provider master: [WIP] Ensure lbs are properly configured for router gateway set/unset https://review.opendev.org/c/openstack/ovn-octavia-provider/+/858363 | 18:19 |
| liuyulong | It's fine to config ovs-dpdk with vxlan tunnels. But with offloading settings, the tunnel encap/decap can not be offloaded in the topology of this "PF--->br-physial (vtep IP) ---- br-int --- br-tun (with vxlan ports)". This maybe a ovs-dpdk or vendor driver bug. | 18:37 |
| *** dasm is now known as dasm|off | 21:17 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!