[Starlingx-discuss] Questions about StarlingX OVS-DPDK firewall driver enhancement

[Qin, Kailun]

Matt,

Thanks a lot for the information. I’ll keep you updated for the performance testing.

BR,
Kailun

From: Peters, Matt [mailto:Matt.Peters at windriver.com]
Sent: Thursday, October 18, 2018 10:08 PM
To: Qin, Kailun <kailun.qin at intel.com>; starlingx-discuss at lists.starlingx.io
Subject: RE: Questions about StarlingX OVS-DPDK firewall driver enhancement

Hi Kailun,
The code change required to use the ‘openvswitch’ driver would be in stx-config.  Currently the default driver is ‘noop’, so once the performance testing is complete and verified, this can be updated to be the default.

https://git.openstack.org/cgit/openstack/stx-config/tree/puppet-manifests/src/hieradata/compute.yaml#n21

Regards, Matt

From: Qin, Kailun [mailto:kailun.qin at intel.com]
Sent: Thursday, October 18, 2018 5:29 AM
To: Peters, Matt; starlingx-discuss at lists.starlingx.io<mailto:starlingx-discuss at lists.starlingx.io>
Subject: RE: Questions about StarlingX OVS-DPDK firewall driver enhancement

Hi Matt,

To follow up with the performance concern of (kernel-space) conntrack used in option #3. I’ve checked and evaluated the user-space conntrack functionality in OVS and in Neutron native OVS firewall.

Please kindly see the attached report for details. We can have another sync in the stx-networking weekly meeting later.

Thanks!

BR,
Kailun

From: Peters, Matt [mailto:Matt.Peters at windriver.com]
Sent: Monday, September 17, 2018 6:41 PM
To: Qin, Kailun <kailun.qin at intel.com<mailto:kailun.qin at intel.com>>; starlingx-discuss at lists.starlingx.io<mailto:starlingx-discuss at lists.starlingx.io>
Subject: Re: Questions about StarlingX OVS-DPDK firewall driver enhancement

Hello Kailun,
I’m fine with exploring option #3 as an alternative to #2.  I wasn’t aware that the native driver fully supported the netdev datapath, but if it can be supported, then I agree it would be a better choice.

Regards, Matt

From: "Qin, Kailun" <kailun.qin at intel.com<mailto:kailun.qin at intel.com>>
Date: Thursday, September 6, 2018 at 10:09 AM
To: "Peters, Matt" <Matt.Peters at windriver.com<mailto:Matt.Peters at windriver.com>>, "starlingx-discuss at lists.starlingx.io<mailto:starlingx-discuss at lists.starlingx.io>" <starlingx-discuss at lists.starlingx.io<mailto:starlingx-discuss at lists.starlingx.io>>
Subject: Questions about StarlingX OVS-DPDK firewall driver enhancement

Hi Matt,

We are doing some ground work for https://storyboard.openstack.org/#!/story/2002944 regarding the StarlingX OVS-DPDK firewall driver enhancement. To better understand the requirement, we may need your help on the following question.

There are 3 security group implementations in neutron OVS-DPDK agent.

  1.  Iptables based security group
The OVS agent and Compute service use a Linux bridge between each instance (VM) and the OVS integration bridge br-int to implement security groups. This implementation is stateful but
cause scalability and performance problems.
  2.  Openflow based security group
This implementation is stateless and based in OpenFlow 'learn action', which uses a firewall driver in networking-ovs-dpdk project.
https://github.com/openstack/networking-ovs-dpdk/blob/master/networking_ovs_dpdk/agent/ovs_dpdk_firewall.py
  3.  Openflow + conntrack based security group
This implementation is stateful, which uses a native firewall driver.
https://docs.openstack.org/newton/networking-guide/config-ovsfwdriver.html
http://docs.openvswitch.org/en/latest/tutorials/ovs-conntrack/

The requirement from the enhancement description is that we're going to adopt implementation option 2 for StarlingX OVS-DPDK security group.
Compared with option 3 which is stateful and uses a native firewall driver, what is our consideration on taking option 2 as our target?

Please kindly see the attached doc for further details. Just let me know if anything unclear. Thanks a lot!

BR,
Kailun

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.starlingx.io/pipermail/starlingx-discuss/attachments/20181018/a14ddbec/attachment.html>