From: Yongseok Koh <yskoh@mellanox.com>
To: Slava Ovsiienko <viacheslavo@mellanox.com>
Cc: Shahaf Shuler <shahafs@mellanox.com>, "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH 3/3] net/mlx5: fix rule cleanup Netlink command sending
Date: Sun, 11 Nov 2018 11:41:33 +0000 [thread overview]
Message-ID: <9DE1F3C9-D4C0-45B7-9B8C-DA9D80C53FC2@mellanox.com> (raw)
In-Reply-To: <1541843951-31708-4-git-send-email-viacheslavo@mellanox.com>
> On Nov 10, 2018, at 1:59 AM, Slava Ovsiienko <viacheslavo@mellanox.com> wrote:
>
> The VXLAN related rule cleanup routine queries and gathers all
> existing local IP and neigh rules into buffer list. One buffer
> may contain multiple rule deletetion commands and is prepared
> to send into Netlink as single message. But, if error occurs
> for some deletion commands in the buffer, the multiple ACK
> message with errors can be send back by the kernel. It breaks
> the Netlink communication sequence numbers, because we expect
> only one ACK message and it smashes out futher Netlik
> communication.
Just curious.
Is parsing the multiple ack msgs more complex than sending commands
one by one?
> The workaround of this problem is to send rule deletion commands
> from buffer in one-by-one fashion and get ACK message for every
> command sent. We do not expect too may rules preexist, so there
> should not be critical performance degradation at VXLAN outer
> interface initialization.
>
> Fixes: f420f03d6772 ("net/mlx5: add E-switch VXLAN rule cleanup routines")
>
> Signed-off-by: Viacheslav Ovsiienko <viacheslavo@mellanox.com>
> ---
Acked-by: Yongseok Koh <yskoh@mellanox.com>
Thanks
> drivers/net/mlx5/mlx5_flow_tcf.c | 58 +++++++++++++++++-----------------------
> 1 file changed, 24 insertions(+), 34 deletions(-)
>
> diff --git a/drivers/net/mlx5/mlx5_flow_tcf.c b/drivers/net/mlx5/mlx5_flow_tcf.c
> index bba8aed..21eb99e 100644
> --- a/drivers/net/mlx5/mlx5_flow_tcf.c
> +++ b/drivers/net/mlx5/mlx5_flow_tcf.c
> @@ -3847,30 +3847,6 @@ struct tcf_nlcb_context {
> }
>
> /**
> - * Set NLM_F_ACK flags in the last netlink command in buffer.
> - * Only last command in the buffer will be acked by system.
> - *
> - * @param[in, out] buf
> - * Pointer to buffer with netlink commands.
> - */
> -static void
> -flow_tcf_setack_nlcmd(struct tcf_nlcb_buf *buf)
> -{
> - struct nlmsghdr *nlh;
> - uint32_t size = 0;
> -
> - assert(buf->size);
> - do {
> - nlh = (struct nlmsghdr *)&buf->msg[size];
> - size += NLMSG_ALIGN(nlh->nlmsg_len);
> - if (size >= buf->size) {
> - nlh->nlmsg_flags |= NLM_F_ACK;
> - break;
> - }
> - } while (true);
> -}
> -
> -/**
> * Send the buffers with prepared netlink commands. Scans the list and
> * sends all found buffers. Buffers are sent and freed anyway in order
> * to prevent memory leakage if some every message in received packet.
> @@ -3888,21 +3864,35 @@ struct tcf_nlcb_context {
> flow_tcf_send_nlcmd(struct mlx5_flow_tcf_context *tcf,
> struct tcf_nlcb_context *ctx)
> {
> - struct tcf_nlcb_buf *bc, *bn;
> - struct nlmsghdr *nlh;
> + struct tcf_nlcb_buf *bc = LIST_FIRST(&ctx->nlbuf);
> int ret = 0;
>
> - bc = LIST_FIRST(&ctx->nlbuf);
> while (bc) {
> + struct tcf_nlcb_buf *bn = LIST_NEXT(bc, next);
> + struct nlmsghdr *nlh;
> + uint32_t msg = 0;
> int rc;
>
> - bn = LIST_NEXT(bc, next);
> - if (bc->size) {
> - flow_tcf_setack_nlcmd(bc);
> - nlh = (struct nlmsghdr *)&bc->msg;
> - rc = flow_tcf_nl_ack(tcf, nlh, bc->size, NULL, NULL);
> - if (rc && !ret)
> - ret = rc;
> + while (msg < bc->size) {
> + /*
> + * Send Netlink commands from buffer in one by one
> + * fashion. If we send multiple rule deletion commands
> + * in one Netlink message and some error occurs it may
> + * cause multiple ACK error messages and break sequence
> + * numbers of Netlink communication, because we expect
> + * the only one ACK reply.
> + */
> + assert((bc->size - msg) >= sizeof(struct nlmsghdr));
> + nlh = (struct nlmsghdr *)&bc->msg[msg];
> + assert((bc->size - msg) >= nlh->nlmsg_len);
> + msg += nlh->nlmsg_len;
> + rc = flow_tcf_nl_ack(tcf, nlh, 0, NULL, NULL);
> + if (rc) {
> + DRV_LOG(WARNING,
> + "netlink: cleanup error %d", rc);
> + if (!ret)
> + ret = rc;
> + }
> }
> rte_free(bc);
> bc = bn;
> --
> 1.8.3.1
>
next prev parent reply other threads:[~2018-11-11 11:41 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-10 9:59 [dpdk-dev] [PATCH 0/3] fix VXLAN related rules cleanup and management Slava Ovsiienko
2018-11-10 9:59 ` [dpdk-dev] [PATCH 1/3] net/mlx5: fix buffer allocation check in rule cleanup Slava Ovsiienko
2018-11-11 11:35 ` Yongseok Koh
2018-11-10 9:59 ` [dpdk-dev] [PATCH 3/3] net/mlx5: fix rule cleanup Netlink command sending Slava Ovsiienko
2018-11-11 11:41 ` Yongseok Koh [this message]
2018-11-12 5:25 ` Slava Ovsiienko
2018-11-10 9:59 ` [dpdk-dev] [PATCH 2/3] net/mlx5: add Netlink message size check in rule cleanup Slava Ovsiienko
2018-11-11 11:39 ` Yongseok Koh
2018-11-11 12:42 ` [dpdk-dev] [PATCH 0/3] fix VXLAN related rules cleanup and management 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=9DE1F3C9-D4C0-45B7-9B8C-DA9D80C53FC2@mellanox.com \
--to=yskoh@mellanox.com \
--cc=dev@dpdk.org \
--cc=shahafs@mellanox.com \
--cc=viacheslavo@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).