From: Paolo Abeni <pabeni@redhat.com>
To: Zhiyuan Hou <zhiyuan2048@linux.alibaba.com>,
davem@davemloft.net, idosch@mellanox.com, daniel@iogearbox.net,
petrm@mellanox.com, jiri@mellanox.com, tglx@linutronix.de,
linmiaohe@huawei.com
Cc: zhabin@linux.alibaba.com, caspar@linux.alibaba.com,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH net-next] net: ipvlan: forward ingress packet to slave's l2 in l3s mode
Date: Wed, 26 Jun 2019 10:16:54 +0200 [thread overview]
Message-ID: <24fab1f43190f4994e47da4c2fa3fd622cd4e8ca.camel@redhat.com> (raw)
In-Reply-To: <20190625064208.2256-1-zhiyuan2048@linux.alibaba.com>
Hi,
On Tue, 2019-06-25 at 14:42 +0800, Zhiyuan Hou wrote:
> In ipvlan l3s mode, ingress packet is switched to slave interface and
> delivers to l4 stack. This may cause two problems:
>
> 1. When slave is in an ns different from master, the behavior of stack
> in slave ns may cause confusion for users. For example, iptables, tc,
> and other l2/l3 functions are not available for ingress packet.
>
> 2. l3s mode is not used for tap device, and cannot support ipvtap. But
> in VM or container based VM cases, tap device is a very common device.
>
> In l3s mode's input nf_hook, this patch calles the skb_forward_dev() to
> forward ingress packet to slave and uses nf_conntrack_confirm() to make
> conntrack work with new mode.
>
> Signed-off-by: Zha Bin <zhabin@linux.alibaba.com>
> Signed-off-by: Zhiyuan Hou <zhiyuan2048@linux.alibaba.com>
> ---
> drivers/net/ipvlan/ipvlan.h | 9 ++++++++-
> drivers/net/ipvlan/ipvlan_l3s.c | 16 ++++++++++++++--
> 2 files changed, 22 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/ipvlan/ipvlan.h b/drivers/net/ipvlan/ipvlan.h
> index 3837c897832e..48c814e24c3f 100644
> --- a/drivers/net/ipvlan/ipvlan.h
> +++ b/drivers/net/ipvlan/ipvlan.h
> @@ -172,6 +172,14 @@ void ipvlan_link_delete(struct net_device *dev, struct list_head *head);
> void ipvlan_link_setup(struct net_device *dev);
> int ipvlan_link_register(struct rtnl_link_ops *ops);
> #ifdef CONFIG_IPVLAN_L3S
> +
> +#include <net/netfilter/nf_conntrack_core.h>
> +
> +static inline int ipvlan_confirm_conntrack(struct sk_buff *skb)
> +{
> + return nf_conntrack_confirm(skb);
> +}
> +
> int ipvlan_l3s_register(struct ipvl_port *port);
> void ipvlan_l3s_unregister(struct ipvl_port *port);
> void ipvlan_migrate_l3s_hook(struct net *oldnet, struct net *newnet);
> @@ -206,5 +214,4 @@ static inline bool netif_is_ipvlan_port(const struct net_device *dev)
> {
> return rcu_access_pointer(dev->rx_handler) == ipvlan_handle_frame;
> }
> -
> #endif /* __IPVLAN_H */
> diff --git a/drivers/net/ipvlan/ipvlan_l3s.c b/drivers/net/ipvlan/ipvlan_l3s.c
> index 943d26cbf39f..ed210002f593 100644
> --- a/drivers/net/ipvlan/ipvlan_l3s.c
> +++ b/drivers/net/ipvlan/ipvlan_l3s.c
> @@ -95,14 +95,26 @@ static unsigned int ipvlan_nf_input(void *priv, struct sk_buff *skb,
> {
> struct ipvl_addr *addr;
> unsigned int len;
> + int ret = NF_ACCEPT;
> + bool success;
>
> addr = ipvlan_skb_to_addr(skb, skb->dev);
> if (!addr)
> goto out;
>
> - skb->dev = addr->master->dev;
> len = skb->len + ETH_HLEN;
> - ipvlan_count_rx(addr->master, len, true, false);
> +
> + ret = ipvlan_confirm_conntrack(skb);
> + if (ret != NF_ACCEPT) {
> + ipvlan_count_rx(addr->master, len, false, false);
> + goto out;
> + }
> +
> + skb_push_rcsum(skb, ETH_HLEN);
> + success = dev_forward_skb(addr->master->dev, skb) == NET_RX_SUCCESS;
This looks weird to me: if I read the code correctly, the skb will
traverse twice NF_INET_LOCAL_IN, once due to the l3s hooking and
another one due to dev_forward_skb().
Also, tc ingreess, etc will run after the first traversing of
NF_INET_LOCAL_IN.
All in all I think that if full l2 processing is required, a different
mode or a different virtual device should be used.
Cheers,
Paolo
next prev parent reply other threads:[~2019-06-26 8:17 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-25 6:42 [PATCH net-next] net: ipvlan: forward ingress packet to slave's l2 in l3s mode Zhiyuan Hou
2019-06-26 8:16 ` Paolo Abeni [this message]
2019-06-28 8:59 ` Zhiyuan Hou
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=24fab1f43190f4994e47da4c2fa3fd622cd4e8ca.camel@redhat.com \
--to=pabeni@redhat.com \
--cc=caspar@linux.alibaba.com \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=idosch@mellanox.com \
--cc=jiri@mellanox.com \
--cc=linmiaohe@huawei.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=petrm@mellanox.com \
--cc=tglx@linutronix.de \
--cc=zhabin@linux.alibaba.com \
--cc=zhiyuan2048@linux.alibaba.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