# Re: [ovs-dev] [PATCH v2] Upcall/Slowpath rate limiter for OVS

Ben,

Could you please let me know your views? Like other meters, OFPM_SLOWPATH is
also local to each bridge and tied to USERSPACE action. So OFPM_SLOWPATH cannot
be used as is for rate-limiting upcalls. We need to have a global/OVS-vswitchd
level meter (either overload OFPM_SLOWPATH semantics or use a new meter) or a
token-bucket, which is programmed/queried by either appctl or vsctl utility
(assuming ofctl cannot be used unless we expose the global-level meter to the
controller).

With this constraint, wouldn’t it be simpler to use the token-bucket based
scheme as in my previous patch?

Thanx
Manu

﻿On 07/03/18, 6:54 PM, "ovs-dev-boun...@openvswitch.org on behalf of Manohar
Krishnappa Chidambaraswamy" <ovs-dev-boun...@openvswitch.org on behalf of
manohar.krishnappa.chidambarasw...@ericsson.com> wrote:

Ben,

While digging further on how OFPM_SLOWPATH can be used for rate-limiting
upcalls. Here is what I found.

1. Support for OFPM13_SLOWPATH meter already exists in OVS today, but it is
tied to USERSPACE action. In netdev-path, handle_packet_upcall() ->
dp_netdev_upcall() -> upcall_cb() -> process_upcall() -> upcall_xlate() ->
xlate_actions(), the slowpath-meter is inserted as an action if the output of
translation is marked as SLOW_XXXX (reasons as in SLOW_PATH_REASONS). This is
done in compose_slow_path() with OVS_ACTION_ATTR_METER and
OVS_ACTION_ATTR_USERSPACE actions. However, in this upcall path,
xlate_actions() is what consumes most cycles and needs to be guarded by a
rate-limiter (which is the main idea behind this patch).

2. "ovs-ofctl add-meter" command is tied to a bridge. When a OFPM_SLOWPATH
meter is set for a bridge, it gets its own instance of the meter in datapath.
So just like other meters, OFPM_SLOWPATH will also have separate instances
per-bridge in datapath.

In order to use OFPM_SLOWPATH meter for rate-limiting upcalls, we need to
run the same (OFPM13_SLOWPATH) meter without an "action", before getting into
dp_netdev_upcall() from handle_packet_upcall(). For this, we need to know which
instance of OFPM13_SLOWPATH to run (as its before translation, bridge details
are not known). One way to do this is to reserve a global datapath-meter, whose
parameters are set either by a modified version of add-meter (like "ofctl
add-global-meter meter="slowpath"...) which is not tied to any bridge or a new
CLI like what was proposed in this patch before.

Thanx
Manu

On 20/02/18, 11:20 AM, "Manohar Krishnappa Chidambaraswamy"
<manohar.krishnappa.chidambarasw...@ericsson.com> wrote:

Thanx Ben. I was also not aware of these virtual meters in Openflow.
However, I think the semantics of these meters are not clearly mentioned in the
OF spec. Perhaps due to the fact that these meters need to be exercised based
on datapath implementation.

OFPM_SLOWPATH meter seems to be at switch level and if we keep this
meter at DP level, all PMDs need to run the same meter. This means they all
would compete for the same meter via a lock. Would this be OK? Or we could keep
a separate meter at PMD level as well. What do you think? The current proposal
was granular to PMD level and hence was lockless.

Also, the ofctl command for setting a meter is at bridge level. For
meter=0xfffffffd,pktps,band=type=drop,rate=1000”. This won’t suit well for
virtual meters. So we need to either support add-meter at switch level or set
it for all bridges. Former seems a better choice. Please let me know your
thoughts.

Thanx
Manu

On 17/02/18, 5:22 AM, "Ben Pfaff" <b...@ovn.org> wrote:

I think it makes sense to allow the rate limit to be set through the
database, no objection there.

