> This no longer applies cleanly, and I also needed to add this incremental to > make the testsuite pass:
I will rebase and adapt the tests as suggested in the next version. > Did you consider keeping a separate dpcls instance per input port instead? > I.e., have an hmap of dpcls'es using the in_port as the hash key, and creating > and destroying them on demand. This would avoid the fixed size array, > simplify the code and each insert and remove operation would be a bit > cheaper. A miss would typically go though a lower number of subtables, even > though the upcall cost would likely hide this benefit in practice. We are > always exact matching in_port (as well as dl_type and recirc_id (see > xlate_wc_init()), so this would add no overhead in terms of the overall > number of megaflows. > I see your point. I guess this would be a somewhat bigger change, but I can have a look at it. I am a bit worried about the memory footprint and the impact on CPU cache performance because each PMD core would have its own set of dpcls'es even, although with RSS and vhost multi-queue support, each in_port will typically be served by many PMD cores. In theory it should be enough to have a single dpcls instance per in_port shared by all PMDs which contains all the read-only data. Each PMD would cache relevant parts of that in its private L1 cache, so there should not be any performance impact. Volatile data such as flow stats would have to be kept per PMD thread as today. This should also avoid multiple up-calls installing the same megaflow in different PMD dpcls'es. What do you think? > Also, it should be possible to expand the pvector API to allow using the > pvector priorities directly as the counts. I posted a patch for this > (https://patchwork.ozlabs.org/patch/638920/), after which you could apply > the following incremental. I haven't tested how this performs, though. I had a look at your patches. I will give that a try to check the performance gain. One question, though. Wouldn't it be cleaner to create a new pvector data type variant without the multithread safety. I have the impression that the client code in dpif-netdev.c is now more exposed to implementation details of pvector than it should be, or? BR, Jan _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
