On 7/17/17, 11:19 PM, "Ilya Maximets" <[email protected]> wrote:
On 18.07.2017 06:48, Darrell Ball wrote:
>
>
> On 7/13/17, 8:07 AM, "[email protected] on behalf of Ilya
Maximets" <[email protected] on behalf of [email protected]>
wrote:
>
> If RSS hash exists in a packet it can be reused instead of
> 5 tuple hash re-calculation in OVS_ACTION_ATTR_HASH. This
> leads to increasing the performance of sending packets to
> the OVS bonding in userspace datapath up to 10-15%.
>
> Additionally fixed unit test 'select group with dp_hash
> selection method' to not depend on dp_hash value.
>
> Signed-off-by: Ilya Maximets <[email protected]>
> ---
>
> Version 2:
> * Removed assumption on hash_basis value.
> * hash_finish replaced with hash_int as more appropriate.
> * Fixed 'select group with dp_hash selection method' UT.
>
> lib/odp-execute.c | 11 +++++++++--
> tests/ofproto-dpif.at | 4 ++--
> 2 files changed, 11 insertions(+), 4 deletions(-)
>
> diff --git a/lib/odp-execute.c b/lib/odp-execute.c
> index d656334..03120bf 100644
> --- a/lib/odp-execute.c
> +++ b/lib/odp-execute.c
> @@ -646,8 +646,15 @@ odp_execute_actions(void *dp, struct
dp_packet_batch *batch, bool steal,
> uint32_t hash;
>
> DP_PACKET_BATCH_FOR_EACH (packet, batch) {
> - flow_extract(packet, &flow);
> - hash = flow_hash_5tuple(&flow,
hash_act->hash_basis);
> + /* RSS hash can be used here instead of 5tuple
for
> + * performance reasons. */
> + if (dp_packet_rss_valid(packet)) {
> + hash = dp_packet_get_rss_hash(packet);
> + hash = hash_int(hash, hash_act->hash_basis);
> + } else {
> + flow_extract(packet, &flow);
> + hash = flow_hash_5tuple(&flow,
hash_act->hash_basis);
> + }
>
> Presently, OVS does not have configurable hashing fields for bonds,
although this seems to be asked for.
> Also, OVS does not have symmetrical hashing for bonding, as exists for
the multipath action.
> If/when these features are added, taking the RSS of various input
interfaces to hash across the outgoing members of
> a given bond would not automatically work since a flexible hash algorithm
would not be easily configured the same
> across different input devices and also enforcing symmetry would be
similarly difficult.
> Potentially, we could also make these features mutually exclusive with
using the RSS hash as is done here.
>
> This patch does offer some performance gain, so we could revisit as
needed in the above cases ?
For configurable hashing fields, I think, there should be different
OVS_HASH_ALG type.
Right now the only algorithm is OVS_HASH_ALG_L4
So, if/when the hash algorithm becomes configurable, then others would come in
or maybe field specifiers.
Symmetric hashing is also not required for bonding to work correctly.
Symmetric hashing is a specific feature that requires the hash used to transmit
the packet to be same on each end.
This would require matching configuration on each end. However, using the RSS
hashes of the input
interfaces going to the bond on each end is going to be hard to get to work
since we don’t control them today in a
manner we would need to for this to work.
We could add code that tries to make them the same, but it will not work in
some cases.
From the other side kernel datapath uses exactly same thing to execute
OVS_ACTION_ATTR_HASH.
skb_get_hash() is used there which is equal to RSS hash if it available.
So, this patch just unifies kernel and userspace ways to execute hash
actions.
We don’t control the associated kernel side configuration through OVS APIs
today and it is not clear to me
that would happen any time soon, so kernel side may be a moot point in near
future.
But being similar now is good.
If some additional characteristics will be required we will modify both
datapaths accordingly.
A feature can exist in one datapath and not the other.
There are lots of such cases and this may be another one.
Best regards, Ilya Maximets.
> packet->md.dp_hash = hash;
> }
> } else {
> diff --git a/tests/ofproto-dpif.at b/tests/ofproto-dpif.at
> index 8373f90..83c72cf 100644
> --- a/tests/ofproto-dpif.at
> +++ b/tests/ofproto-dpif.at
> @@ -491,10 +491,10 @@ for d in 0 1 2 3 4 5 6 7 8 9 a b c d e f; do
> AT_CHECK([ovs-appctl netdev-dummy/receive p1 $pkt])
> done
>
> -AT_CHECK([ovs-appctl dpctl/dump-flows | sed
's/dp_hash(.*\/0x1)/dp_hash(0xXXXX\/0x1)/' | strip_ufid | strip_used | sort],
[0], [dnl
> +AT_CHECK([ovs-appctl dpctl/dump-flows | sed
's/dp_hash(.*\/0x1)/dp_hash(0xXXXX\/0x1)/' | sed 's/\(actions:1\)[[01]]/\1X/' |
strip_ufid | strip_used | sort], [0], [dnl
> flow-dump from non-dpdk interfaces:
>
recirc_id(0),in_port(1),packet_type(ns=0,id=0),eth_type(0x0800),ipv4(src=192.168.0.1,frag=no),
packets:15, bytes:630, used:0.0s, actions:hash(hash_l4(0)),recirc(0x2)
>
-recirc_id(0x2),dp_hash(0xXXXX/0x1),in_port(1),packet_type(ns=0,id=0),eth_type(0x0800),ipv4(frag=no),
packets:15, bytes:630, used:0.0s, actions:11
>
+recirc_id(0x2),dp_hash(0xXXXX/0x1),in_port(1),packet_type(ns=0,id=0),eth_type(0x0800),ipv4(frag=no),
packets:15, bytes:630, used:0.0s, actions:1X
> ])
>
> OVS_VSWITCHD_STOP
> --
> 2.7.4
>
> _______________________________________________
> dev mailing list
> [email protected]
>
https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddev&d=DwICAg&c=uilaK90D4TOVoH58JNXRgQ&r=BVhFA09CGX7JQ5Ih-uZnsw&m=yWYQbl5I3JFWIb4JPXMrvVVnm9euTwjLosajStrcJLk&s=qqJkG2Wj8m7F1VTeYznSaFdi8ju8_aLcznAmZzHGNmA&e=
>
>
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
