> -----Original Message----- > From: Simon Horman <simon.hor...@corigine.com> > Sent: Thursday, April 6, 2023 8:48 PM > To: Ilya Maximets <i.maxim...@ovn.org> > Cc: lin huang <mit...@outlook.com>; d...@openvswitch.org > Subject: Re: [ovs-dev] [PATCH v1 0/2] Add netdev-dpdk support for ingress > and egress pkts policer. > > On Thu, Apr 06, 2023 at 02:13:00PM +0200, Ilya Maximets wrote: > > On 4/6/23 08:38, Simon Horman wrote: > > > On Wed, Apr 05, 2023 at 02:07:42PM +0000, lin huang wrote: > > >> Hi Simon, > > >> > > >> : ) > > >> Thanks for your reply. > > >> > > >> There are some explanations about your comments. > > >> > > >> Best regards, Huang Lin. > > >> > > >>> -----Original Message----- > > >>> From: Simon Horman <simon.hor...@corigine.com> > > >>> Sent: Wednesday, April 5, 2023 8:28 PM > > >>> To: lin huang <mit...@outlook.com> > > >>> Cc: d...@openvswitch.org; i.maxim...@ovn.org > > >>> Subject: Re: [ovs-dev] [PATCH v1 0/2] Add netdev-dpdk support for > ingress and > > >>> egress pkts policer. > > >>> > > >>> On Tue, Apr 04, 2023 at 01:46:05PM +0000, lin huang wrote: > > >>>> Hi Ilya, > > >>>> > > >>>> Pls review my code. > > >>>> > > >>>> I want to add a new policer which is pps-based in netdev-dpdk > module. > > >>>> The policer is divided into ingress and egress part. Both use the ovs > native > > >>> tocken bucket library as the counter. > > >>>> Compared to bandwidth-based policers, the pps-based policer is more > > >>> effective at combating low-and-slow types of DDoS attacks. > > >>>> > > >>>> This new ingress policer is configured using the "policer_kpkts_rate" > and > > >>> "policer_kpkts_burst" configuration statement. Here is the example. > > >>>> ovs-vsctl set interface dpdk0 policer_kpkts_rate=2 > > >>>> ovs-vsctl set interface dpdk0 policer_kpkts_burst=2 > > >>>> > > >>>> This new egress policer is configured using the " egress-pkts-policer " > > >>> configuration statement. Here is the example. > > >>>> ovs-vsctl set port vhost-user0 qos=@newqos -- \ > > >>>> --id=@newqos create qos type=egress-pkts-policer > > >>> other-config:pkts_rate=2048 \ > > >>>> other-config:pkts_burst=2048` > > >>> > > >>> I have some high level questions about this. > > >>> > > >>> 1. For ingress there is, as you mention above, > > >>> already options at the ovs-vsctl for port-based PPS policing. > > >>> > > >>> Did you consider making the egress options you are adding consistent > > >>> with the existing ingress options? > > >>> f.e. egress_policing_kpkts_rate and egress_policing_kpkts_rate. > > >> > > >> Yes we can add new egress options in interface. But this work will > conflict the > > >> userspace datapath egress QoS (egress policing) framework. > > >> The framework needs to set up a QoS instance which is configured by > cir/cbs/pps... to a specific port. > > >> So, I add a new egress policer called pkts-policer. > > > > > > My point was mainly that for ingress we use 'kpkts' > > > But your proposal for egress uses 'pkts'. > > > I think they should be the same. > > > > I had the same thought, so pointed that out in my review for the patch. > > I think, we agreed to change to kilo-. The math will also become less > > confusing. > > Thanks
Thanks for your reply. As Ilya said, we agreed to change egress parameters to kilo. > > > >>> 2. Metering operates on egress, is a policer, and can support PPS. > > >>> Did you consider using this instead of adding a new egress policer? > > >> > > >> In my opinion, meter table is used in flow rate limit not in interface > traffic. > > >> Interface policer is different from meter policer which you can > > >> police a > specific flow. > > >> The new egress policer is just in userspace datapath not in kernel > datapath. > > >> Does the new policer involve the kernel datapath? > > >> > > >>> > > >>> There is an upstreamed implementation of this for upstreamed > > >>> for the kernel datapath with and without TC HW offload. > > > > > > My point is that, in my experience, metering covers your use-case as I > > > understand it. I'd be interested to hear of an example where it does not. > > > > I suppose, it's useful for those who are using OVS as a simple learning > > switch and don't want to mess with OpenFlow rules. I'm guessing that's > > a fair share of DPDK port users. > > Point taken. > > I guess for my use-cases the complexity of meters was managed at a higher > layer, which made it a good choice - partly because it was already > supported by the higher layers. > Thank you for sharing your advice with me. Yes, meters can do kpkts and pps rate limit by openflow rules which can cover my use-cases. But In some specific case, user just want to limit flow by a simple command line configuration not Openflow rules. A lot of OpenFlow rules which added by controller will spend a higher memory and cpu cycles. _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
