> [Antonio F]
> What if the range of the hash values is partitioned per port type?
> I mean if the 1st range - say the first 10 values - are reserved for dpdk
> ports
>
> if <is a dpdk port> // range is [0..9]
> uint32_t port_idx = 0 + hash_port_no(port_no) % 10;
> else // range is [10..NUM_SUBTABLE_VECTORS]
> uint32_t port_idx = 10 + hash_port_no(port_no) %
> (NUM_SUBTABLE_VECTORS - 10);
>
> Could this help to avoid collisions between ports of different types, eg a
> dpdk
> with a vhostuser port?
You are probably right that ports of the different type (dpdk, vhostuser,
tunnel, internal, tunnel, patch, etc) are likely to have hits in different
subsets of subtables. Whether or not static partitioning of the subtable vector
space per in_port type gives better results than hashing over a larger set of
subtable vectors would have to be tested.
> >
> > As the number of subtables will often be higher in reality, we can
>
> [Antonio F] Do you know how many subtables can be used in a real scenario?
That very much depends on the OVS bridge setup, the OpenFlow pipeline and the
traffic patterns. Any overlay networking solution will have at least two
subtables for the tunnel handling plus any number of subtables needed for
processing the inner packets. If you have different virtualized networking
services present (e.g. ACL, L2, L3, Service Chaining, ...) packets will take
different parts through the pipeline, resulting in different megaflow wild-card
masks.
Furthermore, also (periodic) maintenance packets (e.g. LACP, ARP, PING, BFD)
will typically lead to creation of dedicated subtables, that can degrade the
dpcls performance today.
My guess would be that in a realistic OVS deployment in an OpenStack cloud with
SDN controller (e.g. ODL) running ACL/L2/L3/NAT services and link bonding,
there will be in the order of 10-15 subtables. But I don't have access to such
a system to provide empiric data.
> >
> > - PVECTOR_FOR_EACH (subtable, &cls->subtables) {
> > + /* Select the subtable vector for the in_port */
> > + uint32_t port_idx = hash_port_no(port_no) %
> > NUM_SUBTABLE_VECTORS;
>
> [Antonio F] May we simply use the port_no instead of its hashed value?
I considered using the odp port number directly but didn't dare to do so
because of the potentially large number of ports in a switch and the memory
impact.
> Otherwise can we compute port_idx
> at the beginning or at the port creation so to avoid computing it on every
> batch of keys?
I can prototype if computing the index at creation and storing it as port data
gives any benefit. I guess the same could be done for the subtable index, right?
_______________________________________________
dev mailing list
[email protected]
http://openvswitch.org/mailman/listinfo/dev
