Hi Mattias, Have a question on this fix. I understand you wanting a certain number of events before making a decision to migrate (in the above fix). However, suppose there are fewer events over a few flows (even if not many) and yet your core is heavily loaded -- indicating may be they are one or more very CPU intensive flows. Often in DPI situations depending on the complexity of the policy you can get delayed longer. It might still be worthwhile to migrate if the other cores are really lightly loaded. I think that case will be missed out in this approach.
Fundamentally, the number of packets being a proxy-metric for the load of that flow on the cpu is simplistic at times. Very CPU intensive medium/lower bandwidth flows can be picked up in this heuristic. If there is a way that at the time of DSW init we can have a way of tuning it depending on the application scenario it might be more flexible. Thanks -Venky On Thu, Mar 5, 2020 at 2:47 AM Mattias Rönnblom < mattias.ronnb...@ericsson.com> wrote: > Avoid reusing recorded events when performing a migration, since this > may make the migration selection logic pick an already-moved flow. > > Fixes: f6257b22e767 ("event/dsw: add load balancing") > Cc: sta...@dpdk.org > > Reported-by: Venky Venkatesh <vvenkat...@paloaltonetworks.com> > Signed-off-by: Mattias Rönnblom <mattias.ronnb...@ericsson.com> > --- > drivers/event/dsw/dsw_event.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/event/dsw/dsw_event.c b/drivers/event/dsw/dsw_event.c > index d68b71b98..296adea18 100644 > --- a/drivers/event/dsw/dsw_event.c > +++ b/drivers/event/dsw/dsw_event.c > @@ -646,6 +646,9 @@ dsw_port_consider_migration(struct dsw_evdev *dsw, > if (dsw->num_ports == 1) > return; > > + if (seen_events_len < DSW_MAX_EVENTS_RECORDED) > + return; > + > DSW_LOG_DP_PORT(DEBUG, source_port->id, "Considering > migration.\n"); > > /* Randomize interval to avoid having all threads considering > -- > 2.17.1 > >