> Hi Ian, > > We have gone through both your egress and ingress policing patches. And > observed that both are two different approaches. > Instead why don't we extend ingress policing patch to egress policing, > as the ingress patch is in line with plain OVS kernel policing design. > > i.e, Can we extend below OVS commands to egress policing , > > $ ovs-vsctl set interface dpdk0 egress_policing_rate= 0 > $ ovs-vsctl set interface dpdk0 egress_policing_burst=0 > > Or is there any specific reason behind two different approaches. > > > Thanks & Regards, > Gayathri > Hi Gayathri,
Thanks for taking the time to look these over. So there are a number of reasons why we've taken this approach. Your suggestion above looks to add a new parameter 'egress_policing_rate' for OVS with DPDK. I don’t think this is a good idea. This diverges from the current implementation for policing in the vswitch.xml which is used with Kernel OVS also. My aim was to avoid any divergence to keep the usage as similar as possible between OVS kernel and DPDK implementations. This is key when looking at the usage of OVS in cases such as OpenStack where current support for policing follows what's specified in the vswitch.xml (the existing OVS kernel commands), if OVS DPDK were to change this behavior it would require two different sets of commands regarding how to set policing depending on the OVS type. Ideally the commands should be the same. Also the QoS patch contains the QoS API and the egress policer QoS type. When the QoS API was submitted originally feedback from the mailing list suggested that an example QoS type was needed to show how the API is used and how QoS is configured for DPDK. QoS in OVS with DPDK is executed on egress traffic. As such the egress policer was selected as it was as simple but useful implementation that performs a type of QoS on egress traffic and demonstrates how other QoS types could be implemented in the API. Thanks Ian _______________________________________________ dev mailing list [email protected] http://openvswitch.org/mailman/listinfo/dev
