As I see, this is exactly the same bug as fixed in
commit e4e74c3a2b ("dpif-netdev: Purge all ukeys when reconfigure pmd.")
but reproduced while only reconfiguring of pmd threads without restarting.
Try this patch as a workaround:
diff --git a/lib/dpif-netdev.c b/lib/dpif-netdev.c
index fe2cd4b..0008d30 100644
--- a/lib/dpif-netdev.c
+++ b/lib/dpif-netdev.c
@@ -1027,11 +1027,9 @@ dp_netdev_reload_pmd__(struct dp_netdev_pmd_thread *pmd)
static void
dp_netdev_reload_pmds(struct dp_netdev *dp)
{
- struct dp_netdev_pmd_thread *pmd;
-
- CMAP_FOR_EACH (pmd, node, &dp->poll_threads) {
- dp_netdev_reload_pmd__(pmd);
- }
+ dp_netdev_destroy_all_pmds(dp);
+ dp_netdev_set_nonpmd(dp);
+ dp_netdev_reset_pmd_threads(dp);
}
static uint32_t
---
I'll try to prepare proper fix later.
Best regards, Ilya Maximets.
On 30.12.2015 17:49, Mauricio Vásquez wrote:
> I have no idea, ovs was running for a long time when I took that data.
> I restarted everything and now the main thread shows:
>
> main thread:
> emc hits:1316
> megaflow hits:0
> miss:681
> lost:1348
> polling cycles:7226622 (19.41%)
> processing cycles:30002635 (80.59%)
> avg cycles per packet: 18642.59 (37229257/1997)
> avg processing cycles per packet: 15023.85 (30002635/1997)
>
> Other threads continue to show a high number of miss packets, throughput is
> still 700 kpps.
>
>
>
>
> On 30 December 2015 at 09:36, Ilya Maximets <[email protected]
> <mailto:[email protected]>> wrote:
>
> On 30.12.2015 17:32, Mauricio Vásquez wrote:
> > I just checked and the traffic is generated after everything is already
> set up, ports and flows.
>
> And what is this 50K packets in that case?
>
> main thread:
> emc hits:20341
> megaflow hits:0
> miss:10193
> lost:20372
>
> >
> > On 30 December 2015 at 08:50, Ilya Maximets <[email protected]
> <mailto:[email protected]> <mailto:[email protected]
> <mailto:[email protected]>>> wrote:
> >
> > The transmission starts before the addition of dpdkr4 to ovs?
> >
> > On 30.12.2015 16:31, Mauricio Vásquez wrote:
> > > Dear Ilya,
> > >
> > > ovs-appctl dpif-netdev/pmd-stats-show ->
> http://pastebin.com/k1nnMfQZ
> > > ovs-appctl coverage/show -> http://pastebin.com/617CYR4n
> > > ovs-appctl dpctl/show -> http://pastebin.com/JFCT8tgS
> > > ovs-log -> http://pastebin.com/sJkaF20M
> > >
> > >
> > > Thank you very much.
> > >
> > > On 30 December 2015 at 08:05, Ilya Maximets
> <[email protected] <mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>
> <mailto:[email protected] <mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>>> wrote:
> > >
> > > On 30.12.2015 15:51, Mauricio Vásquez wrote:
> > > > Hello Ilya,
> > > >
> > > > The dpdkr ports involved have just one TX queue, so it
> should not be the reason in this case.
> > > >
> > >
> > > Please, provide output of:
> > > ovs-appctl dpif-netdev/pmd-stats-show
> > > ovs-appctl coverage/show
> > > ovs-appctl dpctl/show
> > > and log of ovs-vswitchd.
> > >
> > >
> >
> >
>
>
_______________________________________________
dev mailing list
[email protected]
http://openvswitch.org/mailman/listinfo/dev