On Fri, Feb 16, 2018 at 11:47:41PM +0000, Jan Scheurich wrote:
> Hi Ben,
>
> Thanks, I didn't know about the pseudo OFPM_SLOWPATH meter
defined in OpenFlow. It appears to have been introduced roughly for what we
need here. So it seems like a good idea to be able to support a Meter Mod
message with a drop band for the OFPM_SLOWPATH to configure the upcall rate
limiter parameters.
>
> A remote SDN controller, however,  does not necessarily have any
knowledge and understanding of the internal architecture of the switch and the
resulting need to rate limit slow-path packets. Therefore, the upcall rate
limiter would typically be set up by the cloud operator through local
configuration of the switch.
>
> We could inject the OpenFlow meter configuration into OVS through
an ovs-ofctl command, but the problem is that OpenFlow state does not persist
and would have to be added through scripts after every restart.
>
> I therefore still think it would be a good idea to persistently
configure the default configuration of the upcall rate limiter in the OVSDB
database. It might be overridden at run-time through OpenFlow Meter Mod
messages.
>
> What do you think?
>
> Jan
>
> > -----Original Message-----
> > From: Ben Pfaff [mailto:b...@ovn.org]
> > Sent: Friday, 16 February, 2018 23:54
> > To: Jan Scheurich <jan.scheur...@ericsson.com>
> > Cc: Manohar Krishnappa Chidambaraswamy
<manohar.krishnappa.chidambarasw...@ericsson.com>; d...@openvswitch.org
> > Subject: Re: [ovs-dev] [PATCH v2] Upcall/Slowpath rate limiter
for OVS
> >
> > OK.  We do need some kind of special case here.
> >
> > I think I was I was thinking of something different: metering
for
> > datapath flows that need to go to the slowpath.  For those, we
have a
> > set of datapath actions and those datapath actions can include
a meter
> > action, and that's what we're planning to do for all dpif-based
> > datapaths.
> >
> > I guess that for miss upcalls we don't have a set of datapath
actions,
> > only a list of Netlink upcall pids.  That's a shame, it would
be easy to
> > use meters here too otherwise.
> >
> > At any rate, we should make the slowpath ratelimiting
configurable via
> > the standard OFPM_SLOWPATH meter available in OpenFlow.
> >
> > Thanks,
> >
> > ben.
> >
> > On Thu, Feb 15, 2018 at 10:42:02PM +0000, Jan Scheurich wrote:
> > > Hi Ben,
> > >
> > > This patch is about rate-limiting miss upcalls. Could you
elaborate how you suggest to use the metering datapath action to realize that?
> > >
> > > I also think this is a specific issue for the DPDK datapath
as only the miss upcalls are executed in-line in the PMD thread so that mass
> > upcalls directly impact the datapath performance. The kernel
datapath (not sure about Windows) doesn't have the same issue as upcalls
> > are transferred to the user-space through netlink.
> > >
> > > Thanks, Jan
> > >
> > > > -----Original Message-----
> > > > From: ovs-dev-boun...@openvswitch.org
[mailto:ovs-dev-boun...@openvswitch.org] On Behalf Of Ben Pfaff
> > > > Sent: Thursday, 15 February, 2018 19:13
> > > > To: Manohar Krishnappa Chidambaraswamy
<manohar.krishnappa.chidambarasw...@ericsson.com>
> > > > Cc: d...@openvswitch.org
> > > > Subject: Re: [ovs-dev] [PATCH v2] Upcall/Slowpath rate
limiter for OVS
> > > >
> > > > Metering is implemented as a datapath action so I think you
can share
> > > > the mechanism instead of inventing a new one.
> > > >
> > > > On Thu, Feb 15, 2018 at 05:57:58PM +0000, Manohar
Krishnappa Chidambaraswamy wrote:
> > > > >
> > > > > Ben,
> > > > >
> > > > > “[manu] Do you mean using meters in dp-netdev instead of
token-bucket. I don’t know much about meters. Will check.”
> > > > >
> > > > > I checked about meters. For limiting flows hitting
slowpath, meters can’t be used. Since meter is an action, new flows would still
hit
> > the
> > > > slow-path before meter-action can be executed.
> > > > >
> > > > > Thanx
> > > > > Manu
> > > > >
> > > > > On 25/01/18, 11:52 AM, "ovs-dev-boun...@openvswitch.org
on behalf of Manohar Krishnappa Chidambaraswamy" <ovs-dev-
> > > > boun...@openvswitch.org on behalf of
manohar.krishnappa.chidambarasw...@ericsson.com> wrote:
> > > > >
> > > > >     Ben,
> > > > >
> > > > >     On 23/01/18, 2:01 AM, "Ben Pfaff" <b...@ovn.org>
wrote:
> > > > >
> > > > >         I guess I'm probably the wrong one to ultimately
review this patch,
> > > > >         since it's really a DPDK patch.
> > > > >
> > > > >         It's difficult to say for sure that this is
really an improvement, since
> > > > >         it also causes traffic to be dropped (that is,
the traffic that needs to
> > > > >         be slow-pathed).
> > > > >
> > > > >     [manu] Thanx for your response. Its true that this
also results in
> > > > >     packet-drops, but these packets belong to new flows
that can potentially
> > > > >     take lot more cycles of PMD. Already established
flows will *not* see any drops
> > > > >     due to this rate-limiting. If implemented in DPDK, we
can’t differentiate packets
> > > > >     belonging to already established vs new flows. To do
this, we would need something
> > > > >     in OVS only.
> > > > >
> > > > >     Sorry I didn’t include the description in my v2
patch. Here is the main intent
> > > > >     behind this patch (from v1). Do you think this is
reasonable?
> > > > >
> > > > >     “In OVS-DPDK, both fast-path and slow-path execute in
the context of a common
> > > > >     thread (i.e, PMD thread), without any partitioning of
CPU cycles between the
> > > > >     two. When there is a burst of new flows coming into
the data-path, packets
> > > > >     are punted to slow-path in the order they are
received and the PMD is busy
> > > > >     for the duration of the upcall. Slow-path processing
of a packet consumes
> > > > >     100-200 times the cycles of fast-path handling. As a
result, the forwarding
> > > > >     performance of a PMD degrades significantly during an
upcall burst. If the
> > > > >     PMD was highly loaded already, it becomes temporarily
> > > > >     queues start filling up. If the upcall burst is long
enough, packets will be
> > > > >     dropped when rx queues are full. This happens even if
the new flows are
> > > > >     unexpected and the slow-path decides to drop the
packets.
> > > > >
> > > > >     It is likely that most of the packets dropped due to
rx queue overflow belong
> > > > >     to established flows that should have been processed
by the fast-path. Hence,
> > > > >     the current OVS-DPDK architecture favors the handling
of new flows over the
> > > > >     forwarding of established flows. This is generally a
sub-optimal approach.
> > > > >
> > > > >     Without a limit to the rate of upcalls, OVS-DPDK is
vulnerable for DoS attacks.
> > > > >     But even sporadic bursts of e.g. unexpected multicast
packets have shown to
> > > > >     cause such packet drops.”
> > > > >
> > > > >         I think that this could be handled in a datapath
independent way using
> > > > >         meters.
> > > > >
> > > > >     [manu] Do you mean using meters in dp-netdev instead
of token-bucket. I don’t
> > > > >     know much about meters. Will check.
> > > > >
> > > > >     Thanx
> > > > >     Manu
> > > > >
> > > > >         On Mon, Jan 15, 2018 at 08:33:31AM +0000, Manohar
Krishnappa Chidambaraswamy wrote:
> > > > >         > Rebased to master.
> > > > >         >
> > > > >         > Could you please review this patch?
> > > > >         >
> > > > >         > v1 of this patch has been sitting idle for
quite sometime. I believe this
> > > > >         > feature is important. Without this feature, an
attacker sending packets
> > > > >         > belonging to different (unestablished) flows
can result in PMDs running only
> > > > >         > upcalls, reducing the throughput drastically.
Huge traffic loss due to this
> > > > >         > is more like a DOS attack.
> > > > >         >
is my first patch series in
> > > > >         > OVS. Sorry if naming of this patch as v2 is not
appropriate.
> > > > >         >
> > > > >         > Thanx
> > > > >         > Manu
> > > > >         >
> > > > >         > v1 of this patch:
https://patchwork.ozlabs.org/patch/836737/
> > > > >         >
> > > > >         > Signed-off-by: Manohar K C
<manohar.krishnappa.chidambarasw...@ericsson.com>
> > > > >         > cc: Jan Scheurich <jan.scheur...@ericsson.com>
> > > > >         > cc: Ben Pfaff <b...@ovn.org>
> > > > >         >
> > > > >         > ---
> > > > >         >  Documentation/howto/dpdk.rst      | 21
++++++++++
> > > > >         >  debian/libopenvswitch-dev.install |  1 -
> > > > >         >  debian/libopenvswitch.install     |  1 -
> > > > >         >  debian/rules                      |  4 +-
> > > > >         >  lib/dpif-netdev.c                 | 81
+++++++++++++++++++++++++++++++++++++--
> > > > >         >  vswitchd/vswitch.xml              | 47
+++++++++++++++++++++++
> > > > >         >  6 files changed, 148 insertions(+), 7
deletions(-)
> > > > >         >
> > > > >         > diff --git a/Documentation/howto/dpdk.rst
b/Documentation/howto/dpdk.rst
> > > > >         > index 587aaed..1db1562 100644
> > > > >         > --- a/Documentation/howto/dpdk.rst
> > > > >         > +++ b/Documentation/howto/dpdk.rst
> > > > >         > @@ -716,3 +716,24 @@ devices to bridge ``br0``.
Once complete, follow the below steps:
> > > > >         >     Check traffic on multiple queues::
> > > > >         >
> > > > >         >         \$ cat /proc/interrupts | grep virtio
> > > > >         > +
> > > > >         > +Upcall rate limiting
> > > > >         > +--------------------
> > > > >         > +ovs-vsctl can be used to enable and configure
upcall rate limit parameters.
> > > > >         > +There are 2 configurable values
``upcall-rate`` and ``upcall-burst`` which
> > > > >         > +take effect when global enable knob
``upcall-rl`` is set to true.
> > > > >         > +
> > > > >         > +Upcall rate should be set using
``upcall-rate`` in packets-per-sec. For
> > > > >         > +example::
> > > > >         > +
> > > > >         > +    \$ ovs-vsctl set Open_vSwitch .
other_config:upcall-rate=2000
> > > > >         > +
> > > > >         > +Upcall burst should be set using
``upcall-burst`` in packets-per-sec. For
> > > > >         > +example::
> > > > >         > +
> > > > >         > +    \$ ovs-vsctl set Open_vSwitch .
other_config:upcall-burst=2000
> > > > >         > +
> > > > >         > +Upcall ratelimit feature should be globally
enabled using ``upcall-rl``. For
> > > > >         > +example::
> > > > >         > +
> > > > >         > +    \$ ovs-vsctl set Open_vSwitch .
other_config:upcall-rl=true
> > > > >         > diff --git a/lib/dpif-netdev.c
b/lib/dpif-netdev.c
> > > > >         > index c7d157a..e2fd92c 100644
> > > > >         > --- a/lib/dpif-netdev.c
> > > > >         > +++ b/lib/dpif-netdev.c
> > > > >         > @@ -101,6 +101,16 @@ static struct shash
dp_netdevs OVS_GUARDED_BY(dp_netdev_mutex)
> > > > >         >
> > > > >         >  static struct vlog_rate_limit upcall_rl =
VLOG_RATE_LIMIT_INIT(600, 600);
> > > > >         >
> > > > >         > +/* Upcall rate-limit parameters */
> > > > >         > +static bool upcall_ratelimit;
> > > > >         > +static unsigned int upcall_rate;
> > > > >         > +static unsigned int upcall_burst;
> > > > >         > +
> > > > >         > +/* TODO: Tune these default values based on
upcall perf test */
> > > > >         > +#define UPCALL_RATELIMIT_DEFAULT false /*
Disabled by default */
> > > > >         > +#define UPCALL_RATE_DEFAULT      1000  /* pps
*/
> > > > >         > +#define UPCALL_BURST_DEFAULT     1000  /* pps
*/
> > > > >         > +
> > > > >         >  #define DP_NETDEV_CS_SUPPORTED_MASK (CS_NEW |
CS_ESTABLISHED | CS_RELATED \
> > > > >         >                                       |
CS_INVALID | CS_REPLY_DIR | CS_TRACKED \
> > > > >         >                                       |
CS_SRC_NAT | CS_DST_NAT)
> > > > >         > @@ -340,6 +350,7 @@ enum dp_stat_type {
> > > > >         >                                     hits */
> > > > >         >      DP_STAT_SENT_PKTS,          /* Packets
that has been sent. */
> > > > >         >      DP_STAT_SENT_BATCHES,       /* Number of
batches sent. */
> > > > >         > +    DP_STAT_RATELIMIT_DROP,     /* Packets
dropped due to upcall policer */
> > > > >         >      DP_N_STATS
> > > > >         >  };
> > > > >         >
> > > > >         > @@ -645,6 +656,9 @@ struct dp_netdev_pmd_thread
{
> > > > >         >      unsigned long long stats_zero[DP_N_STATS];
> > > > >         >      uint64_t cycles_zero[PMD_N_CYCLES];
> > > > >         >
> > > > >         > +    /* Policer to rate limit slow-path */
> > > > >         > +    struct token_bucket upcall_tb;
> > > > >         > +
> > > > >         >      /* Set to true if the pmd thread needs to
> > > > >         >      bool need_reload;
> > > > >         >  };
> > > > >         > @@ -894,10 +908,11 @@
> > > > >         >      ds_put_format(reply,
> > > > >         >                    "\temc hits:%llu\n\tmegaflow
hits:%llu\n"
> > > > >         >                    "\tavg. subtable lookups per
hit:%.2f\n"
> > > > >         > -                  "\tmiss:%llu\n\tlost:%llu\n"
> > > > >         > +
"\tmiss:%llu\n\tlost:%llu\n\tratelimit drops:%llu\n"
> > > > >         >                    "\tavg. packets per output
batch: %.2f\n",
> > > > >         >                    stats[DP_STAT_EXACT_HIT],
> > > > >         >                    lookups_per_hit,
stats[DP_STAT_MISS], stats[DP_STAT_LOST],
> > > > >         > +
stats[DP_STAT_RATELIMIT_DROP],
> > > > >         >                    packets_per_batch);
> > > > >         >
> > > > >         >      if (total_cycles == 0) {
> > > > >         > @@ -3031,6 +3046,8 @@
dpif_netdev_set_config(struct dpif *dpif, const struct smap *other_config)
> > > > >         >          smap_get_ullong(other_config,
"emc-insert-inv-prob",
> > > > >         >
DEFAULT_EM_FLOW_INSERT_INV_PROB);
> > > > >         >      uint32_t insert_min, cur_min;
> > > > >         > +    unsigned int rate, burst;
> > > > >         > +    bool ratelimit;
> > > > >         >
> > > > >         >      if
> > > > >         >          free(dp->pmd_cmask);
> > > > >         > @@ -3056,6 +3073,36 @@
dpif_netdev_set_config(struct dpif *dpif, const struct smap *other_config)
> > > > >         >          }
> > > > >         >      }
> > > > >         >
> > > > >         > +    /* Handle upcall policer params */
> > > > >         > +    ratelimit = smap_get_bool(other_config,
"upcall-rl",
> > > > >         > +
UPCALL_RATELIMIT_DEFAULT);
> > > > >         > +    rate = smap_get_int(other_config,
"upcall-rate",
> > > > >         > +                        UPCALL_RATE_DEFAULT);
> > > > >         > +    burst = smap_get_int(other_config,
"upcall-burst",
> > > > >         > +                         UPCALL_BURST_DEFAULT);
> > > > >         > +
> > > > >         > +    if ((rate != upcall_rate) || (burst !=
upcall_burst)) {
> > > > >         > +        VLOG_INFO("Upcall ratelimit params
changed : Old - rate=%d burst=%d "
> > > > >         > +                  ": New - rate=%d
burst=%d\n", upcall_rate, upcall_burst,
> > > > >         > +                  rate, burst);
> > > > >         > +
> > > > >         > +        upcall_rate = rate;
> > > > >         > +        upcall_burst = burst;
> > > > >         > +
> > > > >         > +        /*
> > > > >         > +         * TODO: See if there is a way to
reconfig only the policer
> > > > >         > +         * in each PMD.
> > > > >         > +         */
> > > > >         > +        dp_netdev_request_reconfigure(dp);
> > > > >         > +    }
> > > > >         > +
> > > > >         > +    if (ratelimit != upcall_ratelimit) {
> > > > >         > +        upcall_ratelimit = ratelimit;
> > > > >         > +
> > > > >         > +        VLOG_INFO("Upcall ratelimit changed to
%s\n",
> > > > >         > +                  (upcall_ratelimit ?
"Enabled" : "Disabled"));
> > > > >         > +    }
> > > > >         > +
> > > > >         >      return 0;
> > > > >         >  }
> > > > >         >
> > > > >         > @@ -3958,6 +4005,12 @@ dpif_netdev_run(struct
dpif *dpif)
> > > > >         >      ovs_mutex_lock(&dp->port_mutex);
> > > > >         >      non_pmd = dp_netdev_get_pmd(dp,
NON_PMD_CORE_ID);
> > > > >         >      if (non_pmd) {
> > > > >         > +        /* Reconfig the upcall policer if
params have changed */
> > > > >         > +        if ((upcall_rate !=
non_pmd->upcall_tb.rate) ||
> > > > >         > +            (upcall_burst !=
non_pmd->upcall_tb.burst)) {
> > > > >         > +
token_bucket_init(&non_pmd->upcall_tb, upcall_rate, upcall_burst);
> > > > >         > +        }
> > > > >         > +
> > > > >         >          ovs_mutex_lock(&dp->non_pmd_mutex);
> > > > >         >          cycles_count_start(non_pmd);
> > > > >         >          HMAP_FOR_EACH (port, node, &dp->ports)
{
> > > > >         > @@ -4154,6 +4207,9 @@ reload:
> > > > >         >          lc = UINT_MAX;
> > > > >         >      }
> > > > >         >
> > > > >         > +    /* Initialize upcall policer token bucket
with configured params */
> > > > >         > +    token_bucket_init(&pmd->upcall_tb,
upcall_rate, upcall_burst);
> > > > >         > +
> > > > >         >      cycles_count_start(pmd);
> > > > >         >      for (;;) {
> > > > >         >          for (i = 0; i < poll_cnt; i++) {
> > > > >         > @@ -4638,6 +4694,10 @@
dp_netdev_configure_pmd(struct dp_netdev_pmd_thread *pmd, struct dp_netdev *dp,
> > > > >         >          emc_cache_init(&pmd->flow_cache);
> > > > >         >          pmd_alloc_static_tx_qid(pmd);
> > > > >         >      }
> > > > >         > +
> > > > >         > +    /* Initialize upcall policer token bucket
with configured params */
> > > > >         > +    token_bucket_init(&pmd->upcall_tb,
upcall_rate, upcall_burst);
> > > > >         > +
> > > > >         >      cmap_insert(&dp->poll_threads,
CONST_CAST(struct cmap_node *, &pmd->node),
> > > > >         >                  hash_int(core_id, 0));
> > > > >         >  }
> > > > >         > @@ -5076,7 +5136,7 @@
> > > > >         >                       struct dp_packet *packet,
> > > > >         >                       const struct
netdev_flow_key *key,
> > > > >         >                       struct ofpbuf *actions,
struct ofpbuf *put_actions,
> > > > >         > -                     int *lost_cnt)
> > > > >         > +                     int *lost_cnt, int
*rl_drop_cnt)
> > > > >         >  {
> > > > >         >      struct ofpbuf *add_actions;
> > > > >         >      struct dp_packet_batch b;
> > > > >         > @@ -5084,6 +5144,18 @@
> > > > >         >      ovs_u128 ufid;
> > > > >         >      int error;
> > > > >         >
> > > > >         > +    /*
> > > > >         > +     * Grab a token from the upcall policer to
enter slowpath. If token
> > > > >         > +     * is not available, drop and account the
packet. This is to
> > > > >         > +     * rate-limit packets getting into
slowpath.
> > > > >         > +     */
> > > > >         > +    if (upcall_ratelimit &&
!token_bucket_withdraw(&pmd->upcall_tb, 1)) {
> > > > >         > +        dp_packet_delete(packet);
> > > > >         > +        (*rl_drop_cnt)++;
> > > > >         > +
> > > > >         > +        return;
> > > > >         > +    }
> > > > >         > +
> > > > >         >      match.tun_md.valid = false;
> > > > >         >      miniflow_expand(&key->mf, &match.flow);
> > > > >         >
> > > > >         > @@ -5158,7 +5230,7 @@
> > > > >         >      struct dpcls *cls;
> > > > >         >      struct dpcls_rule *rules[PKT_ARRAY_SIZE];
> > > > >         >      struct dp_netdev *dp = pmd->dp;
> > > > >         > -    int miss_cnt = 0, lost_cnt = 0;
> > > > >         > +    int miss_cnt = 0, lost_cnt = 0,
rl_drop_cnt = 0;
> > > > >         >      int lookup_cnt = 0, add_lookup_cnt;
> > > > >         >      bool any_miss;
> > > > >         >      size_t i;
> > > > >         > @@ -5202,7 +5274,7 @@
> > > > >         >
> > > > >         >              miss_cnt++;
> > > > >         >              handle_packet_upcall(pmd, packet,
&keys[i], &actions,
> > > > >         > -                                 &put_actions,
&lost_cnt);
> > > > >         > +                                 &put_actions,
&lost_cnt, &rl_drop_cnt);
> > > > >         >          }
> > > > >         >
> > > > >         >          ofpbuf_uninit(&actions);
> > > > >         > @@ -5235,6 +5307,7 @@
> > > > >         >      dp_netdev_count_packet(pmd,
DP_STAT_LOOKUP_HIT, lookup_cnt);
> > > > >         >      dp_netdev_count_packet(pmd, DP_STAT_MISS,
miss_cnt);
> > > > >         >      dp_netdev_count_packet(pmd, DP_STAT_LOST,
lost_cnt);
> > > > >         > +    dp_netdev_count_packet(pmd,
DP_STAT_RATELIMIT_DROP, rl_drop_cnt);
> > > > >         >  }
> > > > >         >
> > > > >         >  /* Packets enter the datapath from a port (or
from recirculation) here.
> > > > >         > diff --git a/vswitchd/vswitch.xml
b/vswitchd/vswitch.xml
> > > > >         > index 58c0ebd..bc77c35 100644
> > > > >         > --- a/vswitchd/vswitch.xml
> > > > >         > +++ b/vswitchd/vswitch.xml
> > > > >         > @@ -412,6 +412,53 @@
> > > > >         >          </p>
> > > > >         >        </column>
> > > > >         >
> > > > >         > +      <column name="other_config"
key="upcall-rl"
> > > > >         > +              type='{"type": "boolean"}'>
> > > > >         > +        <p>
> > > > >         > +          Set this value to <code>true</code>
to enable upcall rate-limiting.
> > > > >         > +          The upcall parameters like rate and
burst will be ignored, if this is
> > > > >         > +          not set.
> > > > >         > +        </p>
> > > > >         > +        <p>
> > > > >         > +          The default value is
<code>false</code> and upcall rate-limiting will
> > > > >         > +          be disabled.
> > > > >         > +        </p>
> > > > >         > +      </column>
> > > > >         > +
> > > > >         > +      <column name="other_config"
key="upcall-rate"
> > > > >         > +        type='{"type": "integer",
"minInteger": 0, "maxInteger": 4294967295}'>
> > > > >         > +        <p>
> > > > >         > +          Specifies the rate of upcalls in
packets-per-second that is to be
> > > > >         > +          allowed. For example, if the value
is 10000, then those many upcalls
> > > > >         > +          (for packets) are allowed per second
in each of the packet polling
> > > > >         > +          thread (PMD or non-PMD).
> > > > >         > +        </p>
> > > > >         > +        <p>
> > > > >         > +          A value of <code>0</code> means, no
upcalls would be allowed i.e,
> > > > >         > +          upcall will be disabled. This is
mainly for debugging.
> > > > >         > +        </p>
> > > > >         > +        <p>
> > > > >         > +          The default value is 1000.
> > > > >         > +        </p>
> > > > >         > +      </column>
> > > > >         > +
> > > > >         > +      <column name="other_config"
key="upcall-burst"
> > > > >         > +        type='{"type": "integer",
"minInteger": 0, "maxInteger": 4294967295}'>
> > > > >         > +        <p>
> > > > >         > +          Specifies the maximum burst of
upcalls in packets-per-second that is
> > > > >         > +          to be allowed. For example, if the
value is 15000, then a maximum
> > > > >         > +          burst of 15000 upcalls (for packets)
are allowed per second in each
> > > > >         > +          of the packet polling thread (PMD or
non-PMD).
> > > > >         > +        </p>
> > > > >         > +        <p>
> > > > >         > +          A value of <code>0</code> means, no
upcalls would be allowed i.e,
> > > > >         > +          upcall will be disabled. This is
mainly for debugging.
> > > > >         > +        </p>
> > > > >         > +        <p>
> > > > >         > +          The default value is 1000.
> > > > >         > +        </p>
> > > > >         > +      </column>
> > > > >         > +
> > > > >         >        <column name="other_config"
key="vlan-limit"
> > > > >         >                type='{"type": "integer",
"minInteger": 0}'>
> > > > >         >          <p>
> > > > >         > --
> > > > >         > 1.9.1
> > > > >         >
> > > > >         >
> > > > >         >
> > > > >
> > > > >
> > > > >     _______________________________________________
> > > > >     dev mailing list
> > > > >     d...@openvswitch.org
> > > > >     https://mail.openvswitch.org/mailman/listinfo/ovs-dev
> > > > >
> > > > >
> > > > _______________________________________________
> > > > dev mailing list
> > > > d...@openvswitch.org
> > > > https://mail.openvswitch.org/mailman/listinfo/ovs-dev

_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev