From: Shahaf Shuler <shahafs@mellanox.com>
To: Tom Barbette <barbette@kth.se>, "dev@dpdk.org" <dev@dpdk.org>
Cc: Adrien Mazarguil <adrien.mazarguil@6wind.com>,
Olga Shern <olgas@mellanox.com>
Subject: Re: [dpdk-dev] rte_flow update support?
Date: Thu, 14 Feb 2019 13:15:35 +0000 [thread overview]
Message-ID: <AM6PR0502MB37979EF7FD39C87F1520AD21C3670@AM6PR0502MB3797.eurprd05.prod.outlook.com> (raw)
In-Reply-To: <1d2b91ac-8f43-f851-8250-301d2ce41dd0@kth.se>
Hi Tom,
Thursday, February 14, 2019 1:31 PM, Tom Barbette:
> Subject: rte_flow update support?
>
> Hi all,
>
> Are there plans to add support for modifying rules using the rte_flow API ?
>
> The first problem with destroy+create is atomicity. During the process some
> packets will get lost.
>
> Then the second problem is performance. We measured Mellanox CX5 (mlx5
> driver) to be able to "update" at best 2K rules/sec, but that drops to
> 200 rules/sec when updating TC rules ("transfer" rules, to switch packets
> between VFs). Real support for update should boost those numbers.
Yes you are right, the current update rate of verbs and TC is not so good.
>
> I saw the ibverbs API backing the mlx5 supports updating the action of a rule.
> This would already solve a lot of use cases. Eg, changing destination queue(s)
> of some rules. Given that mlx5 does not support changing global RSS queues
> without restarting the device, this would also solve re-balancing issue by
> using rte_flow.
Updating the action list will solve only part of issue, what you really want (for OVS case) is to update the flow pattern as well (since TCP connection got terminated and new one was created).
>
> Then, beyond updating only the action of a rule, some researchers have
> shown[1] that updating rules patterns data instead of creating and deleting
> rules with similar patterns improve drastically the performance. Eg that could
> be very interesting to accelerate the offloading of OVS's flow cache (5-
> tuples), or similar setups.
Stay tuned, we are working on it.
There is a new engine for flow rules which will be very fast. Expected performance will be ~300K updates per second and will include both transfer and regular flow rules.
It is in plans for 19.XX releases.
Would recommend you to have a try on it once ready.
>
> Thanks,
> Tom
>
>
> [1] Turboflow: information rich flow record generation on commodity
> switches, J Sonchack et al.
next prev parent reply other threads:[~2019-02-14 13:15 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-14 11:31 Tom Barbette
2019-02-14 13:15 ` Shahaf Shuler [this message]
2019-02-15 10:45 ` Tom Barbette
2019-02-17 5:53 ` Shahaf Shuler
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=AM6PR0502MB37979EF7FD39C87F1520AD21C3670@AM6PR0502MB3797.eurprd05.prod.outlook.com \
--to=shahafs@mellanox.com \
--cc=adrien.mazarguil@6wind.com \
--cc=barbette@kth.se \
--cc=dev@dpdk.org \
--cc=olgas@mellanox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).