From: David Miller <davem@davemloft.net> To: ja@ssi.bg Cc: netdev@vger.kernel.org, linux-sctp@vger.kernel.org, yuehaibing@huawei.com Subject: Re: [PATCHv2 RFC net-next 0/7] net: dst_confirm replacement Date: Mon, 30 Jan 2017 10:13:39 -0500 (EST) [thread overview] Message-ID: <20170130.101339.2050288140097606206.davem@davemloft.net> (raw) In-Reply-To: <1485613578-19973-1-git-send-email-ja@ssi.bg> From: Julian Anastasov <ja@ssi.bg> Date: Sat, 28 Jan 2017 16:26:11 +0200 > This patchset addresses the problem of neighbour > confirmation where received replies from one nexthop > can cause confirmation of different nexthop when using > the same dst. Thanks to YueHaibing <yuehaibing@huawei.com> > for tracking the dst->pending_confirm problem. > > Sockets can obtain cached output route. Such > routes can be to known nexthop (rt_gateway=IP) or to be > used simultaneously for different nexthop IPs by different > subnet prefixes (nh->nh_scope = RT_SCOPE_HOST, rt_gateway=0). > > At first look, there are more problems: > > - dst_confirm() sets flag on dst and not on dst->path, > as result, indication is lost when XFRM is used > > - DNAT can change the nexthop, so the really used nexthop is > not confirmed > > So, the following solution is to avoid using > dst->pending_confirm. For the most part this series looks good to me, nice work. > - I failed to understand the CXGB* code, I see dst_confirm() > calls but I'm not sure dst_neigh_output() was called. For now > I just removed the dst->pending_confirm flag and left all > dst_confirm() calls there. Any better idea? It is trying to manage the dst and neigh state for TCP connections managed by it's offload engine. So you will not therefore see any actual packet output for the sessions it is performing confirmation for.
WARNING: multiple messages have this Message-ID (diff)
From: David Miller <davem@davemloft.net> To: ja@ssi.bg Cc: netdev@vger.kernel.org, linux-sctp@vger.kernel.org, yuehaibing@huawei.com Subject: Re: [PATCHv2 RFC net-next 0/7] net: dst_confirm replacement Date: Mon, 30 Jan 2017 15:13:39 +0000 [thread overview] Message-ID: <20170130.101339.2050288140097606206.davem@davemloft.net> (raw) In-Reply-To: <1485613578-19973-1-git-send-email-ja@ssi.bg> From: Julian Anastasov <ja@ssi.bg> Date: Sat, 28 Jan 2017 16:26:11 +0200 > This patchset addresses the problem of neighbour > confirmation where received replies from one nexthop > can cause confirmation of different nexthop when using > the same dst. Thanks to YueHaibing <yuehaibing@huawei.com> > for tracking the dst->pending_confirm problem. > > Sockets can obtain cached output route. Such > routes can be to known nexthop (rt_gateway=IP) or to be > used simultaneously for different nexthop IPs by different > subnet prefixes (nh->nh_scope = RT_SCOPE_HOST, rt_gateway=0). > > At first look, there are more problems: > > - dst_confirm() sets flag on dst and not on dst->path, > as result, indication is lost when XFRM is used > > - DNAT can change the nexthop, so the really used nexthop is > not confirmed > > So, the following solution is to avoid using > dst->pending_confirm. For the most part this series looks good to me, nice work. > - I failed to understand the CXGB* code, I see dst_confirm() > calls but I'm not sure dst_neigh_output() was called. For now > I just removed the dst->pending_confirm flag and left all > dst_confirm() calls there. Any better idea? It is trying to manage the dst and neigh state for TCP connections managed by it's offload engine. So you will not therefore see any actual packet output for the sessions it is performing confirmation for.
next prev parent reply other threads:[~2017-01-30 15:14 UTC|newest] Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-01-28 14:26 [PATCHv2 RFC net-next 0/7] net: dst_confirm replacement Julian Anastasov 2017-01-28 14:26 ` Julian Anastasov 2017-01-28 14:26 ` [PATCHv2 RFC net-next 1/7] sock: add sk_dst_pending_confirm flag Julian Anastasov 2017-01-28 14:26 ` Julian Anastasov 2017-01-28 14:26 ` [PATCHv2 RFC net-next 2/7] net: add dst_pending_confirm flag to skbuff Julian Anastasov 2017-01-28 14:26 ` Julian Anastasov 2017-01-28 14:26 ` [PATCHv2 RFC net-next 3/7] sctp: add dst_pending_confirm flag Julian Anastasov 2017-01-28 14:26 ` Julian Anastasov 2017-01-30 14:45 ` Neil Horman 2017-01-30 14:45 ` Neil Horman 2017-01-28 14:26 ` [PATCHv2 RFC net-next 4/7] tcp: replace dst_confirm with sk_dst_confirm Julian Anastasov 2017-01-28 14:26 ` Julian Anastasov 2017-01-29 19:27 ` Eric Dumazet 2017-01-29 19:27 ` Eric Dumazet 2017-01-28 14:26 ` [PATCHv2 RFC net-next 5/7] net: add confirm_neigh method to dst_ops Julian Anastasov 2017-01-28 14:26 ` Julian Anastasov 2017-01-28 14:26 ` [PATCHv2 RFC net-next 6/7] net: use dst_confirm_neigh for UDP, RAW, ICMP, L2TP Julian Anastasov 2017-01-28 14:26 ` Julian Anastasov 2017-01-28 14:26 ` [PATCHv2 RFC net-next 7/7] net: pending_confirm is not used anymore Julian Anastasov 2017-01-28 14:26 ` Julian Anastasov 2017-01-30 15:13 ` David Miller [this message] 2017-01-30 15:13 ` [PATCHv2 RFC net-next 0/7] net: dst_confirm replacement David Miller 2017-01-31 21:53 ` Julian Anastasov 2017-01-31 21:53 ` Julian Anastasov
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=20170130.101339.2050288140097606206.davem@davemloft.net \ --to=davem@davemloft.net \ --cc=ja@ssi.bg \ --cc=linux-sctp@vger.kernel.org \ --cc=netdev@vger.kernel.org \ --cc=yuehaibing@huawei.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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.