> -----Original Message-----
> From: Jan Scheurich [mailto:jan.scheur...@ericsson.com]
> Sent: Tuesday, June 21, 2016 10:27 AM
> To: Fischetti, Antonio <antonio.fische...@intel.com>;
> dev@openvswitch.org
> Subject: RE: [RFC Patch] dpif-netdev: Sorted subtable vectors per
> in_port in dpcls
>
> > [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.
[Antonio F] ok, it makes sense.
>
> > >
> > > 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.
[Antonio F] That's interesting, thanks.
>
> > >
> > > - 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.
[Antonio F] Yes, it makes sense.
>
> > Otherwise can we compute port_idx
> > at the beginning or at the port creation so to avoid computing it
> on every
> > batch of keys?
[Antonio F]
Another benefit of computing the port_idx at the port creation
could be that if the new computed value for port_idx is already used by
another port - to avoid collisions - you could change it to the
next unused value or such?
In this case even a simple progressive number
port_idx = last_port_idx + 1
could be used instead of a hashed value.
>
> 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?
[Antonio F] Yes, especially because hash_pointer(subtable,..)
is inside dpcls_lookup(), and also dpcls_try_optimize().
Maybe subtable_idx could stay inside struct dpcls_subtable, to
be set after the subtable is created.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
