14:00:39 <ralonsoh> #startmeeting neutron_drivers
14:00:39 <opendevmeet> Meeting started Fri Apr 14 14:00:39 2023 UTC and is due to finish in 60 minutes.  The chair is ralonsoh. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:39 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:39 <opendevmeet> The meeting name has been set to 'neutron_drivers'
14:00:40 <ralonsoh> hello
14:00:43 <lajoskatona> o/
14:00:46 <obondarev> o/
14:01:14 <dvo-plv> hello
14:01:17 <ralonsoh> the agenda: https://wiki.openstack.org/wiki/Meetings/NeutronDrivers
14:01:58 <ralonsoh> ok, let's start because the agenda is packed today
14:02:05 <ralonsoh> first topic
14:02:09 <ralonsoh> #link https://bugs.launchpad.net/neutron/+bug/2012332
14:02:17 <ralonsoh> from liu
14:02:25 <ralonsoh> but I don't think he is here
14:02:31 <rubasov> o/
14:02:48 <ralonsoh> do you want to discuss it?
14:03:05 <ralonsoh> or do you want me to ping the author to be present?
14:03:32 <lajoskatona> we can I suppose
14:03:46 <ralonsoh> ok then
14:03:48 <mlavalle> ralonsoh: can I make a suggestion?
14:03:52 <ralonsoh> sure
14:04:02 <lajoskatona> The idea looks ok, and as amotoki commented a similar aproach what we have for routes can be used for allowed-addresses also
14:04:10 <mlavalle> dvo-plv is here. why don't we discuss his RFE?
14:04:21 <lajoskatona> +1
14:04:49 <ralonsoh> mlavalle, we have already started with this one
14:05:18 <slaweq> I think that https://bugs.launchpad.net/neutron/+bug/2012332 is reasonable request and I'm +1 on this
14:05:26 <ralonsoh> my question about this new API is that, eventually, you need to update the port
14:05:32 <ralonsoh> so you'll take the same time
14:05:40 <slaweq> I don't really think there is much to discuss there, amotoki basically summarized it in his comment perfectly
14:06:07 <ralonsoh> yes and we are providing the same API for routes
14:06:15 <obondarev> I also think it more about user experience than performance
14:06:19 <ralonsoh> but that will improve the server time?
14:06:20 <slaweq> time maybe yes but it will be atomic API (similar to what we have for extra routes) so
14:06:25 <ralonsoh> obondarev, exactly
14:06:35 <slaweq> ++
14:06:37 <lajoskatona> +1
14:06:48 <mlavalle> I'm ok with this RFE
14:07:01 <ralonsoh> perfect, I think there is agreement
14:07:05 <ralonsoh> one qq: do we need spec?
14:07:06 <mlavalle> amotoki summarized well the point
14:07:12 <ralonsoh> (IMO I don't think so)
14:07:23 <mlavalle> I don't think so either?
14:07:43 <slaweq> no spec needed IMO
14:07:50 <mlavalle> +1
14:07:54 <obondarev> yeah, looks it just about adding new API extension, not much to rework
14:08:05 <ralonsoh> perfect, I'll update the bug after this meeting
14:08:09 <ralonsoh> thanks folks
14:08:42 <ralonsoh> ok, lajoskatona, if you don't mind, I'll jump to the last one
14:09:07 <ralonsoh> next topic
14:09:11 <ralonsoh> #link https://bugs.launchpad.net/neutron/+bug/2013540
14:09:16 <ralonsoh> [RFE] Add support for Napatech LinkVirt SmartNICs
14:09:18 <lajoskatona> to the ERSPAN RFE(https://bugs.launchpad.net/neutron/+bug/2015471 )?
14:09:24 <lajoskatona> ok, so no
14:09:45 <ralonsoh> dvo-plv, please, go on
14:09:45 <dvo-plv> Hello, we are here
14:09:47 <lajoskatona> but sure, this one hangs since long time in nova-specs
14:10:23 <dvo-plv> we would like to add support for our nix to the openstack
14:11:09 <dvo-plv> we need to add support for dpdk vf representor port
14:11:29 <dvo-plv> base approach we disccused with Sean some time ago
14:12:02 <dvo-plv> in the first itteration we suggested to us separate os-vif plugin like Agilio
14:13:00 <dvo-plv> But during the disscussion with Sean he would like to extend default openvswitch driver with virtio-forwarder nic type
14:13:19 <dvo-plv> we provide poc code
14:13:44 <dvo-plv> from our specific we have next socket name stdvio + vf number
14:15:23 <lajoskatona> by POC you mean this series: https://review.opendev.org/q/topic:Napatech_SmartNIC_support ?
14:15:35 <dvo-plv> exactly
14:15:54 <ralonsoh> so basically you are re-using the VIFPortProfileOVSRepresentor
14:16:00 <ralonsoh> when a port is created
14:16:04 <dvo-plv> yes
14:16:20 <ralonsoh> but what is different from OVS with HW offload?
14:17:10 <dvo-plv> we need to set dpdk port type to the ovs port
14:17:24 <dvo-plv> and past socket to the qemu layer
14:17:28 <dvo-plv> pass*
14:17:40 <dvo-plv> with custom name stdvio + vf number
14:18:11 <dvo-plv> https://review.opendev.org/c/openstack/neutron/+/869510/3/neutron/plugins/ml2/drivers/openvswitch/mech_driver/mech_openvswitch.py#217
14:18:16 <dvo-plv> we form socket here
14:18:50 <ralonsoh> why this is not done in os-vif?
14:19:10 <ralonsoh> (we had this conversation some years ago when agilio implemented this code in ovs agent)
14:19:53 <dvo-plv> because we need to fill details for nova to create qemu command with socekt path
14:20:26 <dvo-plv> we are open for code changes according to your better vision
14:20:35 <sahid> i guess dvo-plv is just following the current implementation
14:21:22 <ralonsoh> ok, we can discuss this in the patches
14:21:22 <dvo-plv> yes, we tried to make less changes according to the Sean's vision
14:21:25 <obondarev> so you need to create neutron port with specific parameters first, and then pass it to nova?
14:22:29 <dvo-plv> We need to form socket name and pass this socket to the nova to form qemu command, also we need to form vf number for ovs command
14:22:45 <dvo-plv> ovs-vsctl add-port br-int representor6 -- set Interface representor6 type=dpdk "options:dpdk-devargs=0000:65:00.0,representor=[6]
14:22:57 <dvo-plv> this is ovs command which we need for out port
14:23:09 <obondarev> ah, I see
14:23:12 <dvo-plv> representor=[6] this vf numver forms with next formual
14:23:23 <dvo-plv> vf_num = int(slot) * 8 + int(func)
14:23:24 <ralonsoh> yes but this is provided by Nova, not in the Neutron port definition
14:23:50 <ralonsoh> the PCI address and the VF is retrieved from Nova and the VF
14:24:22 <ralonsoh> what do you need to create a Neutron port? this is related to another question: type=dpdk, this is a new datapath in OVS?
14:24:56 <dvo-plv> I believe no, this datapath is supporter by vanilla ovs
14:25:31 <dvo-plv> yes, we get pci in the nova, but neutron form details dict here
14:25:32 <dvo-plv> https://review.opendev.org/c/openstack/neutron/+/869510/3/neutron/plugins/ml2/drivers/openvswitch/mech_driver/mech_openvswitch.py#193
14:26:06 <dvo-plv> so we follow the existing approach
14:26:30 <ralonsoh> so you need to set the vnic type and populate the port profile
14:26:48 <ralonsoh> I'm askign that because this is not in the nova spec
14:27:00 <ralonsoh> and I would like to have this somewhere
14:27:09 <dvo-plv> yes, we need to fill port profile with dpdk port type and socket name
14:28:03 <ralonsoh> if we agreed not to request a spec for this feature, at least we'll need some kind of documentation
14:28:03 <dvo-plv> okay, How we need to screen this information. does it should be done formwhere in the RFE?
14:28:15 <ralonsoh> ^^ folks?
14:28:29 <lajoskatona> good question
14:28:44 <ralonsoh> that could also be written in the docs, in https://review.opendev.org/c/openstack/neutron/+/869510
14:28:52 <lajoskatona> do we have now such details in contrib docs?
14:29:13 <ralonsoh> nothing
14:29:36 <lajoskatona> but anyway we can find a place for such docs, so I think we can go with it, and find a place where we can document it
14:29:57 <mlavalle> on the Nova side, sean-k-mooney has indicated that he is ready to approve the spec pending we support this RFE
14:30:45 <lajoskatona> yes he left a +1 already on it
14:30:47 <mlavalle> so I think it is ok not to request yet another spec, and add our condiferations to the existing one
14:30:57 <sahid> +1
14:31:03 <sean-k-mooney> this is the dpdk hardware offload topic. if so then yes. im not sure there is enough detailin the spec for other but readign the code the general approhc look ok
14:31:14 <mlavalle> and require good documentation on the Neutron side
14:31:38 <mlavalle> yep, we have code to look at
14:31:55 <ralonsoh> it will be needed some kind of description both in the RFE and the docs (the last one is important)
14:32:04 <sean-k-mooney> mlavalle: if there are any detail form the neutron side that you think shoudl be added to the exsitng nova spec we could add them to capture that agrement
14:32:30 <mlavalle> sean-k-mooney: yeah, that was my point. lt's use the same spec
14:32:37 <sean-k-mooney> ack
14:32:37 <obondarev> +1
14:32:40 <mlavalle> you expect us to review it anyways
14:32:49 <lajoskatona> +1
14:33:02 <sean-k-mooney> in which case ya i was about to say i would like to see +1s form the neutron core team before we merge it
14:33:18 <mlavalle> yeap, I got that message :-)
14:33:23 <ralonsoh> ok, I'll add this spec to the list to be tracked weekly
14:33:25 <mlavalle> loud and clear
14:33:33 <sean-k-mooney> :)
14:33:39 <ralonsoh> so please, Neutrinos, check and review this spec
14:33:52 <lajoskatona> ack
14:34:01 <mlavalle> it's here: https://review.opendev.org/c/openstack/nova-specs/+/859290
14:34:08 <slaweq> ack
14:34:09 <sean-k-mooney> one thing i was wondering about is do wew want to detail what tests shoudl eb run in the third party ci in the spec or not
14:34:25 <ralonsoh> we discussed that in the PTG
14:34:36 <ralonsoh> first is to implement the CI
14:34:44 <ralonsoh> it doesn't matter if we run basic tests
14:34:56 <ralonsoh> but at least it should run in real HW
14:35:11 <dvo-plv> we are open to provide third-party ci/cd
14:35:23 <dvo-plv> But we would like what type of the teset we need to execute
14:35:43 <opendevreview> Slawek Kaplonski proposed openstack/neutron master: WIP [S-RBAC] Switch to new policies by default  https://review.opendev.org/c/openstack/neutron/+/879827
14:36:05 <sean-k-mooney> the netwroking basic ops senario tests and test cover span, attach/detach and move operations
14:36:06 <ralonsoh> I'll reply to this in the spec, but is expected to run basic tempest/neutron-tempest-plugin tests
14:36:09 <dvo-plv> Also we need to know to understand setup configuration for those tesets
14:36:16 <dvo-plv> okay
14:36:23 <mlavalle> in that case, let's formalize it in the spec, as suggested by sean-k-mooney. it will serve to document the approach and provide guidance to dvo-plv and his team
14:36:45 <dvo-plv> great, thank you
14:37:00 <ralonsoh> just as a formality, is the RFE approved?
14:37:02 <ralonsoh> +1 from me
14:37:06 <mlavalle> +1
14:37:11 <lajoskatona> +1
14:37:20 <obondarev> +1
14:37:22 <slaweq> +1
14:37:32 <ralonsoh> thanks folks, I'll comment that in the bug after the meeting
14:37:41 <dvo-plv> so, what is the conclustion, Does community need something from our side
14:38:08 <mlavalle> dvo-plv: let's contnue the conversation in the spec and the rest of the patches
14:38:12 <ralonsoh> the conclusion is that 1) Neutron accepts this RFE
14:38:19 <dvo-plv> okay, thank you
14:38:21 <ralonsoh> 2) we agreed on reviewing a common spec
14:38:35 <ralonsoh> and 3) we are expecting some kind of CI to test the code
14:38:44 <mlavalle> good summary
14:39:11 <mlavalle> 3 points, like very good summary
14:39:21 <mlavalle> every^^^
14:39:27 <dvo-plv> We think that we will be ready to provide ci in 1-1.5 month from today
14:39:51 <ralonsoh> that will be perfect, we can review and accept the code meanwhile (I guess)
14:40:05 <ralonsoh> if that doesn't break any existing functionality
14:40:19 <dvo-plv> Should we join to some additional meeting ?
14:40:35 <dvo-plv> for code or doc or ci review ?
14:40:44 <ralonsoh> dvo-plv, not really (but you can attend to any Neutron or Nova meeting)
14:40:45 <mlavalle> you are always welcome to the neutron meeting on tuesday 14)) utc
14:40:52 <mlavalle> but not a requirement
14:41:07 <mlavalle> gerrit is our medium of communication
14:41:07 <ralonsoh> ok, let's move
14:41:19 <ralonsoh> the agenda is packed today
14:41:22 <ralonsoh> next topic
14:41:23 <dvo-plv> thank you, have a good day
14:41:25 <ralonsoh> #link https://bugs.launchpad.net/neutron/+bug/2015471
14:41:30 <ralonsoh> [RFE] Add ERSPAN for tap-as-a-service with OVS and OVN
14:41:32 <ralonsoh> lajoskatona, please
14:41:39 <lajoskatona> thanks
14:42:11 <lajoskatona> So tap-as-a-service currently can mirror OVS or SRIOV ports' traffic to another Neutron port
14:42:44 <lajoskatona> but there is the ERSPAN which is basically also mirroring but mirroring in a tunnel (a GRE variant)
14:43:19 <lajoskatona> and both OVS and OVN support ERSPAN, so the idea is to add this kind of mirroring to taas
14:43:48 <opendevreview> yatin proposed openstack/neutron master: [DNM] Validate ovn grenade fix  https://review.opendev.org/c/openstack/neutron/+/878761
14:44:13 <lajoskatona> I tried to summarize this in the RFE, so there are questions how this can be used with current API and similar things
14:44:42 <ralonsoh> so, add an extra driver for OVS and create a new one for OVN
14:44:43 <lajoskatona> and for OVN a new driver is necessary for sure as that is not there in taas currently
14:44:44 <ralonsoh> is that correct?
14:45:10 <lajoskatona> for OVS it is just the extension of the current driver
14:45:17 <ralonsoh> ah ok ok
14:45:40 <ralonsoh> just out of curiosity (if that doesnt' take too much time)
14:45:48 <ralonsoh> what changes in OVS implementation?
14:46:39 <ralonsoh> (related to the ERSPAN and current model in the RFE)
14:46:44 <lajoskatona> with OVS you can create a port which is the source port on the bridge (br-int) for the mirror like ovs-vsctl add-port br-int -- .......
14:47:30 <lajoskatona> currently the driver creates frlows and there's an extra bridge br-tap with more flows, and that filters and directs the traffic to be mirrored to the destination port
14:48:35 <lajoskatona> but with this ERSPAN OVS creates the tunnel from the erspan port on br-int and the admin is responsible to be something on the other end of the tunnel (it can be for example a floatin-ip also, but usually something outside the cloud
14:49:13 <lajoskatona> just if you are courious I tried to doc how the current mirrring works with OVS: https://review.opendev.org/c/openstack/tap-as-a-service/+/828382
14:49:58 <mlavalle> in the rfe you state that "With ERSPAN this model is not that useful:" in regards to the  N:1 relationship between tap-flows and tap-services. can you elaborate a bit? Why is it not that useful?
14:50:34 <mlavalle> and thanks for the doc. Yes, I've always felt taas was light on docs
14:51:42 <lajoskatona> with OVS/OVN ERSPAN there will be one new port for every source
14:52:15 <mlavalle> because that is the way it is defined?
14:52:59 <slaweq> is the intention here to replace "legacy" mirroring with this new solution or just add new possibility and keep both maintained?
14:53:07 <lajoskatona> yes both the OVS and OVN implementation do that
14:53:18 <rubasov> lajoskatona will correct me if I misunderstood, but with erspan the mirror destination would be an arbitrary IP:port and not a neutron port
14:53:29 <ralonsoh> ^^ same question
14:53:30 <mlavalle> I think we will keep the legacy and add a new additional way to do it
14:53:31 <lajoskatona> It's an extension of the old/legacy
14:53:45 <lajoskatona> rubasov: yes exactly
14:54:20 <mlavalle> rubasov: ahhh, that is a good clarification. thanks
14:54:22 <lajoskatona> as I said the destination for erspan would be out of the cloud
14:54:36 <mlavalle> yeap, now I get it
14:54:41 <rubasov> and the current tap flow + tap service can refer to neutron ports only (both source and destination)
14:54:51 <lajoskatona> yes that is an important difference, thanks
14:55:36 <mlavalle> that clarification is important because provides the rationale as to how to model this in the API
14:56:15 <mlavalle> now I lean towards "to introduce a new API for ERSPAN to make as simple as possible"
14:56:24 <ralonsoh> ok, I see the difference now but the implementation (including the alternatives proposed), API changes and mech driver prticulars, demand a spec
14:56:38 <lajoskatona> ack
14:57:26 <ralonsoh> in any case, I'm in favor of this improvement (both for OVS and OVN)
14:57:32 <obondarev> +1 for this rfe and a spec
14:57:35 <mlavalle> yeap
14:57:38 <ralonsoh> +1
14:57:42 <mlavalle> good proposal
14:57:44 <mlavalle> +1
14:57:53 <slaweq> +1
14:58:02 <lajoskatona> Thanks for the discussion
14:58:18 <ralonsoh> perfect then, I'll update the launchpad bug
14:58:29 <lajoskatona> thanks ralonsoh
14:58:34 <ralonsoh> there is one more but let's keep it for the next week
14:58:43 <ralonsoh> we had enough for today and this week
14:58:48 <mlavalle> we made good progress this week
14:58:55 <ralonsoh> so let's close for today and have a nice weekend!
14:58:56 <mlavalle> more than I expected
14:59:03 <mlavalle> o/
14:59:05 <rubasov> o/
14:59:07 <ralonsoh> #endmeeting