* [PATCH net-next v7 0/4] Enable virtio_net to act as a standby for a passthru device
@ 2018-04-20 1:42 ` Sridhar Samudrala
0 siblings, 0 replies; 114+ messages in thread
From: Sridhar Samudrala @ 2018-04-20 1:42 UTC (permalink / raw)
To: mst, stephen, davem, netdev, virtualization, virtio-dev,
jesse.brandeburg, alexander.h.duyck, kubakici, sridhar.samudrala,
jasowang, loseweigh, jiri
The main motivation for this patch is to enable cloud service providers
to provide an accelerated datapath to virtio-net enabled VMs in a
transparent manner with no/minimal guest userspace changes. This also
enables hypervisor controlled live migration to be supported with VMs that
have direct attached SR-IOV VF devices.
Patch 1 introduces a new feature bit VIRTIO_NET_F_STANDBY that can be
used by hypervisor to indicate that virtio_net interface should act as
a standby for another device with the same MAC address.
Patch 2 introduces a failover module that provides a generic interface for
paravirtual drivers to listen for netdev register/unregister/link change
events from pci ethernet devices with the same MAC and takeover their
datapath. The notifier and event handling code is based on the existing
netvsc implementation. It provides 2 sets of interfaces to paravirtual
drivers to support 2-netdev(netvsc) and 3-netdev(virtio_net) models.
Patch 3 extends virtio_net to use alternate datapath when available and
registered. When STANDBY feature is enabled, virtio_net driver creates
an additional 'failover' netdev that acts as a master device and controls
2 slave devices. The original virtio_net netdev is registered as
'standby' netdev and a passthru/vf device with the same MAC gets
registered as 'primary' netdev. Both 'standby' and 'primary' netdevs are
associated with the same 'pci' device. The user accesses the network
interface via 'failover' netdev. The 'failover' netdev chooses 'primary'
netdev as default for transmits when it is available with link up and
running.
Patch 4 refactors netvsc to use the registration/notification framework
supported by failover module.
As this patch series is initially focusing on usecases where hypervisor
fully controls the VM networking and the guest is not expected to directly
configure any hardware settings, it doesn't expose all the ndo/ethtool ops
that are supported by virtio_net at this time. To support additional usecases,
it should be possible to enable additional ops later by caching the state
in virtio netdev and replaying when the 'primary' netdev gets registered.
The hypervisor needs to enable only one datapath at any time so that packets
don't get looped back to the VM over the other datapath. When a VF is
plugged, the virtio datapath link state can be marked as down.
At the time of live migration, the hypervisor needs to unplug the VF device
from the guest on the source host and reset the MAC filter of the VF to
initiate failover of datapath to virtio before starting the migration. After
the migration is completed, the destination hypervisor sets the MAC filter
on the VF and plugs it back to the guest to switch over to VF datapath.
This patch is based on the discussion initiated by Jesse on this thread.
https://marc.info/?l=linux-virtualization&m=151189725224231&w=2
v7
- Rename 'bypass/active/backup' terminology with 'failover/primary/standy'
(jiri, mst)
- re-arranged dev_open() and dev_set_mtu() calls in the register routines
so that they don't get called for 2-netdev model. (stephen)
- fixed select_queue() routine to do queue selection based on VF if it is
registered as primary. (stephen)
- minor bugfixes
v6 RFC:
Simplified virtio_net changes by moving all the ndo_ops of the
bypass_netdev and create/destroy of bypass_netdev to 'bypass' module.
avoided 2 phase registration(driver + instances).
introduced IFF_BYPASS/IFF_BYPASS_SLAVE dev->priv_flags
replaced mutex with a spinlock
v5 RFC:
Based on Jiri's comments, moved the common functionality to a 'bypass'
module so that the same notifier and event handlers to handle child
register/unregister/link change events can be shared between virtio_net
and netvsc.
Improved error handling based on Siwei's comments.
v4:
- Based on the review comments on the v3 version of the RFC patch and
Jakub's suggestion for the naming issue with 3 netdev solution,
proposed 3 netdev in-driver bonding solution for virtio-net.
v3 RFC:
- Introduced 3 netdev model and pointed out a couple of issues with
that model and proposed 2 netdev model to avoid these issues.
- Removed broadcast/multicast optimization and only use virtio as
backup path when VF is unplugged.
v2 RFC:
- Changed VIRTIO_NET_F_MASTER to VIRTIO_NET_F_BACKUP (mst)
- made a small change to the virtio-net xmit path to only use VF datapath
for unicasts. Broadcasts/multicasts use virtio datapath. This avoids
east-west broadcasts to go over the PCI link.
- added suppport for the feature bit in qemu
Sridhar Samudrala (4):
virtio_net: Introduce VIRTIO_NET_F_STANDBY feature bit
net: Introduce generic failover module
virtio_net: Extend virtio to use VF datapath when available
netvsc: refactor notifier/event handling code to use the failover
framework
drivers/net/Kconfig | 1 +
drivers/net/hyperv/Kconfig | 1 +
drivers/net/hyperv/hyperv_net.h | 2 +
drivers/net/hyperv/netvsc_drv.c | 208 +++-------
drivers/net/virtio_net.c | 38 +-
include/linux/netdevice.h | 16 +
include/net/failover.h | 96 +++++
include/uapi/linux/virtio_net.h | 3 +
net/Kconfig | 18 +
net/core/Makefile | 1 +
net/core/failover.c | 844 ++++++++++++++++++++++++++++++++++++++++
11 files changed, 1070 insertions(+), 158 deletions(-)
create mode 100644 include/net/failover.h
create mode 100644 net/core/failover.c
--
2.14.3
^ permalink raw reply [flat|nested] 114+ messages in thread
* [virtio-dev] [PATCH net-next v7 0/4] Enable virtio_net to act as a standby for a passthru device
@ 2018-04-20 1:42 ` Sridhar Samudrala
0 siblings, 0 replies; 114+ messages in thread
From: Sridhar Samudrala @ 2018-04-20 1:42 UTC (permalink / raw)
To: mst, stephen, davem, netdev, virtualization, virtio-dev,
jesse.brandeburg, alexander.h.duyck, kubakici, sridhar.samudrala,
jasowang, loseweigh, jiri
The main motivation for this patch is to enable cloud service providers
to provide an accelerated datapath to virtio-net enabled VMs in a
transparent manner with no/minimal guest userspace changes. This also
enables hypervisor controlled live migration to be supported with VMs that
have direct attached SR-IOV VF devices.
Patch 1 introduces a new feature bit VIRTIO_NET_F_STANDBY that can be
used by hypervisor to indicate that virtio_net interface should act as
a standby for another device with the same MAC address.
Patch 2 introduces a failover module that provides a generic interface for
paravirtual drivers to listen for netdev register/unregister/link change
events from pci ethernet devices with the same MAC and takeover their
datapath. The notifier and event handling code is based on the existing
netvsc implementation. It provides 2 sets of interfaces to paravirtual
drivers to support 2-netdev(netvsc) and 3-netdev(virtio_net) models.
Patch 3 extends virtio_net to use alternate datapath when available and
registered. When STANDBY feature is enabled, virtio_net driver creates
an additional 'failover' netdev that acts as a master device and controls
2 slave devices. The original virtio_net netdev is registered as
'standby' netdev and a passthru/vf device with the same MAC gets
registered as 'primary' netdev. Both 'standby' and 'primary' netdevs are
associated with the same 'pci' device. The user accesses the network
interface via 'failover' netdev. The 'failover' netdev chooses 'primary'
netdev as default for transmits when it is available with link up and
running.
Patch 4 refactors netvsc to use the registration/notification framework
supported by failover module.
As this patch series is initially focusing on usecases where hypervisor
fully controls the VM networking and the guest is not expected to directly
configure any hardware settings, it doesn't expose all the ndo/ethtool ops
that are supported by virtio_net at this time. To support additional usecases,
it should be possible to enable additional ops later by caching the state
in virtio netdev and replaying when the 'primary' netdev gets registered.
The hypervisor needs to enable only one datapath at any time so that packets
don't get looped back to the VM over the other datapath. When a VF is
plugged, the virtio datapath link state can be marked as down.
At the time of live migration, the hypervisor needs to unplug the VF device
from the guest on the source host and reset the MAC filter of the VF to
initiate failover of datapath to virtio before starting the migration. After
the migration is completed, the destination hypervisor sets the MAC filter
on the VF and plugs it back to the guest to switch over to VF datapath.
This patch is based on the discussion initiated by Jesse on this thread.
https://marc.info/?l=linux-virtualization&m=151189725224231&w=2
v7
- Rename 'bypass/active/backup' terminology with 'failover/primary/standy'
(jiri, mst)
- re-arranged dev_open() and dev_set_mtu() calls in the register routines
so that they don't get called for 2-netdev model. (stephen)
- fixed select_queue() routine to do queue selection based on VF if it is
registered as primary. (stephen)
- minor bugfixes
v6 RFC:
Simplified virtio_net changes by moving all the ndo_ops of the
bypass_netdev and create/destroy of bypass_netdev to 'bypass' module.
avoided 2 phase registration(driver + instances).
introduced IFF_BYPASS/IFF_BYPASS_SLAVE dev->priv_flags
replaced mutex with a spinlock
v5 RFC:
Based on Jiri's comments, moved the common functionality to a 'bypass'
module so that the same notifier and event handlers to handle child
register/unregister/link change events can be shared between virtio_net
and netvsc.
Improved error handling based on Siwei's comments.
v4:
- Based on the review comments on the v3 version of the RFC patch and
Jakub's suggestion for the naming issue with 3 netdev solution,
proposed 3 netdev in-driver bonding solution for virtio-net.
v3 RFC:
- Introduced 3 netdev model and pointed out a couple of issues with
that model and proposed 2 netdev model to avoid these issues.
- Removed broadcast/multicast optimization and only use virtio as
backup path when VF is unplugged.
v2 RFC:
- Changed VIRTIO_NET_F_MASTER to VIRTIO_NET_F_BACKUP (mst)
- made a small change to the virtio-net xmit path to only use VF datapath
for unicasts. Broadcasts/multicasts use virtio datapath. This avoids
east-west broadcasts to go over the PCI link.
- added suppport for the feature bit in qemu
Sridhar Samudrala (4):
virtio_net: Introduce VIRTIO_NET_F_STANDBY feature bit
net: Introduce generic failover module
virtio_net: Extend virtio to use VF datapath when available
netvsc: refactor notifier/event handling code to use the failover
framework
drivers/net/Kconfig | 1 +
drivers/net/hyperv/Kconfig | 1 +
drivers/net/hyperv/hyperv_net.h | 2 +
drivers/net/hyperv/netvsc_drv.c | 208 +++-------
drivers/net/virtio_net.c | 38 +-
include/linux/netdevice.h | 16 +
include/net/failover.h | 96 +++++
include/uapi/linux/virtio_net.h | 3 +
net/Kconfig | 18 +
net/core/Makefile | 1 +
net/core/failover.c | 844 ++++++++++++++++++++++++++++++++++++++++
11 files changed, 1070 insertions(+), 158 deletions(-)
create mode 100644 include/net/failover.h
create mode 100644 net/core/failover.c
--
2.14.3
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 114+ messages in thread
* [PATCH v7 net-next 1/4] virtio_net: Introduce VIRTIO_NET_F_STANDBY feature bit
2018-04-20 1:42 ` [virtio-dev] " Sridhar Samudrala
@ 2018-04-20 1:42 ` Sridhar Samudrala
-1 siblings, 0 replies; 114+ messages in thread
From: Sridhar Samudrala @ 2018-04-20 1:42 UTC (permalink / raw)
To: mst, stephen, davem, netdev, virtualization, virtio-dev,
jesse.brandeburg, alexander.h.duyck, kubakici, sridhar.samudrala,
jasowang, loseweigh, jiri
This feature bit can be used by hypervisor to indicate virtio_net device to
act as a standby for another device with the same MAC address.
VIRTIO_NET_F_STANDBY is defined as bit 62 as it is a device feature bit.
Signed-off-by: Sridhar Samudrala <sridhar.samudrala@intel.com>
---
drivers/net/virtio_net.c | 2 +-
include/uapi/linux/virtio_net.h | 3 +++
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 7b187ec7411e..6f95719ede40 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -2962,7 +2962,7 @@ static struct virtio_device_id id_table[] = {
VIRTIO_NET_F_GUEST_ANNOUNCE, VIRTIO_NET_F_MQ, \
VIRTIO_NET_F_CTRL_MAC_ADDR, \
VIRTIO_NET_F_MTU, VIRTIO_NET_F_CTRL_GUEST_OFFLOADS, \
- VIRTIO_NET_F_SPEED_DUPLEX
+ VIRTIO_NET_F_SPEED_DUPLEX, VIRTIO_NET_F_STANDBY
static unsigned int features[] = {
VIRTNET_FEATURES,
diff --git a/include/uapi/linux/virtio_net.h b/include/uapi/linux/virtio_net.h
index 5de6ed37695b..a3715a3224c1 100644
--- a/include/uapi/linux/virtio_net.h
+++ b/include/uapi/linux/virtio_net.h
@@ -57,6 +57,9 @@
* Steering */
#define VIRTIO_NET_F_CTRL_MAC_ADDR 23 /* Set MAC address */
+#define VIRTIO_NET_F_STANDBY 62 /* Act as standby for another device
+ * with the same MAC.
+ */
#define VIRTIO_NET_F_SPEED_DUPLEX 63 /* Device set linkspeed and duplex */
#ifndef VIRTIO_NET_NO_LEGACY
--
2.14.3
^ permalink raw reply related [flat|nested] 114+ messages in thread
* [PATCH v7 net-next 1/4] virtio_net: Introduce VIRTIO_NET_F_STANDBY feature bit
2018-04-20 1:42 ` [virtio-dev] " Sridhar Samudrala
(?)
(?)
@ 2018-04-20 1:42 ` Sridhar Samudrala
-1 siblings, 0 replies; 114+ messages in thread
From: Sridhar Samudrala @ 2018-04-20 1:42 UTC (permalink / raw)
To: mst, stephen, davem, netdev, virtualization, virtio-dev,
jesse.brandeburg, alexander.h.duyck, kubakici, sridhar.samudrala,
jasowang, loseweigh, jiri
This feature bit can be used by hypervisor to indicate virtio_net device to
act as a standby for another device with the same MAC address.
VIRTIO_NET_F_STANDBY is defined as bit 62 as it is a device feature bit.
Signed-off-by: Sridhar Samudrala <sridhar.samudrala@intel.com>
---
drivers/net/virtio_net.c | 2 +-
include/uapi/linux/virtio_net.h | 3 +++
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 7b187ec7411e..6f95719ede40 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -2962,7 +2962,7 @@ static struct virtio_device_id id_table[] = {
VIRTIO_NET_F_GUEST_ANNOUNCE, VIRTIO_NET_F_MQ, \
VIRTIO_NET_F_CTRL_MAC_ADDR, \
VIRTIO_NET_F_MTU, VIRTIO_NET_F_CTRL_GUEST_OFFLOADS, \
- VIRTIO_NET_F_SPEED_DUPLEX
+ VIRTIO_NET_F_SPEED_DUPLEX, VIRTIO_NET_F_STANDBY
static unsigned int features[] = {
VIRTNET_FEATURES,
diff --git a/include/uapi/linux/virtio_net.h b/include/uapi/linux/virtio_net.h
index 5de6ed37695b..a3715a3224c1 100644
--- a/include/uapi/linux/virtio_net.h
+++ b/include/uapi/linux/virtio_net.h
@@ -57,6 +57,9 @@
* Steering */
#define VIRTIO_NET_F_CTRL_MAC_ADDR 23 /* Set MAC address */
+#define VIRTIO_NET_F_STANDBY 62 /* Act as standby for another device
+ * with the same MAC.
+ */
#define VIRTIO_NET_F_SPEED_DUPLEX 63 /* Device set linkspeed and duplex */
#ifndef VIRTIO_NET_NO_LEGACY
--
2.14.3
^ permalink raw reply related [flat|nested] 114+ messages in thread
* [virtio-dev] [PATCH v7 net-next 1/4] virtio_net: Introduce VIRTIO_NET_F_STANDBY feature bit
@ 2018-04-20 1:42 ` Sridhar Samudrala
0 siblings, 0 replies; 114+ messages in thread
From: Sridhar Samudrala @ 2018-04-20 1:42 UTC (permalink / raw)
To: mst, stephen, davem, netdev, virtualization, virtio-dev,
jesse.brandeburg, alexander.h.duyck, kubakici, sridhar.samudrala,
jasowang, loseweigh, jiri
This feature bit can be used by hypervisor to indicate virtio_net device to
act as a standby for another device with the same MAC address.
VIRTIO_NET_F_STANDBY is defined as bit 62 as it is a device feature bit.
Signed-off-by: Sridhar Samudrala <sridhar.samudrala@intel.com>
---
drivers/net/virtio_net.c | 2 +-
include/uapi/linux/virtio_net.h | 3 +++
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 7b187ec7411e..6f95719ede40 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -2962,7 +2962,7 @@ static struct virtio_device_id id_table[] = {
VIRTIO_NET_F_GUEST_ANNOUNCE, VIRTIO_NET_F_MQ, \
VIRTIO_NET_F_CTRL_MAC_ADDR, \
VIRTIO_NET_F_MTU, VIRTIO_NET_F_CTRL_GUEST_OFFLOADS, \
- VIRTIO_NET_F_SPEED_DUPLEX
+ VIRTIO_NET_F_SPEED_DUPLEX, VIRTIO_NET_F_STANDBY
static unsigned int features[] = {
VIRTNET_FEATURES,
diff --git a/include/uapi/linux/virtio_net.h b/include/uapi/linux/virtio_net.h
index 5de6ed37695b..a3715a3224c1 100644
--- a/include/uapi/linux/virtio_net.h
+++ b/include/uapi/linux/virtio_net.h
@@ -57,6 +57,9 @@
* Steering */
#define VIRTIO_NET_F_CTRL_MAC_ADDR 23 /* Set MAC address */
+#define VIRTIO_NET_F_STANDBY 62 /* Act as standby for another device
+ * with the same MAC.
+ */
#define VIRTIO_NET_F_SPEED_DUPLEX 63 /* Device set linkspeed and duplex */
#ifndef VIRTIO_NET_NO_LEGACY
--
2.14.3
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply related [flat|nested] 114+ messages in thread
* [PATCH v7 net-next 2/4] net: Introduce generic failover module
2018-04-20 1:42 ` [virtio-dev] " Sridhar Samudrala
@ 2018-04-20 1:42 ` Sridhar Samudrala
-1 siblings, 0 replies; 114+ messages in thread
From: Sridhar Samudrala @ 2018-04-20 1:42 UTC (permalink / raw)
To: mst, stephen, davem, netdev, virtualization, virtio-dev,
jesse.brandeburg, alexander.h.duyck, kubakici, sridhar.samudrala,
jasowang, loseweigh, jiri
This provides a generic interface for paravirtual drivers to listen
for netdev register/unregister/link change events from pci ethernet
devices with the same MAC and takeover their datapath. The notifier and
event handling code is based on the existing netvsc implementation.
It exposes 2 sets of interfaces to the paravirtual drivers.
1. existing netvsc driver that uses 2 netdev model. In this model, no
master netdev is created. The paravirtual driver registers each instance
of netvsc as a 'failover' instance along with a set of ops to manage the
slave events.
failover_register()
failover_unregister()
2. new virtio_net based solution that uses 3 netdev model. In this model,
the failover module provides interfaces to create/destroy additional master
netdev and all the slave events are managed internally.
failover_create()
failover_destroy()
These functions call failover_register()/failover_unregister() with the
master netdev created by the failover module.
Signed-off-by: Sridhar Samudrala <sridhar.samudrala@intel.com>
---
include/linux/netdevice.h | 16 +
include/net/failover.h | 96 ++++++
net/Kconfig | 18 +
net/core/Makefile | 1 +
net/core/failover.c | 844 ++++++++++++++++++++++++++++++++++++++++++++++
5 files changed, 975 insertions(+)
create mode 100644 include/net/failover.h
create mode 100644 net/core/failover.c
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index cf44503ea81a..ed535b6724e1 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -1401,6 +1401,8 @@ struct net_device_ops {
* entity (i.e. the master device for bridged veth)
* @IFF_MACSEC: device is a MACsec device
* @IFF_NO_RX_HANDLER: device doesn't support the rx_handler hook
+ * @IFF_FAILOVER: device is a failover master device
+ * @IFF_FAILOVER_SLAVE: device is lower dev of a failover master device
*/
enum netdev_priv_flags {
IFF_802_1Q_VLAN = 1<<0,
@@ -1430,6 +1432,8 @@ enum netdev_priv_flags {
IFF_PHONY_HEADROOM = 1<<24,
IFF_MACSEC = 1<<25,
IFF_NO_RX_HANDLER = 1<<26,
+ IFF_FAILOVER = 1<<27,
+ IFF_FAILOVER_SLAVE = 1<<28,
};
#define IFF_802_1Q_VLAN IFF_802_1Q_VLAN
@@ -1458,6 +1462,8 @@ enum netdev_priv_flags {
#define IFF_RXFH_CONFIGURED IFF_RXFH_CONFIGURED
#define IFF_MACSEC IFF_MACSEC
#define IFF_NO_RX_HANDLER IFF_NO_RX_HANDLER
+#define IFF_FAILOVER IFF_FAILOVER
+#define IFF_FAILOVER_SLAVE IFF_FAILOVER_SLAVE
/**
* struct net_device - The DEVICE structure.
@@ -4308,6 +4314,16 @@ static inline bool netif_is_rxfh_configured(const struct net_device *dev)
return dev->priv_flags & IFF_RXFH_CONFIGURED;
}
+static inline bool netif_is_failover(const struct net_device *dev)
+{
+ return dev->priv_flags & IFF_FAILOVER;
+}
+
+static inline bool netif_is_failover_slave(const struct net_device *dev)
+{
+ return dev->priv_flags & IFF_FAILOVER_SLAVE;
+}
+
/* This device needs to keep skb dst for qdisc enqueue or ndo_start_xmit() */
static inline void netif_keep_dst(struct net_device *dev)
{
diff --git a/include/net/failover.h b/include/net/failover.h
new file mode 100644
index 000000000000..0b8601043d90
--- /dev/null
+++ b/include/net/failover.h
@@ -0,0 +1,96 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/* Copyright (c) 2018, Intel Corporation. */
+
+#ifndef _NET_FAILOVER_H
+#define _NET_FAILOVER_H
+
+#include <linux/netdevice.h>
+
+struct failover_ops {
+ int (*slave_pre_register)(struct net_device *slave_dev,
+ struct net_device *failover_dev);
+ int (*slave_join)(struct net_device *slave_dev,
+ struct net_device *failover_dev);
+ int (*slave_pre_unregister)(struct net_device *slave_dev,
+ struct net_device *failover_dev);
+ int (*slave_release)(struct net_device *slave_dev,
+ struct net_device *failover_dev);
+ int (*slave_link_change)(struct net_device *slave_dev,
+ struct net_device *failover_dev);
+ rx_handler_result_t (*handle_frame)(struct sk_buff **pskb);
+};
+
+struct failover {
+ struct list_head list;
+ struct net_device __rcu *failover_dev;
+ struct failover_ops __rcu *ops;
+};
+
+/* failover state */
+struct failover_info {
+ /* primary netdev with same MAC */
+ struct net_device __rcu *primary_dev;
+
+ /* standby netdev */
+ struct net_device __rcu *standby_dev;
+
+ /* primary netdev stats */
+ struct rtnl_link_stats64 primary_stats;
+
+ /* standby netdev stats */
+ struct rtnl_link_stats64 standby_stats;
+
+ /* aggregated stats */
+ struct rtnl_link_stats64 failover_stats;
+
+ /* spinlock while updating stats */
+ spinlock_t stats_lock;
+};
+
+#if IS_ENABLED(CONFIG_NET_FAILOVER)
+
+int failover_create(struct net_device *standby_dev,
+ struct failover **pfailover);
+void failover_destroy(struct failover *failover);
+
+int failover_register(struct net_device *standby_dev, struct failover_ops *ops,
+ struct failover **pfailover);
+void failover_unregister(struct failover *failover);
+
+int failover_slave_unregister(struct net_device *slave_dev);
+
+#else
+
+static inline
+int failover_create(struct net_device *standby_dev,
+ struct failover **pfailover);
+{
+ return 0;
+}
+
+static inline
+void failover_destroy(struct failover *failover)
+{
+}
+
+static inline
+int failover_register(struct net_device *standby_dev, struct failover_ops *ops,
+ struct pfailover **pfailover);
+{
+ return 0;
+}
+
+static inline
+void failover_unregister(struct failover *failover)
+{
+}
+
+static inline
+int failover_slave_unregister(struct net_device *slave_dev)
+{
+ return 0;
+}
+
+#endif
+
+#endif /* _NET_FAILOVER_H */
diff --git a/net/Kconfig b/net/Kconfig
index 0428f12c25c2..388b99dfee10 100644
--- a/net/Kconfig
+++ b/net/Kconfig
@@ -423,6 +423,24 @@ config MAY_USE_DEVLINK
on MAY_USE_DEVLINK to ensure they do not cause link errors when
devlink is a loadable module and the driver using it is built-in.
+config NET_FAILOVER
+ tristate "Failover interface"
+ help
+ This provides a generic interface for paravirtual drivers to listen
+ for netdev register/unregister/link change events from pci ethernet
+ devices with the same MAC and takeover their datapath. This also
+ enables live migration of a VM with direct attached VF by failing
+ over to the paravirtual datapath when the VF is unplugged.
+
+config MAY_USE_FAILOVER
+ tristate
+ default m if NET_FAILOVER=m
+ default y if NET_FAILOVER=y || NET_FAILOVER=n
+ help
+ Drivers using the failover infrastructure should have a dependency
+ on MAY_USE_FAILOVER to ensure they do not cause link errors when
+ failover is a loadable module and the driver using it is built-in.
+
endif # if NET
# Used by archs to tell that they support BPF JIT compiler plus which flavour.
diff --git a/net/core/Makefile b/net/core/Makefile
index 6dbbba8c57ae..cef17518bb7d 100644
--- a/net/core/Makefile
+++ b/net/core/Makefile
@@ -30,3 +30,4 @@ obj-$(CONFIG_DST_CACHE) += dst_cache.o
obj-$(CONFIG_HWBM) += hwbm.o
obj-$(CONFIG_NET_DEVLINK) += devlink.o
obj-$(CONFIG_GRO_CELLS) += gro_cells.o
+obj-$(CONFIG_NET_FAILOVER) += failover.o
diff --git a/net/core/failover.c b/net/core/failover.c
new file mode 100644
index 000000000000..7bee762cb737
--- /dev/null
+++ b/net/core/failover.c
@@ -0,0 +1,844 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Copyright (c) 2018, Intel Corporation. */
+
+/* A common module to handle registrations and notifications for paravirtual
+ * drivers to enable accelerated datapath and support VF live migration.
+ *
+ * The notifier and event handling code is based on netvsc driver.
+ */
+
+#include <linux/netdevice.h>
+#include <linux/etherdevice.h>
+#include <linux/ethtool.h>
+#include <linux/module.h>
+#include <linux/slab.h>
+#include <linux/netdevice.h>
+#include <linux/netpoll.h>
+#include <linux/rtnetlink.h>
+#include <linux/if_vlan.h>
+#include <linux/pci.h>
+#include <net/sch_generic.h>
+#include <uapi/linux/if_arp.h>
+#include <net/failover.h>
+
+static LIST_HEAD(failover_list);
+static DEFINE_SPINLOCK(failover_lock);
+
+static int failover_slave_pre_register(struct net_device *slave_dev,
+ struct net_device *failover_dev,
+ struct failover_ops *failover_ops)
+{
+ struct failover_info *finfo;
+ bool standby;
+
+ if (failover_ops) {
+ if (!failover_ops->slave_pre_register)
+ return -EINVAL;
+
+ return failover_ops->slave_pre_register(slave_dev,
+ failover_dev);
+ }
+
+ finfo = netdev_priv(failover_dev);
+ standby = (slave_dev->dev.parent == failover_dev->dev.parent);
+ if (standby ? rtnl_dereference(finfo->standby_dev) :
+ rtnl_dereference(finfo->primary_dev)) {
+ netdev_err(failover_dev, "%s attempting to register as slave dev when %s already present\n",
+ slave_dev->name, standby ? "standby" : "primary");
+ return -EEXIST;
+ }
+
+ /* Avoid non pci devices as primary netdev */
+ if (!standby && (!slave_dev->dev.parent ||
+ !dev_is_pci(slave_dev->dev.parent)))
+ return -EINVAL;
+
+ return 0;
+}
+
+static int failover_slave_join(struct net_device *slave_dev,
+ struct net_device *failover_dev,
+ struct failover_ops *failover_ops)
+{
+ struct failover_info *finfo;
+ int err, orig_mtu;
+ bool standby;
+
+ if (failover_ops) {
+ if (!failover_ops->slave_join)
+ return -EINVAL;
+
+ return failover_ops->slave_join(slave_dev, failover_dev);
+ }
+
+ if (netif_running(failover_dev)) {
+ err = dev_open(slave_dev);
+ if (err && (err != -EBUSY)) {
+ netdev_err(failover_dev, "Opening slave %s failed err:%d\n",
+ slave_dev->name, err);
+ goto err_dev_open;
+ }
+ }
+
+ /* Align MTU of slave with failover dev */
+ orig_mtu = slave_dev->mtu;
+ err = dev_set_mtu(slave_dev, failover_dev->mtu);
+ if (err) {
+ netdev_err(failover_dev, "unable to change mtu of %s to %u register failed\n",
+ slave_dev->name, failover_dev->mtu);
+ goto err_set_mtu;
+ }
+
+ finfo = netdev_priv(failover_dev);
+ standby = (slave_dev->dev.parent == failover_dev->dev.parent);
+
+ dev_hold(slave_dev);
+
+ if (standby) {
+ rcu_assign_pointer(finfo->standby_dev, slave_dev);
+ dev_get_stats(finfo->standby_dev, &finfo->standby_stats);
+ } else {
+ rcu_assign_pointer(finfo->primary_dev, slave_dev);
+ dev_get_stats(finfo->primary_dev, &finfo->primary_stats);
+ failover_dev->min_mtu = slave_dev->min_mtu;
+ failover_dev->max_mtu = slave_dev->max_mtu;
+ }
+
+ netdev_info(failover_dev, "failover slave:%s joined\n",
+ slave_dev->name);
+
+ return 0;
+
+err_set_mtu:
+ dev_close(slave_dev);
+err_dev_open:
+ return err;
+}
+
+/* Called when slave dev is injecting data into network stack.
+ * Change the associated network device from lower dev to virtio.
+ * note: already called with rcu_read_lock
+ */
+static rx_handler_result_t failover_handle_frame(struct sk_buff **pskb)
+{
+ struct sk_buff *skb = *pskb;
+ struct net_device *ndev = rcu_dereference(skb->dev->rx_handler_data);
+
+ skb->dev = ndev;
+
+ return RX_HANDLER_ANOTHER;
+}
+
+static struct net_device *failover_get_bymac(u8 *mac, struct failover_ops **ops)
+{
+ struct net_device *failover_dev;
+ struct failover *failover;
+
+ spin_lock(&failover_lock);
+ list_for_each_entry(failover, &failover_list, list) {
+ failover_dev = rtnl_dereference(failover->failover_dev);
+ if (ether_addr_equal(failover_dev->perm_addr, mac)) {
+ *ops = rtnl_dereference(failover->ops);
+ spin_unlock(&failover_lock);
+ return failover_dev;
+ }
+ }
+ spin_unlock(&failover_lock);
+ return NULL;
+}
+
+static int failover_slave_register(struct net_device *slave_dev)
+{
+ struct failover_ops *failover_ops;
+ struct net_device *failover_dev;
+ int ret;
+
+ ASSERT_RTNL();
+
+ failover_dev = failover_get_bymac(slave_dev->perm_addr, &failover_ops);
+ if (!failover_dev)
+ goto done;
+
+ ret = failover_slave_pre_register(slave_dev, failover_dev,
+ failover_ops);
+ if (ret)
+ goto done;
+
+ ret = netdev_rx_handler_register(slave_dev, failover_ops ?
+ failover_ops->handle_frame :
+ failover_handle_frame, failover_dev);
+ if (ret) {
+ netdev_err(slave_dev, "can not register failover rx handler (err = %d)\n",
+ ret);
+ goto done;
+ }
+
+ ret = netdev_upper_dev_link(slave_dev, failover_dev, NULL);
+ if (ret) {
+ netdev_err(slave_dev, "can not set failover device %s (err = %d)\n",
+ failover_dev->name, ret);
+ goto upper_link_failed;
+ }
+
+ slave_dev->priv_flags |= IFF_FAILOVER_SLAVE;
+
+ ret = failover_slave_join(slave_dev, failover_dev, failover_ops);
+ if (ret)
+ goto err_join;
+
+ call_netdevice_notifiers(NETDEV_JOIN, slave_dev);
+
+ netdev_info(failover_dev, "failover slave:%s registered\n",
+ slave_dev->name);
+
+ goto done;
+
+err_join:
+ netdev_upper_dev_unlink(slave_dev, failover_dev);
+ slave_dev->priv_flags &= ~IFF_FAILOVER_SLAVE;
+upper_link_failed:
+ netdev_rx_handler_unregister(slave_dev);
+done:
+ return NOTIFY_DONE;
+}
+
+static int failover_slave_pre_unregister(struct net_device *slave_dev,
+ struct net_device *failover_dev,
+ struct failover_ops *failover_ops)
+{
+ struct net_device *standby_dev, *primary_dev;
+ struct failover_info *finfo;
+
+ if (failover_ops) {
+ if (!failover_ops->slave_pre_unregister)
+ return -EINVAL;
+
+ return failover_ops->slave_pre_unregister(slave_dev,
+ failover_dev);
+ }
+
+ finfo = netdev_priv(failover_dev);
+ primary_dev = rtnl_dereference(finfo->primary_dev);
+ standby_dev = rtnl_dereference(finfo->standby_dev);
+
+ if (slave_dev != primary_dev && slave_dev != standby_dev)
+ return -EINVAL;
+
+ return 0;
+}
+
+static int failover_slave_release(struct net_device *slave_dev,
+ struct net_device *failover_dev,
+ struct failover_ops *failover_ops)
+{
+ struct net_device *standby_dev, *primary_dev;
+ struct failover_info *finfo;
+
+ if (failover_ops) {
+ if (!failover_ops->slave_release)
+ return -EINVAL;
+
+ return failover_ops->slave_release(slave_dev, failover_dev);
+ }
+
+ finfo = netdev_priv(failover_dev);
+ primary_dev = rtnl_dereference(finfo->primary_dev);
+ standby_dev = rtnl_dereference(finfo->standby_dev);
+
+ if (slave_dev == standby_dev) {
+ RCU_INIT_POINTER(finfo->standby_dev, NULL);
+ } else {
+ RCU_INIT_POINTER(finfo->primary_dev, NULL);
+ if (standby_dev) {
+ failover_dev->min_mtu = standby_dev->min_mtu;
+ failover_dev->max_mtu = standby_dev->max_mtu;
+ }
+ }
+
+ dev_put(slave_dev);
+
+ netdev_info(failover_dev, "failover slave:%s released\n",
+ slave_dev->name);
+
+ return 0;
+}
+
+int failover_slave_unregister(struct net_device *slave_dev)
+{
+ struct failover_ops *failover_ops;
+ struct net_device *failover_dev;
+ int ret;
+
+ if (!netif_is_failover_slave(slave_dev))
+ goto done;
+
+ ASSERT_RTNL();
+
+ failover_dev = failover_get_bymac(slave_dev->perm_addr, &failover_ops);
+ if (!failover_dev)
+ goto done;
+
+ ret = failover_slave_pre_unregister(slave_dev, failover_dev,
+ failover_ops);
+ if (ret)
+ goto done;
+
+ netdev_rx_handler_unregister(slave_dev);
+ netdev_upper_dev_unlink(slave_dev, failover_dev);
+ slave_dev->priv_flags &= ~IFF_FAILOVER_SLAVE;
+
+ failover_slave_release(slave_dev, failover_dev, failover_ops);
+
+ netdev_info(failover_dev, "failover slave:%s unregistered\n",
+ slave_dev->name);
+
+done:
+ return NOTIFY_DONE;
+}
+EXPORT_SYMBOL_GPL(failover_slave_unregister);
+
+static bool failover_xmit_ready(struct net_device *dev)
+{
+ return netif_running(dev) && netif_carrier_ok(dev);
+}
+
+static int failover_slave_link_change(struct net_device *slave_dev)
+{
+ struct net_device *failover_dev, *primary_dev, *standby_dev;
+ struct failover_ops *failover_ops;
+ struct failover_info *finfo;
+
+ if (!netif_is_failover_slave(slave_dev))
+ goto done;
+
+ ASSERT_RTNL();
+
+ failover_dev = failover_get_bymac(slave_dev->perm_addr, &failover_ops);
+ if (!failover_dev)
+ goto done;
+
+ if (failover_ops) {
+ if (!failover_ops->slave_link_change)
+ goto done;
+
+ return failover_ops->slave_link_change(slave_dev, failover_dev);
+ }
+
+ if (!netif_running(failover_dev))
+ return 0;
+
+ finfo = netdev_priv(failover_dev);
+
+ primary_dev = rtnl_dereference(finfo->primary_dev);
+ standby_dev = rtnl_dereference(finfo->standby_dev);
+
+ if (slave_dev != primary_dev && slave_dev != standby_dev)
+ goto done;
+
+ if ((primary_dev && failover_xmit_ready(primary_dev)) ||
+ (standby_dev && failover_xmit_ready(standby_dev))) {
+ netif_carrier_on(failover_dev);
+ netif_tx_wake_all_queues(failover_dev);
+ } else {
+ netif_carrier_off(failover_dev);
+ netif_tx_stop_all_queues(failover_dev);
+ }
+
+done:
+ return NOTIFY_DONE;
+}
+
+static bool failover_validate_event_dev(struct net_device *dev)
+{
+ /* Skip parent events */
+ if (netif_is_failover(dev))
+ return false;
+
+ /* Avoid non-Ethernet type devices */
+ if (dev->type != ARPHRD_ETHER)
+ return false;
+
+ return true;
+}
+
+static int
+failover_event(struct notifier_block *this, unsigned long event, void *ptr)
+{
+ struct net_device *event_dev = netdev_notifier_info_to_dev(ptr);
+
+ if (!failover_validate_event_dev(event_dev))
+ return NOTIFY_DONE;
+
+ switch (event) {
+ case NETDEV_REGISTER:
+ return failover_slave_register(event_dev);
+ case NETDEV_UNREGISTER:
+ return failover_slave_unregister(event_dev);
+ case NETDEV_UP:
+ case NETDEV_DOWN:
+ case NETDEV_CHANGE:
+ return failover_slave_link_change(event_dev);
+ default:
+ return NOTIFY_DONE;
+ }
+}
+
+static struct notifier_block failover_notifier = {
+ .notifier_call = failover_event,
+};
+
+static int failover_open(struct net_device *dev)
+{
+ struct failover_info *finfo = netdev_priv(dev);
+ struct net_device *primary_dev, *standby_dev;
+ int err;
+
+ netif_carrier_off(dev);
+ netif_tx_wake_all_queues(dev);
+
+ primary_dev = rtnl_dereference(finfo->primary_dev);
+ if (primary_dev) {
+ err = dev_open(primary_dev);
+ if (err)
+ goto err_primary_open;
+ }
+
+ standby_dev = rtnl_dereference(finfo->standby_dev);
+ if (standby_dev) {
+ err = dev_open(standby_dev);
+ if (err)
+ goto err_standby_open;
+ }
+
+ return 0;
+
+err_standby_open:
+ dev_close(primary_dev);
+err_primary_open:
+ netif_tx_disable(dev);
+ return err;
+}
+
+static int failover_close(struct net_device *dev)
+{
+ struct failover_info *finfo = netdev_priv(dev);
+ struct net_device *slave_dev;
+
+ netif_tx_disable(dev);
+
+ slave_dev = rtnl_dereference(finfo->primary_dev);
+ if (slave_dev)
+ dev_close(slave_dev);
+
+ slave_dev = rtnl_dereference(finfo->standby_dev);
+ if (slave_dev)
+ dev_close(slave_dev);
+
+ return 0;
+}
+
+static netdev_tx_t failover_drop_xmit(struct sk_buff *skb,
+ struct net_device *dev)
+{
+ atomic_long_inc(&dev->tx_dropped);
+ dev_kfree_skb_any(skb);
+ return NETDEV_TX_OK;
+}
+
+static netdev_tx_t failover_start_xmit(struct sk_buff *skb,
+ struct net_device *dev)
+{
+ struct failover_info *finfo = netdev_priv(dev);
+ struct net_device *xmit_dev;
+
+ /* Try xmit via primary netdev followed by standby netdev */
+ xmit_dev = rcu_dereference_bh(finfo->primary_dev);
+ if (!xmit_dev || !failover_xmit_ready(xmit_dev)) {
+ xmit_dev = rcu_dereference_bh(finfo->standby_dev);
+ if (!xmit_dev || !failover_xmit_ready(xmit_dev))
+ return failover_drop_xmit(skb, dev);
+ }
+
+ skb->dev = xmit_dev;
+ skb->queue_mapping = qdisc_skb_cb(skb)->slave_dev_queue_mapping;
+
+ return dev_queue_xmit(skb);
+}
+
+static u16 failover_select_queue(struct net_device *dev, struct sk_buff *skb,
+ void *accel_priv,
+ select_queue_fallback_t fallback)
+{
+ struct failover_info *finfo = netdev_priv(dev);
+ struct net_device *primary_dev;
+ u16 txq;
+
+ rcu_read_lock();
+ primary_dev = rcu_dereference(finfo->primary_dev);
+ if (primary_dev) {
+ const struct net_device_ops *ops = primary_dev->netdev_ops;
+
+ if (ops->ndo_select_queue)
+ txq = ops->ndo_select_queue(primary_dev, skb,
+ accel_priv, fallback);
+ else
+ txq = fallback(primary_dev, skb);
+
+ qdisc_skb_cb(skb)->slave_dev_queue_mapping = skb->queue_mapping;
+
+ return txq;
+ }
+
+ txq = skb_rx_queue_recorded(skb) ? skb_get_rx_queue(skb) : 0;
+
+ /* Save the original txq to restore before passing to the driver */
+ qdisc_skb_cb(skb)->slave_dev_queue_mapping = skb->queue_mapping;
+
+ if (unlikely(txq >= dev->real_num_tx_queues)) {
+ do {
+ txq -= dev->real_num_tx_queues;
+ } while (txq >= dev->real_num_tx_queues);
+ }
+
+ return txq;
+}
+
+/* fold stats, assuming all rtnl_link_stats64 fields are u64, but
+ * that some drivers can provide 32finfot values only.
+ */
+static void failover_fold_stats(struct rtnl_link_stats64 *_res,
+ const struct rtnl_link_stats64 *_new,
+ const struct rtnl_link_stats64 *_old)
+{
+ const u64 *new = (const u64 *)_new;
+ const u64 *old = (const u64 *)_old;
+ u64 *res = (u64 *)_res;
+ int i;
+
+ for (i = 0; i < sizeof(*_res) / sizeof(u64); i++) {
+ u64 nv = new[i];
+ u64 ov = old[i];
+ s64 delta = nv - ov;
+
+ /* detects if this particular field is 32bit only */
+ if (((nv | ov) >> 32) == 0)
+ delta = (s64)(s32)((u32)nv - (u32)ov);
+
+ /* filter anomalies, some drivers reset their stats
+ * at down/up events.
+ */
+ if (delta > 0)
+ res[i] += delta;
+ }
+}
+
+static void failover_get_stats(struct net_device *dev,
+ struct rtnl_link_stats64 *stats)
+{
+ struct failover_info *finfo = netdev_priv(dev);
+ const struct rtnl_link_stats64 *new;
+ struct rtnl_link_stats64 temp;
+ struct net_device *slave_dev;
+
+ spin_lock(&finfo->stats_lock);
+ memcpy(stats, &finfo->failover_stats, sizeof(*stats));
+
+ rcu_read_lock();
+
+ slave_dev = rcu_dereference(finfo->primary_dev);
+ if (slave_dev) {
+ new = dev_get_stats(slave_dev, &temp);
+ failover_fold_stats(stats, new, &finfo->primary_stats);
+ memcpy(&finfo->primary_stats, new, sizeof(*new));
+ }
+
+ slave_dev = rcu_dereference(finfo->standby_dev);
+ if (slave_dev) {
+ new = dev_get_stats(slave_dev, &temp);
+ failover_fold_stats(stats, new, &finfo->standby_stats);
+ memcpy(&finfo->standby_stats, new, sizeof(*new));
+ }
+
+ rcu_read_unlock();
+
+ memcpy(&finfo->failover_stats, stats, sizeof(*stats));
+ spin_unlock(&finfo->stats_lock);
+}
+
+static int failover_change_mtu(struct net_device *dev, int new_mtu)
+{
+ struct failover_info *finfo = netdev_priv(dev);
+ struct net_device *primary_dev, *standby_dev;
+ int ret = 0;
+
+ primary_dev = rcu_dereference(finfo->primary_dev);
+ if (primary_dev) {
+ ret = dev_set_mtu(primary_dev, new_mtu);
+ if (ret)
+ return ret;
+ }
+
+ standby_dev = rcu_dereference(finfo->standby_dev);
+ if (standby_dev) {
+ ret = dev_set_mtu(standby_dev, new_mtu);
+ if (ret) {
+ dev_set_mtu(primary_dev, dev->mtu);
+ return ret;
+ }
+ }
+
+ dev->mtu = new_mtu;
+ return 0;
+}
+
+static void failover_set_rx_mode(struct net_device *dev)
+{
+ struct failover_info *finfo = netdev_priv(dev);
+ struct net_device *slave_dev;
+
+ rcu_read_lock();
+
+ slave_dev = rcu_dereference(finfo->primary_dev);
+ if (slave_dev) {
+ dev_uc_sync_multiple(slave_dev, dev);
+ dev_mc_sync_multiple(slave_dev, dev);
+ }
+
+ slave_dev = rcu_dereference(finfo->standby_dev);
+ if (slave_dev) {
+ dev_uc_sync_multiple(slave_dev, dev);
+ dev_mc_sync_multiple(slave_dev, dev);
+ }
+
+ rcu_read_unlock();
+}
+
+static const struct net_device_ops failover_dev_ops = {
+ .ndo_open = failover_open,
+ .ndo_stop = failover_close,
+ .ndo_start_xmit = failover_start_xmit,
+ .ndo_select_queue = failover_select_queue,
+ .ndo_get_stats64 = failover_get_stats,
+ .ndo_change_mtu = failover_change_mtu,
+ .ndo_set_rx_mode = failover_set_rx_mode,
+ .ndo_validate_addr = eth_validate_addr,
+ .ndo_features_check = passthru_features_check,
+};
+
+#define FAILOVER_NAME "failover"
+#define FAILOVER_VERSION "0.1"
+
+static void failover_ethtool_get_drvinfo(struct net_device *dev,
+ struct ethtool_drvinfo *drvinfo)
+{
+ strlcpy(drvinfo->driver, FAILOVER_NAME, sizeof(drvinfo->driver));
+ strlcpy(drvinfo->version, FAILOVER_VERSION, sizeof(drvinfo->version));
+}
+
+int failover_ethtool_get_link_ksettings(struct net_device *dev,
+ struct ethtool_link_ksettings *cmd)
+{
+ struct failover_info *finfo = netdev_priv(dev);
+ struct net_device *slave_dev;
+
+ slave_dev = rtnl_dereference(finfo->primary_dev);
+ if (!slave_dev || !failover_xmit_ready(slave_dev)) {
+ slave_dev = rtnl_dereference(finfo->standby_dev);
+ if (!slave_dev || !failover_xmit_ready(slave_dev)) {
+ cmd->base.duplex = DUPLEX_UNKNOWN;
+ cmd->base.port = PORT_OTHER;
+ cmd->base.speed = SPEED_UNKNOWN;
+
+ return 0;
+ }
+ }
+
+ return __ethtool_get_link_ksettings(slave_dev, cmd);
+}
+EXPORT_SYMBOL_GPL(failover_ethtool_get_link_ksettings);
+
+static const struct ethtool_ops failover_ethtool_ops = {
+ .get_drvinfo = failover_ethtool_get_drvinfo,
+ .get_link = ethtool_op_get_link,
+ .get_link_ksettings = failover_ethtool_get_link_ksettings,
+};
+
+static void failover_register_existing_slave(struct net_device *failover_dev)
+{
+ struct net *net = dev_net(failover_dev);
+ struct net_device *dev;
+
+ rtnl_lock();
+ for_each_netdev(net, dev) {
+ if (dev == failover_dev)
+ continue;
+ if (!failover_validate_event_dev(dev))
+ continue;
+ if (ether_addr_equal(failover_dev->perm_addr, dev->perm_addr))
+ failover_slave_register(dev);
+ }
+ rtnl_unlock();
+}
+
+int failover_register(struct net_device *dev, struct failover_ops *ops,
+ struct failover **pfailover)
+{
+ struct failover *failover;
+
+ failover = kzalloc(sizeof(*failover), GFP_KERNEL);
+ if (!failover)
+ return -ENOMEM;
+
+ rcu_assign_pointer(failover->ops, ops);
+ dev_hold(dev);
+ dev->priv_flags |= IFF_FAILOVER;
+ rcu_assign_pointer(failover->failover_dev, dev);
+
+ spin_lock(&failover_lock);
+ list_add_tail(&failover->list, &failover_list);
+ spin_unlock(&failover_lock);
+
+ failover_register_existing_slave(dev);
+
+ *pfailover = failover;
+ return 0;
+}
+EXPORT_SYMBOL_GPL(failover_register);
+
+void failover_unregister(struct failover *failover)
+{
+ struct net_device *failover_dev;
+
+ failover_dev = rcu_dereference(failover->failover_dev);
+
+ failover_dev->priv_flags &= ~IFF_FAILOVER;
+ dev_put(failover_dev);
+
+ spin_lock(&failover_lock);
+ list_del(&failover->list);
+ spin_unlock(&failover_lock);
+
+ kfree(failover);
+}
+EXPORT_SYMBOL_GPL(failover_unregister);
+
+int failover_create(struct net_device *standby_dev, struct failover **pfailover)
+{
+ struct device *dev = standby_dev->dev.parent;
+ struct net_device *failover_dev;
+ int err;
+
+ /* Alloc at least 2 queues, for now we are going with 16 assuming
+ * that most devices being bonded won't have too many queues.
+ */
+ failover_dev = alloc_etherdev_mq(sizeof(struct failover_info), 16);
+ if (!failover_dev) {
+ dev_err(dev, "Unable to allocate failover_netdev!\n");
+ return -ENOMEM;
+ }
+
+ dev_net_set(failover_dev, dev_net(standby_dev));
+ SET_NETDEV_DEV(failover_dev, dev);
+
+ failover_dev->netdev_ops = &failover_dev_ops;
+ failover_dev->ethtool_ops = &failover_ethtool_ops;
+
+ /* Initialize the device options */
+ failover_dev->priv_flags |= IFF_UNICAST_FLT | IFF_NO_QUEUE;
+ failover_dev->priv_flags &= ~(IFF_XMIT_DST_RELEASE |
+ IFF_TX_SKB_SHARING);
+
+ /* don't acquire failover netdev's netif_tx_lock when transmitting */
+ failover_dev->features |= NETIF_F_LLTX;
+
+ /* Don't allow failover devices to change network namespaces. */
+ failover_dev->features |= NETIF_F_NETNS_LOCAL;
+
+ failover_dev->hw_features = NETIF_F_HW_CSUM | NETIF_F_SG |
+ NETIF_F_FRAGLIST | NETIF_F_ALL_TSO |
+ NETIF_F_HIGHDMA | NETIF_F_LRO;
+
+ failover_dev->hw_features |= NETIF_F_GSO_ENCAP_ALL;
+ failover_dev->features |= failover_dev->hw_features;
+
+ memcpy(failover_dev->dev_addr, standby_dev->dev_addr,
+ failover_dev->addr_len);
+
+ failover_dev->min_mtu = standby_dev->min_mtu;
+ failover_dev->max_mtu = standby_dev->max_mtu;
+
+ err = register_netdev(failover_dev);
+ if (err < 0) {
+ dev_err(dev, "Unable to register failover_dev!\n");
+ goto err_register_netdev;
+ }
+
+ netif_carrier_off(failover_dev);
+
+ err = failover_register(failover_dev, NULL, pfailover);
+ if (err < 0)
+ goto err_failover;
+
+ return 0;
+
+err_failover:
+ unregister_netdev(failover_dev);
+err_register_netdev:
+ free_netdev(failover_dev);
+
+ return err;
+}
+EXPORT_SYMBOL_GPL(failover_create);
+
+void failover_destroy(struct failover *failover)
+{
+ struct net_device *failover_dev;
+ struct net_device *slave_dev;
+ struct failover_info *finfo;
+
+ if (!failover)
+ return;
+
+ failover_dev = rcu_dereference(failover->failover_dev);
+ finfo = netdev_priv(failover_dev);
+
+ netif_device_detach(failover_dev);
+
+ rtnl_lock();
+
+ slave_dev = rtnl_dereference(finfo->primary_dev);
+ if (slave_dev)
+ failover_slave_unregister(slave_dev);
+
+ slave_dev = rtnl_dereference(finfo->standby_dev);
+ if (slave_dev)
+ failover_slave_unregister(slave_dev);
+
+ failover_unregister(failover);
+
+ unregister_netdevice(failover_dev);
+
+ rtnl_unlock();
+
+ free_netdev(failover_dev);
+}
+EXPORT_SYMBOL_GPL(failover_destroy);
+
+static __init int
+failover_init(void)
+{
+ register_netdevice_notifier(&failover_notifier);
+
+ return 0;
+}
+module_init(failover_init);
+
+static __exit
+void failover_exit(void)
+{
+ unregister_netdevice_notifier(&failover_notifier);
+}
+module_exit(failover_exit);
+
+MODULE_DESCRIPTION("Failover infrastructure/interface for Paravirtual drivers");
+MODULE_LICENSE("GPL v2");
--
2.14.3
^ permalink raw reply related [flat|nested] 114+ messages in thread
* [PATCH v7 net-next 2/4] net: Introduce generic failover module
2018-04-20 1:42 ` [virtio-dev] " Sridhar Samudrala
` (2 preceding siblings ...)
(?)
@ 2018-04-20 1:42 ` Sridhar Samudrala
-1 siblings, 0 replies; 114+ messages in thread
From: Sridhar Samudrala @ 2018-04-20 1:42 UTC (permalink / raw)
To: mst, stephen, davem, netdev, virtualization, virtio-dev,
jesse.brandeburg, alexander.h.duyck, kubakici, sridhar.samudrala,
jasowang, loseweigh, jiri
This provides a generic interface for paravirtual drivers to listen
for netdev register/unregister/link change events from pci ethernet
devices with the same MAC and takeover their datapath. The notifier and
event handling code is based on the existing netvsc implementation.
It exposes 2 sets of interfaces to the paravirtual drivers.
1. existing netvsc driver that uses 2 netdev model. In this model, no
master netdev is created. The paravirtual driver registers each instance
of netvsc as a 'failover' instance along with a set of ops to manage the
slave events.
failover_register()
failover_unregister()
2. new virtio_net based solution that uses 3 netdev model. In this model,
the failover module provides interfaces to create/destroy additional master
netdev and all the slave events are managed internally.
failover_create()
failover_destroy()
These functions call failover_register()/failover_unregister() with the
master netdev created by the failover module.
Signed-off-by: Sridhar Samudrala <sridhar.samudrala@intel.com>
---
include/linux/netdevice.h | 16 +
include/net/failover.h | 96 ++++++
net/Kconfig | 18 +
net/core/Makefile | 1 +
net/core/failover.c | 844 ++++++++++++++++++++++++++++++++++++++++++++++
5 files changed, 975 insertions(+)
create mode 100644 include/net/failover.h
create mode 100644 net/core/failover.c
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index cf44503ea81a..ed535b6724e1 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -1401,6 +1401,8 @@ struct net_device_ops {
* entity (i.e. the master device for bridged veth)
* @IFF_MACSEC: device is a MACsec device
* @IFF_NO_RX_HANDLER: device doesn't support the rx_handler hook
+ * @IFF_FAILOVER: device is a failover master device
+ * @IFF_FAILOVER_SLAVE: device is lower dev of a failover master device
*/
enum netdev_priv_flags {
IFF_802_1Q_VLAN = 1<<0,
@@ -1430,6 +1432,8 @@ enum netdev_priv_flags {
IFF_PHONY_HEADROOM = 1<<24,
IFF_MACSEC = 1<<25,
IFF_NO_RX_HANDLER = 1<<26,
+ IFF_FAILOVER = 1<<27,
+ IFF_FAILOVER_SLAVE = 1<<28,
};
#define IFF_802_1Q_VLAN IFF_802_1Q_VLAN
@@ -1458,6 +1462,8 @@ enum netdev_priv_flags {
#define IFF_RXFH_CONFIGURED IFF_RXFH_CONFIGURED
#define IFF_MACSEC IFF_MACSEC
#define IFF_NO_RX_HANDLER IFF_NO_RX_HANDLER
+#define IFF_FAILOVER IFF_FAILOVER
+#define IFF_FAILOVER_SLAVE IFF_FAILOVER_SLAVE
/**
* struct net_device - The DEVICE structure.
@@ -4308,6 +4314,16 @@ static inline bool netif_is_rxfh_configured(const struct net_device *dev)
return dev->priv_flags & IFF_RXFH_CONFIGURED;
}
+static inline bool netif_is_failover(const struct net_device *dev)
+{
+ return dev->priv_flags & IFF_FAILOVER;
+}
+
+static inline bool netif_is_failover_slave(const struct net_device *dev)
+{
+ return dev->priv_flags & IFF_FAILOVER_SLAVE;
+}
+
/* This device needs to keep skb dst for qdisc enqueue or ndo_start_xmit() */
static inline void netif_keep_dst(struct net_device *dev)
{
diff --git a/include/net/failover.h b/include/net/failover.h
new file mode 100644
index 000000000000..0b8601043d90
--- /dev/null
+++ b/include/net/failover.h
@@ -0,0 +1,96 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/* Copyright (c) 2018, Intel Corporation. */
+
+#ifndef _NET_FAILOVER_H
+#define _NET_FAILOVER_H
+
+#include <linux/netdevice.h>
+
+struct failover_ops {
+ int (*slave_pre_register)(struct net_device *slave_dev,
+ struct net_device *failover_dev);
+ int (*slave_join)(struct net_device *slave_dev,
+ struct net_device *failover_dev);
+ int (*slave_pre_unregister)(struct net_device *slave_dev,
+ struct net_device *failover_dev);
+ int (*slave_release)(struct net_device *slave_dev,
+ struct net_device *failover_dev);
+ int (*slave_link_change)(struct net_device *slave_dev,
+ struct net_device *failover_dev);
+ rx_handler_result_t (*handle_frame)(struct sk_buff **pskb);
+};
+
+struct failover {
+ struct list_head list;
+ struct net_device __rcu *failover_dev;
+ struct failover_ops __rcu *ops;
+};
+
+/* failover state */
+struct failover_info {
+ /* primary netdev with same MAC */
+ struct net_device __rcu *primary_dev;
+
+ /* standby netdev */
+ struct net_device __rcu *standby_dev;
+
+ /* primary netdev stats */
+ struct rtnl_link_stats64 primary_stats;
+
+ /* standby netdev stats */
+ struct rtnl_link_stats64 standby_stats;
+
+ /* aggregated stats */
+ struct rtnl_link_stats64 failover_stats;
+
+ /* spinlock while updating stats */
+ spinlock_t stats_lock;
+};
+
+#if IS_ENABLED(CONFIG_NET_FAILOVER)
+
+int failover_create(struct net_device *standby_dev,
+ struct failover **pfailover);
+void failover_destroy(struct failover *failover);
+
+int failover_register(struct net_device *standby_dev, struct failover_ops *ops,
+ struct failover **pfailover);
+void failover_unregister(struct failover *failover);
+
+int failover_slave_unregister(struct net_device *slave_dev);
+
+#else
+
+static inline
+int failover_create(struct net_device *standby_dev,
+ struct failover **pfailover);
+{
+ return 0;
+}
+
+static inline
+void failover_destroy(struct failover *failover)
+{
+}
+
+static inline
+int failover_register(struct net_device *standby_dev, struct failover_ops *ops,
+ struct pfailover **pfailover);
+{
+ return 0;
+}
+
+static inline
+void failover_unregister(struct failover *failover)
+{
+}
+
+static inline
+int failover_slave_unregister(struct net_device *slave_dev)
+{
+ return 0;
+}
+
+#endif
+
+#endif /* _NET_FAILOVER_H */
diff --git a/net/Kconfig b/net/Kconfig
index 0428f12c25c2..388b99dfee10 100644
--- a/net/Kconfig
+++ b/net/Kconfig
@@ -423,6 +423,24 @@ config MAY_USE_DEVLINK
on MAY_USE_DEVLINK to ensure they do not cause link errors when
devlink is a loadable module and the driver using it is built-in.
+config NET_FAILOVER
+ tristate "Failover interface"
+ help
+ This provides a generic interface for paravirtual drivers to listen
+ for netdev register/unregister/link change events from pci ethernet
+ devices with the same MAC and takeover their datapath. This also
+ enables live migration of a VM with direct attached VF by failing
+ over to the paravirtual datapath when the VF is unplugged.
+
+config MAY_USE_FAILOVER
+ tristate
+ default m if NET_FAILOVER=m
+ default y if NET_FAILOVER=y || NET_FAILOVER=n
+ help
+ Drivers using the failover infrastructure should have a dependency
+ on MAY_USE_FAILOVER to ensure they do not cause link errors when
+ failover is a loadable module and the driver using it is built-in.
+
endif # if NET
# Used by archs to tell that they support BPF JIT compiler plus which flavour.
diff --git a/net/core/Makefile b/net/core/Makefile
index 6dbbba8c57ae..cef17518bb7d 100644
--- a/net/core/Makefile
+++ b/net/core/Makefile
@@ -30,3 +30,4 @@ obj-$(CONFIG_DST_CACHE) += dst_cache.o
obj-$(CONFIG_HWBM) += hwbm.o
obj-$(CONFIG_NET_DEVLINK) += devlink.o
obj-$(CONFIG_GRO_CELLS) += gro_cells.o
+obj-$(CONFIG_NET_FAILOVER) += failover.o
diff --git a/net/core/failover.c b/net/core/failover.c
new file mode 100644
index 000000000000..7bee762cb737
--- /dev/null
+++ b/net/core/failover.c
@@ -0,0 +1,844 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Copyright (c) 2018, Intel Corporation. */
+
+/* A common module to handle registrations and notifications for paravirtual
+ * drivers to enable accelerated datapath and support VF live migration.
+ *
+ * The notifier and event handling code is based on netvsc driver.
+ */
+
+#include <linux/netdevice.h>
+#include <linux/etherdevice.h>
+#include <linux/ethtool.h>
+#include <linux/module.h>
+#include <linux/slab.h>
+#include <linux/netdevice.h>
+#include <linux/netpoll.h>
+#include <linux/rtnetlink.h>
+#include <linux/if_vlan.h>
+#include <linux/pci.h>
+#include <net/sch_generic.h>
+#include <uapi/linux/if_arp.h>
+#include <net/failover.h>
+
+static LIST_HEAD(failover_list);
+static DEFINE_SPINLOCK(failover_lock);
+
+static int failover_slave_pre_register(struct net_device *slave_dev,
+ struct net_device *failover_dev,
+ struct failover_ops *failover_ops)
+{
+ struct failover_info *finfo;
+ bool standby;
+
+ if (failover_ops) {
+ if (!failover_ops->slave_pre_register)
+ return -EINVAL;
+
+ return failover_ops->slave_pre_register(slave_dev,
+ failover_dev);
+ }
+
+ finfo = netdev_priv(failover_dev);
+ standby = (slave_dev->dev.parent == failover_dev->dev.parent);
+ if (standby ? rtnl_dereference(finfo->standby_dev) :
+ rtnl_dereference(finfo->primary_dev)) {
+ netdev_err(failover_dev, "%s attempting to register as slave dev when %s already present\n",
+ slave_dev->name, standby ? "standby" : "primary");
+ return -EEXIST;
+ }
+
+ /* Avoid non pci devices as primary netdev */
+ if (!standby && (!slave_dev->dev.parent ||
+ !dev_is_pci(slave_dev->dev.parent)))
+ return -EINVAL;
+
+ return 0;
+}
+
+static int failover_slave_join(struct net_device *slave_dev,
+ struct net_device *failover_dev,
+ struct failover_ops *failover_ops)
+{
+ struct failover_info *finfo;
+ int err, orig_mtu;
+ bool standby;
+
+ if (failover_ops) {
+ if (!failover_ops->slave_join)
+ return -EINVAL;
+
+ return failover_ops->slave_join(slave_dev, failover_dev);
+ }
+
+ if (netif_running(failover_dev)) {
+ err = dev_open(slave_dev);
+ if (err && (err != -EBUSY)) {
+ netdev_err(failover_dev, "Opening slave %s failed err:%d\n",
+ slave_dev->name, err);
+ goto err_dev_open;
+ }
+ }
+
+ /* Align MTU of slave with failover dev */
+ orig_mtu = slave_dev->mtu;
+ err = dev_set_mtu(slave_dev, failover_dev->mtu);
+ if (err) {
+ netdev_err(failover_dev, "unable to change mtu of %s to %u register failed\n",
+ slave_dev->name, failover_dev->mtu);
+ goto err_set_mtu;
+ }
+
+ finfo = netdev_priv(failover_dev);
+ standby = (slave_dev->dev.parent == failover_dev->dev.parent);
+
+ dev_hold(slave_dev);
+
+ if (standby) {
+ rcu_assign_pointer(finfo->standby_dev, slave_dev);
+ dev_get_stats(finfo->standby_dev, &finfo->standby_stats);
+ } else {
+ rcu_assign_pointer(finfo->primary_dev, slave_dev);
+ dev_get_stats(finfo->primary_dev, &finfo->primary_stats);
+ failover_dev->min_mtu = slave_dev->min_mtu;
+ failover_dev->max_mtu = slave_dev->max_mtu;
+ }
+
+ netdev_info(failover_dev, "failover slave:%s joined\n",
+ slave_dev->name);
+
+ return 0;
+
+err_set_mtu:
+ dev_close(slave_dev);
+err_dev_open:
+ return err;
+}
+
+/* Called when slave dev is injecting data into network stack.
+ * Change the associated network device from lower dev to virtio.
+ * note: already called with rcu_read_lock
+ */
+static rx_handler_result_t failover_handle_frame(struct sk_buff **pskb)
+{
+ struct sk_buff *skb = *pskb;
+ struct net_device *ndev = rcu_dereference(skb->dev->rx_handler_data);
+
+ skb->dev = ndev;
+
+ return RX_HANDLER_ANOTHER;
+}
+
+static struct net_device *failover_get_bymac(u8 *mac, struct failover_ops **ops)
+{
+ struct net_device *failover_dev;
+ struct failover *failover;
+
+ spin_lock(&failover_lock);
+ list_for_each_entry(failover, &failover_list, list) {
+ failover_dev = rtnl_dereference(failover->failover_dev);
+ if (ether_addr_equal(failover_dev->perm_addr, mac)) {
+ *ops = rtnl_dereference(failover->ops);
+ spin_unlock(&failover_lock);
+ return failover_dev;
+ }
+ }
+ spin_unlock(&failover_lock);
+ return NULL;
+}
+
+static int failover_slave_register(struct net_device *slave_dev)
+{
+ struct failover_ops *failover_ops;
+ struct net_device *failover_dev;
+ int ret;
+
+ ASSERT_RTNL();
+
+ failover_dev = failover_get_bymac(slave_dev->perm_addr, &failover_ops);
+ if (!failover_dev)
+ goto done;
+
+ ret = failover_slave_pre_register(slave_dev, failover_dev,
+ failover_ops);
+ if (ret)
+ goto done;
+
+ ret = netdev_rx_handler_register(slave_dev, failover_ops ?
+ failover_ops->handle_frame :
+ failover_handle_frame, failover_dev);
+ if (ret) {
+ netdev_err(slave_dev, "can not register failover rx handler (err = %d)\n",
+ ret);
+ goto done;
+ }
+
+ ret = netdev_upper_dev_link(slave_dev, failover_dev, NULL);
+ if (ret) {
+ netdev_err(slave_dev, "can not set failover device %s (err = %d)\n",
+ failover_dev->name, ret);
+ goto upper_link_failed;
+ }
+
+ slave_dev->priv_flags |= IFF_FAILOVER_SLAVE;
+
+ ret = failover_slave_join(slave_dev, failover_dev, failover_ops);
+ if (ret)
+ goto err_join;
+
+ call_netdevice_notifiers(NETDEV_JOIN, slave_dev);
+
+ netdev_info(failover_dev, "failover slave:%s registered\n",
+ slave_dev->name);
+
+ goto done;
+
+err_join:
+ netdev_upper_dev_unlink(slave_dev, failover_dev);
+ slave_dev->priv_flags &= ~IFF_FAILOVER_SLAVE;
+upper_link_failed:
+ netdev_rx_handler_unregister(slave_dev);
+done:
+ return NOTIFY_DONE;
+}
+
+static int failover_slave_pre_unregister(struct net_device *slave_dev,
+ struct net_device *failover_dev,
+ struct failover_ops *failover_ops)
+{
+ struct net_device *standby_dev, *primary_dev;
+ struct failover_info *finfo;
+
+ if (failover_ops) {
+ if (!failover_ops->slave_pre_unregister)
+ return -EINVAL;
+
+ return failover_ops->slave_pre_unregister(slave_dev,
+ failover_dev);
+ }
+
+ finfo = netdev_priv(failover_dev);
+ primary_dev = rtnl_dereference(finfo->primary_dev);
+ standby_dev = rtnl_dereference(finfo->standby_dev);
+
+ if (slave_dev != primary_dev && slave_dev != standby_dev)
+ return -EINVAL;
+
+ return 0;
+}
+
+static int failover_slave_release(struct net_device *slave_dev,
+ struct net_device *failover_dev,
+ struct failover_ops *failover_ops)
+{
+ struct net_device *standby_dev, *primary_dev;
+ struct failover_info *finfo;
+
+ if (failover_ops) {
+ if (!failover_ops->slave_release)
+ return -EINVAL;
+
+ return failover_ops->slave_release(slave_dev, failover_dev);
+ }
+
+ finfo = netdev_priv(failover_dev);
+ primary_dev = rtnl_dereference(finfo->primary_dev);
+ standby_dev = rtnl_dereference(finfo->standby_dev);
+
+ if (slave_dev == standby_dev) {
+ RCU_INIT_POINTER(finfo->standby_dev, NULL);
+ } else {
+ RCU_INIT_POINTER(finfo->primary_dev, NULL);
+ if (standby_dev) {
+ failover_dev->min_mtu = standby_dev->min_mtu;
+ failover_dev->max_mtu = standby_dev->max_mtu;
+ }
+ }
+
+ dev_put(slave_dev);
+
+ netdev_info(failover_dev, "failover slave:%s released\n",
+ slave_dev->name);
+
+ return 0;
+}
+
+int failover_slave_unregister(struct net_device *slave_dev)
+{
+ struct failover_ops *failover_ops;
+ struct net_device *failover_dev;
+ int ret;
+
+ if (!netif_is_failover_slave(slave_dev))
+ goto done;
+
+ ASSERT_RTNL();
+
+ failover_dev = failover_get_bymac(slave_dev->perm_addr, &failover_ops);
+ if (!failover_dev)
+ goto done;
+
+ ret = failover_slave_pre_unregister(slave_dev, failover_dev,
+ failover_ops);
+ if (ret)
+ goto done;
+
+ netdev_rx_handler_unregister(slave_dev);
+ netdev_upper_dev_unlink(slave_dev, failover_dev);
+ slave_dev->priv_flags &= ~IFF_FAILOVER_SLAVE;
+
+ failover_slave_release(slave_dev, failover_dev, failover_ops);
+
+ netdev_info(failover_dev, "failover slave:%s unregistered\n",
+ slave_dev->name);
+
+done:
+ return NOTIFY_DONE;
+}
+EXPORT_SYMBOL_GPL(failover_slave_unregister);
+
+static bool failover_xmit_ready(struct net_device *dev)
+{
+ return netif_running(dev) && netif_carrier_ok(dev);
+}
+
+static int failover_slave_link_change(struct net_device *slave_dev)
+{
+ struct net_device *failover_dev, *primary_dev, *standby_dev;
+ struct failover_ops *failover_ops;
+ struct failover_info *finfo;
+
+ if (!netif_is_failover_slave(slave_dev))
+ goto done;
+
+ ASSERT_RTNL();
+
+ failover_dev = failover_get_bymac(slave_dev->perm_addr, &failover_ops);
+ if (!failover_dev)
+ goto done;
+
+ if (failover_ops) {
+ if (!failover_ops->slave_link_change)
+ goto done;
+
+ return failover_ops->slave_link_change(slave_dev, failover_dev);
+ }
+
+ if (!netif_running(failover_dev))
+ return 0;
+
+ finfo = netdev_priv(failover_dev);
+
+ primary_dev = rtnl_dereference(finfo->primary_dev);
+ standby_dev = rtnl_dereference(finfo->standby_dev);
+
+ if (slave_dev != primary_dev && slave_dev != standby_dev)
+ goto done;
+
+ if ((primary_dev && failover_xmit_ready(primary_dev)) ||
+ (standby_dev && failover_xmit_ready(standby_dev))) {
+ netif_carrier_on(failover_dev);
+ netif_tx_wake_all_queues(failover_dev);
+ } else {
+ netif_carrier_off(failover_dev);
+ netif_tx_stop_all_queues(failover_dev);
+ }
+
+done:
+ return NOTIFY_DONE;
+}
+
+static bool failover_validate_event_dev(struct net_device *dev)
+{
+ /* Skip parent events */
+ if (netif_is_failover(dev))
+ return false;
+
+ /* Avoid non-Ethernet type devices */
+ if (dev->type != ARPHRD_ETHER)
+ return false;
+
+ return true;
+}
+
+static int
+failover_event(struct notifier_block *this, unsigned long event, void *ptr)
+{
+ struct net_device *event_dev = netdev_notifier_info_to_dev(ptr);
+
+ if (!failover_validate_event_dev(event_dev))
+ return NOTIFY_DONE;
+
+ switch (event) {
+ case NETDEV_REGISTER:
+ return failover_slave_register(event_dev);
+ case NETDEV_UNREGISTER:
+ return failover_slave_unregister(event_dev);
+ case NETDEV_UP:
+ case NETDEV_DOWN:
+ case NETDEV_CHANGE:
+ return failover_slave_link_change(event_dev);
+ default:
+ return NOTIFY_DONE;
+ }
+}
+
+static struct notifier_block failover_notifier = {
+ .notifier_call = failover_event,
+};
+
+static int failover_open(struct net_device *dev)
+{
+ struct failover_info *finfo = netdev_priv(dev);
+ struct net_device *primary_dev, *standby_dev;
+ int err;
+
+ netif_carrier_off(dev);
+ netif_tx_wake_all_queues(dev);
+
+ primary_dev = rtnl_dereference(finfo->primary_dev);
+ if (primary_dev) {
+ err = dev_open(primary_dev);
+ if (err)
+ goto err_primary_open;
+ }
+
+ standby_dev = rtnl_dereference(finfo->standby_dev);
+ if (standby_dev) {
+ err = dev_open(standby_dev);
+ if (err)
+ goto err_standby_open;
+ }
+
+ return 0;
+
+err_standby_open:
+ dev_close(primary_dev);
+err_primary_open:
+ netif_tx_disable(dev);
+ return err;
+}
+
+static int failover_close(struct net_device *dev)
+{
+ struct failover_info *finfo = netdev_priv(dev);
+ struct net_device *slave_dev;
+
+ netif_tx_disable(dev);
+
+ slave_dev = rtnl_dereference(finfo->primary_dev);
+ if (slave_dev)
+ dev_close(slave_dev);
+
+ slave_dev = rtnl_dereference(finfo->standby_dev);
+ if (slave_dev)
+ dev_close(slave_dev);
+
+ return 0;
+}
+
+static netdev_tx_t failover_drop_xmit(struct sk_buff *skb,
+ struct net_device *dev)
+{
+ atomic_long_inc(&dev->tx_dropped);
+ dev_kfree_skb_any(skb);
+ return NETDEV_TX_OK;
+}
+
+static netdev_tx_t failover_start_xmit(struct sk_buff *skb,
+ struct net_device *dev)
+{
+ struct failover_info *finfo = netdev_priv(dev);
+ struct net_device *xmit_dev;
+
+ /* Try xmit via primary netdev followed by standby netdev */
+ xmit_dev = rcu_dereference_bh(finfo->primary_dev);
+ if (!xmit_dev || !failover_xmit_ready(xmit_dev)) {
+ xmit_dev = rcu_dereference_bh(finfo->standby_dev);
+ if (!xmit_dev || !failover_xmit_ready(xmit_dev))
+ return failover_drop_xmit(skb, dev);
+ }
+
+ skb->dev = xmit_dev;
+ skb->queue_mapping = qdisc_skb_cb(skb)->slave_dev_queue_mapping;
+
+ return dev_queue_xmit(skb);
+}
+
+static u16 failover_select_queue(struct net_device *dev, struct sk_buff *skb,
+ void *accel_priv,
+ select_queue_fallback_t fallback)
+{
+ struct failover_info *finfo = netdev_priv(dev);
+ struct net_device *primary_dev;
+ u16 txq;
+
+ rcu_read_lock();
+ primary_dev = rcu_dereference(finfo->primary_dev);
+ if (primary_dev) {
+ const struct net_device_ops *ops = primary_dev->netdev_ops;
+
+ if (ops->ndo_select_queue)
+ txq = ops->ndo_select_queue(primary_dev, skb,
+ accel_priv, fallback);
+ else
+ txq = fallback(primary_dev, skb);
+
+ qdisc_skb_cb(skb)->slave_dev_queue_mapping = skb->queue_mapping;
+
+ return txq;
+ }
+
+ txq = skb_rx_queue_recorded(skb) ? skb_get_rx_queue(skb) : 0;
+
+ /* Save the original txq to restore before passing to the driver */
+ qdisc_skb_cb(skb)->slave_dev_queue_mapping = skb->queue_mapping;
+
+ if (unlikely(txq >= dev->real_num_tx_queues)) {
+ do {
+ txq -= dev->real_num_tx_queues;
+ } while (txq >= dev->real_num_tx_queues);
+ }
+
+ return txq;
+}
+
+/* fold stats, assuming all rtnl_link_stats64 fields are u64, but
+ * that some drivers can provide 32finfot values only.
+ */
+static void failover_fold_stats(struct rtnl_link_stats64 *_res,
+ const struct rtnl_link_stats64 *_new,
+ const struct rtnl_link_stats64 *_old)
+{
+ const u64 *new = (const u64 *)_new;
+ const u64 *old = (const u64 *)_old;
+ u64 *res = (u64 *)_res;
+ int i;
+
+ for (i = 0; i < sizeof(*_res) / sizeof(u64); i++) {
+ u64 nv = new[i];
+ u64 ov = old[i];
+ s64 delta = nv - ov;
+
+ /* detects if this particular field is 32bit only */
+ if (((nv | ov) >> 32) == 0)
+ delta = (s64)(s32)((u32)nv - (u32)ov);
+
+ /* filter anomalies, some drivers reset their stats
+ * at down/up events.
+ */
+ if (delta > 0)
+ res[i] += delta;
+ }
+}
+
+static void failover_get_stats(struct net_device *dev,
+ struct rtnl_link_stats64 *stats)
+{
+ struct failover_info *finfo = netdev_priv(dev);
+ const struct rtnl_link_stats64 *new;
+ struct rtnl_link_stats64 temp;
+ struct net_device *slave_dev;
+
+ spin_lock(&finfo->stats_lock);
+ memcpy(stats, &finfo->failover_stats, sizeof(*stats));
+
+ rcu_read_lock();
+
+ slave_dev = rcu_dereference(finfo->primary_dev);
+ if (slave_dev) {
+ new = dev_get_stats(slave_dev, &temp);
+ failover_fold_stats(stats, new, &finfo->primary_stats);
+ memcpy(&finfo->primary_stats, new, sizeof(*new));
+ }
+
+ slave_dev = rcu_dereference(finfo->standby_dev);
+ if (slave_dev) {
+ new = dev_get_stats(slave_dev, &temp);
+ failover_fold_stats(stats, new, &finfo->standby_stats);
+ memcpy(&finfo->standby_stats, new, sizeof(*new));
+ }
+
+ rcu_read_unlock();
+
+ memcpy(&finfo->failover_stats, stats, sizeof(*stats));
+ spin_unlock(&finfo->stats_lock);
+}
+
+static int failover_change_mtu(struct net_device *dev, int new_mtu)
+{
+ struct failover_info *finfo = netdev_priv(dev);
+ struct net_device *primary_dev, *standby_dev;
+ int ret = 0;
+
+ primary_dev = rcu_dereference(finfo->primary_dev);
+ if (primary_dev) {
+ ret = dev_set_mtu(primary_dev, new_mtu);
+ if (ret)
+ return ret;
+ }
+
+ standby_dev = rcu_dereference(finfo->standby_dev);
+ if (standby_dev) {
+ ret = dev_set_mtu(standby_dev, new_mtu);
+ if (ret) {
+ dev_set_mtu(primary_dev, dev->mtu);
+ return ret;
+ }
+ }
+
+ dev->mtu = new_mtu;
+ return 0;
+}
+
+static void failover_set_rx_mode(struct net_device *dev)
+{
+ struct failover_info *finfo = netdev_priv(dev);
+ struct net_device *slave_dev;
+
+ rcu_read_lock();
+
+ slave_dev = rcu_dereference(finfo->primary_dev);
+ if (slave_dev) {
+ dev_uc_sync_multiple(slave_dev, dev);
+ dev_mc_sync_multiple(slave_dev, dev);
+ }
+
+ slave_dev = rcu_dereference(finfo->standby_dev);
+ if (slave_dev) {
+ dev_uc_sync_multiple(slave_dev, dev);
+ dev_mc_sync_multiple(slave_dev, dev);
+ }
+
+ rcu_read_unlock();
+}
+
+static const struct net_device_ops failover_dev_ops = {
+ .ndo_open = failover_open,
+ .ndo_stop = failover_close,
+ .ndo_start_xmit = failover_start_xmit,
+ .ndo_select_queue = failover_select_queue,
+ .ndo_get_stats64 = failover_get_stats,
+ .ndo_change_mtu = failover_change_mtu,
+ .ndo_set_rx_mode = failover_set_rx_mode,
+ .ndo_validate_addr = eth_validate_addr,
+ .ndo_features_check = passthru_features_check,
+};
+
+#define FAILOVER_NAME "failover"
+#define FAILOVER_VERSION "0.1"
+
+static void failover_ethtool_get_drvinfo(struct net_device *dev,
+ struct ethtool_drvinfo *drvinfo)
+{
+ strlcpy(drvinfo->driver, FAILOVER_NAME, sizeof(drvinfo->driver));
+ strlcpy(drvinfo->version, FAILOVER_VERSION, sizeof(drvinfo->version));
+}
+
+int failover_ethtool_get_link_ksettings(struct net_device *dev,
+ struct ethtool_link_ksettings *cmd)
+{
+ struct failover_info *finfo = netdev_priv(dev);
+ struct net_device *slave_dev;
+
+ slave_dev = rtnl_dereference(finfo->primary_dev);
+ if (!slave_dev || !failover_xmit_ready(slave_dev)) {
+ slave_dev = rtnl_dereference(finfo->standby_dev);
+ if (!slave_dev || !failover_xmit_ready(slave_dev)) {
+ cmd->base.duplex = DUPLEX_UNKNOWN;
+ cmd->base.port = PORT_OTHER;
+ cmd->base.speed = SPEED_UNKNOWN;
+
+ return 0;
+ }
+ }
+
+ return __ethtool_get_link_ksettings(slave_dev, cmd);
+}
+EXPORT_SYMBOL_GPL(failover_ethtool_get_link_ksettings);
+
+static const struct ethtool_ops failover_ethtool_ops = {
+ .get_drvinfo = failover_ethtool_get_drvinfo,
+ .get_link = ethtool_op_get_link,
+ .get_link_ksettings = failover_ethtool_get_link_ksettings,
+};
+
+static void failover_register_existing_slave(struct net_device *failover_dev)
+{
+ struct net *net = dev_net(failover_dev);
+ struct net_device *dev;
+
+ rtnl_lock();
+ for_each_netdev(net, dev) {
+ if (dev == failover_dev)
+ continue;
+ if (!failover_validate_event_dev(dev))
+ continue;
+ if (ether_addr_equal(failover_dev->perm_addr, dev->perm_addr))
+ failover_slave_register(dev);
+ }
+ rtnl_unlock();
+}
+
+int failover_register(struct net_device *dev, struct failover_ops *ops,
+ struct failover **pfailover)
+{
+ struct failover *failover;
+
+ failover = kzalloc(sizeof(*failover), GFP_KERNEL);
+ if (!failover)
+ return -ENOMEM;
+
+ rcu_assign_pointer(failover->ops, ops);
+ dev_hold(dev);
+ dev->priv_flags |= IFF_FAILOVER;
+ rcu_assign_pointer(failover->failover_dev, dev);
+
+ spin_lock(&failover_lock);
+ list_add_tail(&failover->list, &failover_list);
+ spin_unlock(&failover_lock);
+
+ failover_register_existing_slave(dev);
+
+ *pfailover = failover;
+ return 0;
+}
+EXPORT_SYMBOL_GPL(failover_register);
+
+void failover_unregister(struct failover *failover)
+{
+ struct net_device *failover_dev;
+
+ failover_dev = rcu_dereference(failover->failover_dev);
+
+ failover_dev->priv_flags &= ~IFF_FAILOVER;
+ dev_put(failover_dev);
+
+ spin_lock(&failover_lock);
+ list_del(&failover->list);
+ spin_unlock(&failover_lock);
+
+ kfree(failover);
+}
+EXPORT_SYMBOL_GPL(failover_unregister);
+
+int failover_create(struct net_device *standby_dev, struct failover **pfailover)
+{
+ struct device *dev = standby_dev->dev.parent;
+ struct net_device *failover_dev;
+ int err;
+
+ /* Alloc at least 2 queues, for now we are going with 16 assuming
+ * that most devices being bonded won't have too many queues.
+ */
+ failover_dev = alloc_etherdev_mq(sizeof(struct failover_info), 16);
+ if (!failover_dev) {
+ dev_err(dev, "Unable to allocate failover_netdev!\n");
+ return -ENOMEM;
+ }
+
+ dev_net_set(failover_dev, dev_net(standby_dev));
+ SET_NETDEV_DEV(failover_dev, dev);
+
+ failover_dev->netdev_ops = &failover_dev_ops;
+ failover_dev->ethtool_ops = &failover_ethtool_ops;
+
+ /* Initialize the device options */
+ failover_dev->priv_flags |= IFF_UNICAST_FLT | IFF_NO_QUEUE;
+ failover_dev->priv_flags &= ~(IFF_XMIT_DST_RELEASE |
+ IFF_TX_SKB_SHARING);
+
+ /* don't acquire failover netdev's netif_tx_lock when transmitting */
+ failover_dev->features |= NETIF_F_LLTX;
+
+ /* Don't allow failover devices to change network namespaces. */
+ failover_dev->features |= NETIF_F_NETNS_LOCAL;
+
+ failover_dev->hw_features = NETIF_F_HW_CSUM | NETIF_F_SG |
+ NETIF_F_FRAGLIST | NETIF_F_ALL_TSO |
+ NETIF_F_HIGHDMA | NETIF_F_LRO;
+
+ failover_dev->hw_features |= NETIF_F_GSO_ENCAP_ALL;
+ failover_dev->features |= failover_dev->hw_features;
+
+ memcpy(failover_dev->dev_addr, standby_dev->dev_addr,
+ failover_dev->addr_len);
+
+ failover_dev->min_mtu = standby_dev->min_mtu;
+ failover_dev->max_mtu = standby_dev->max_mtu;
+
+ err = register_netdev(failover_dev);
+ if (err < 0) {
+ dev_err(dev, "Unable to register failover_dev!\n");
+ goto err_register_netdev;
+ }
+
+ netif_carrier_off(failover_dev);
+
+ err = failover_register(failover_dev, NULL, pfailover);
+ if (err < 0)
+ goto err_failover;
+
+ return 0;
+
+err_failover:
+ unregister_netdev(failover_dev);
+err_register_netdev:
+ free_netdev(failover_dev);
+
+ return err;
+}
+EXPORT_SYMBOL_GPL(failover_create);
+
+void failover_destroy(struct failover *failover)
+{
+ struct net_device *failover_dev;
+ struct net_device *slave_dev;
+ struct failover_info *finfo;
+
+ if (!failover)
+ return;
+
+ failover_dev = rcu_dereference(failover->failover_dev);
+ finfo = netdev_priv(failover_dev);
+
+ netif_device_detach(failover_dev);
+
+ rtnl_lock();
+
+ slave_dev = rtnl_dereference(finfo->primary_dev);
+ if (slave_dev)
+ failover_slave_unregister(slave_dev);
+
+ slave_dev = rtnl_dereference(finfo->standby_dev);
+ if (slave_dev)
+ failover_slave_unregister(slave_dev);
+
+ failover_unregister(failover);
+
+ unregister_netdevice(failover_dev);
+
+ rtnl_unlock();
+
+ free_netdev(failover_dev);
+}
+EXPORT_SYMBOL_GPL(failover_destroy);
+
+static __init int
+failover_init(void)
+{
+ register_netdevice_notifier(&failover_notifier);
+
+ return 0;
+}
+module_init(failover_init);
+
+static __exit
+void failover_exit(void)
+{
+ unregister_netdevice_notifier(&failover_notifier);
+}
+module_exit(failover_exit);
+
+MODULE_DESCRIPTION("Failover infrastructure/interface for Paravirtual drivers");
+MODULE_LICENSE("GPL v2");
--
2.14.3
^ permalink raw reply related [flat|nested] 114+ messages in thread
* [virtio-dev] [PATCH v7 net-next 2/4] net: Introduce generic failover module
@ 2018-04-20 1:42 ` Sridhar Samudrala
0 siblings, 0 replies; 114+ messages in thread
From: Sridhar Samudrala @ 2018-04-20 1:42 UTC (permalink / raw)
To: mst, stephen, davem, netdev, virtualization, virtio-dev,
jesse.brandeburg, alexander.h.duyck, kubakici, sridhar.samudrala,
jasowang, loseweigh, jiri
This provides a generic interface for paravirtual drivers to listen
for netdev register/unregister/link change events from pci ethernet
devices with the same MAC and takeover their datapath. The notifier and
event handling code is based on the existing netvsc implementation.
It exposes 2 sets of interfaces to the paravirtual drivers.
1. existing netvsc driver that uses 2 netdev model. In this model, no
master netdev is created. The paravirtual driver registers each instance
of netvsc as a 'failover' instance along with a set of ops to manage the
slave events.
failover_register()
failover_unregister()
2. new virtio_net based solution that uses 3 netdev model. In this model,
the failover module provides interfaces to create/destroy additional master
netdev and all the slave events are managed internally.
failover_create()
failover_destroy()
These functions call failover_register()/failover_unregister() with the
master netdev created by the failover module.
Signed-off-by: Sridhar Samudrala <sridhar.samudrala@intel.com>
---
include/linux/netdevice.h | 16 +
include/net/failover.h | 96 ++++++
net/Kconfig | 18 +
net/core/Makefile | 1 +
net/core/failover.c | 844 ++++++++++++++++++++++++++++++++++++++++++++++
5 files changed, 975 insertions(+)
create mode 100644 include/net/failover.h
create mode 100644 net/core/failover.c
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index cf44503ea81a..ed535b6724e1 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -1401,6 +1401,8 @@ struct net_device_ops {
* entity (i.e. the master device for bridged veth)
* @IFF_MACSEC: device is a MACsec device
* @IFF_NO_RX_HANDLER: device doesn't support the rx_handler hook
+ * @IFF_FAILOVER: device is a failover master device
+ * @IFF_FAILOVER_SLAVE: device is lower dev of a failover master device
*/
enum netdev_priv_flags {
IFF_802_1Q_VLAN = 1<<0,
@@ -1430,6 +1432,8 @@ enum netdev_priv_flags {
IFF_PHONY_HEADROOM = 1<<24,
IFF_MACSEC = 1<<25,
IFF_NO_RX_HANDLER = 1<<26,
+ IFF_FAILOVER = 1<<27,
+ IFF_FAILOVER_SLAVE = 1<<28,
};
#define IFF_802_1Q_VLAN IFF_802_1Q_VLAN
@@ -1458,6 +1462,8 @@ enum netdev_priv_flags {
#define IFF_RXFH_CONFIGURED IFF_RXFH_CONFIGURED
#define IFF_MACSEC IFF_MACSEC
#define IFF_NO_RX_HANDLER IFF_NO_RX_HANDLER
+#define IFF_FAILOVER IFF_FAILOVER
+#define IFF_FAILOVER_SLAVE IFF_FAILOVER_SLAVE
/**
* struct net_device - The DEVICE structure.
@@ -4308,6 +4314,16 @@ static inline bool netif_is_rxfh_configured(const struct net_device *dev)
return dev->priv_flags & IFF_RXFH_CONFIGURED;
}
+static inline bool netif_is_failover(const struct net_device *dev)
+{
+ return dev->priv_flags & IFF_FAILOVER;
+}
+
+static inline bool netif_is_failover_slave(const struct net_device *dev)
+{
+ return dev->priv_flags & IFF_FAILOVER_SLAVE;
+}
+
/* This device needs to keep skb dst for qdisc enqueue or ndo_start_xmit() */
static inline void netif_keep_dst(struct net_device *dev)
{
diff --git a/include/net/failover.h b/include/net/failover.h
new file mode 100644
index 000000000000..0b8601043d90
--- /dev/null
+++ b/include/net/failover.h
@@ -0,0 +1,96 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/* Copyright (c) 2018, Intel Corporation. */
+
+#ifndef _NET_FAILOVER_H
+#define _NET_FAILOVER_H
+
+#include <linux/netdevice.h>
+
+struct failover_ops {
+ int (*slave_pre_register)(struct net_device *slave_dev,
+ struct net_device *failover_dev);
+ int (*slave_join)(struct net_device *slave_dev,
+ struct net_device *failover_dev);
+ int (*slave_pre_unregister)(struct net_device *slave_dev,
+ struct net_device *failover_dev);
+ int (*slave_release)(struct net_device *slave_dev,
+ struct net_device *failover_dev);
+ int (*slave_link_change)(struct net_device *slave_dev,
+ struct net_device *failover_dev);
+ rx_handler_result_t (*handle_frame)(struct sk_buff **pskb);
+};
+
+struct failover {
+ struct list_head list;
+ struct net_device __rcu *failover_dev;
+ struct failover_ops __rcu *ops;
+};
+
+/* failover state */
+struct failover_info {
+ /* primary netdev with same MAC */
+ struct net_device __rcu *primary_dev;
+
+ /* standby netdev */
+ struct net_device __rcu *standby_dev;
+
+ /* primary netdev stats */
+ struct rtnl_link_stats64 primary_stats;
+
+ /* standby netdev stats */
+ struct rtnl_link_stats64 standby_stats;
+
+ /* aggregated stats */
+ struct rtnl_link_stats64 failover_stats;
+
+ /* spinlock while updating stats */
+ spinlock_t stats_lock;
+};
+
+#if IS_ENABLED(CONFIG_NET_FAILOVER)
+
+int failover_create(struct net_device *standby_dev,
+ struct failover **pfailover);
+void failover_destroy(struct failover *failover);
+
+int failover_register(struct net_device *standby_dev, struct failover_ops *ops,
+ struct failover **pfailover);
+void failover_unregister(struct failover *failover);
+
+int failover_slave_unregister(struct net_device *slave_dev);
+
+#else
+
+static inline
+int failover_create(struct net_device *standby_dev,
+ struct failover **pfailover);
+{
+ return 0;
+}
+
+static inline
+void failover_destroy(struct failover *failover)
+{
+}
+
+static inline
+int failover_register(struct net_device *standby_dev, struct failover_ops *ops,
+ struct pfailover **pfailover);
+{
+ return 0;
+}
+
+static inline
+void failover_unregister(struct failover *failover)
+{
+}
+
+static inline
+int failover_slave_unregister(struct net_device *slave_dev)
+{
+ return 0;
+}
+
+#endif
+
+#endif /* _NET_FAILOVER_H */
diff --git a/net/Kconfig b/net/Kconfig
index 0428f12c25c2..388b99dfee10 100644
--- a/net/Kconfig
+++ b/net/Kconfig
@@ -423,6 +423,24 @@ config MAY_USE_DEVLINK
on MAY_USE_DEVLINK to ensure they do not cause link errors when
devlink is a loadable module and the driver using it is built-in.
+config NET_FAILOVER
+ tristate "Failover interface"
+ help
+ This provides a generic interface for paravirtual drivers to listen
+ for netdev register/unregister/link change events from pci ethernet
+ devices with the same MAC and takeover their datapath. This also
+ enables live migration of a VM with direct attached VF by failing
+ over to the paravirtual datapath when the VF is unplugged.
+
+config MAY_USE_FAILOVER
+ tristate
+ default m if NET_FAILOVER=m
+ default y if NET_FAILOVER=y || NET_FAILOVER=n
+ help
+ Drivers using the failover infrastructure should have a dependency
+ on MAY_USE_FAILOVER to ensure they do not cause link errors when
+ failover is a loadable module and the driver using it is built-in.
+
endif # if NET
# Used by archs to tell that they support BPF JIT compiler plus which flavour.
diff --git a/net/core/Makefile b/net/core/Makefile
index 6dbbba8c57ae..cef17518bb7d 100644
--- a/net/core/Makefile
+++ b/net/core/Makefile
@@ -30,3 +30,4 @@ obj-$(CONFIG_DST_CACHE) += dst_cache.o
obj-$(CONFIG_HWBM) += hwbm.o
obj-$(CONFIG_NET_DEVLINK) += devlink.o
obj-$(CONFIG_GRO_CELLS) += gro_cells.o
+obj-$(CONFIG_NET_FAILOVER) += failover.o
diff --git a/net/core/failover.c b/net/core/failover.c
new file mode 100644
index 000000000000..7bee762cb737
--- /dev/null
+++ b/net/core/failover.c
@@ -0,0 +1,844 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Copyright (c) 2018, Intel Corporation. */
+
+/* A common module to handle registrations and notifications for paravirtual
+ * drivers to enable accelerated datapath and support VF live migration.
+ *
+ * The notifier and event handling code is based on netvsc driver.
+ */
+
+#include <linux/netdevice.h>
+#include <linux/etherdevice.h>
+#include <linux/ethtool.h>
+#include <linux/module.h>
+#include <linux/slab.h>
+#include <linux/netdevice.h>
+#include <linux/netpoll.h>
+#include <linux/rtnetlink.h>
+#include <linux/if_vlan.h>
+#include <linux/pci.h>
+#include <net/sch_generic.h>
+#include <uapi/linux/if_arp.h>
+#include <net/failover.h>
+
+static LIST_HEAD(failover_list);
+static DEFINE_SPINLOCK(failover_lock);
+
+static int failover_slave_pre_register(struct net_device *slave_dev,
+ struct net_device *failover_dev,
+ struct failover_ops *failover_ops)
+{
+ struct failover_info *finfo;
+ bool standby;
+
+ if (failover_ops) {
+ if (!failover_ops->slave_pre_register)
+ return -EINVAL;
+
+ return failover_ops->slave_pre_register(slave_dev,
+ failover_dev);
+ }
+
+ finfo = netdev_priv(failover_dev);
+ standby = (slave_dev->dev.parent == failover_dev->dev.parent);
+ if (standby ? rtnl_dereference(finfo->standby_dev) :
+ rtnl_dereference(finfo->primary_dev)) {
+ netdev_err(failover_dev, "%s attempting to register as slave dev when %s already present\n",
+ slave_dev->name, standby ? "standby" : "primary");
+ return -EEXIST;
+ }
+
+ /* Avoid non pci devices as primary netdev */
+ if (!standby && (!slave_dev->dev.parent ||
+ !dev_is_pci(slave_dev->dev.parent)))
+ return -EINVAL;
+
+ return 0;
+}
+
+static int failover_slave_join(struct net_device *slave_dev,
+ struct net_device *failover_dev,
+ struct failover_ops *failover_ops)
+{
+ struct failover_info *finfo;
+ int err, orig_mtu;
+ bool standby;
+
+ if (failover_ops) {
+ if (!failover_ops->slave_join)
+ return -EINVAL;
+
+ return failover_ops->slave_join(slave_dev, failover_dev);
+ }
+
+ if (netif_running(failover_dev)) {
+ err = dev_open(slave_dev);
+ if (err && (err != -EBUSY)) {
+ netdev_err(failover_dev, "Opening slave %s failed err:%d\n",
+ slave_dev->name, err);
+ goto err_dev_open;
+ }
+ }
+
+ /* Align MTU of slave with failover dev */
+ orig_mtu = slave_dev->mtu;
+ err = dev_set_mtu(slave_dev, failover_dev->mtu);
+ if (err) {
+ netdev_err(failover_dev, "unable to change mtu of %s to %u register failed\n",
+ slave_dev->name, failover_dev->mtu);
+ goto err_set_mtu;
+ }
+
+ finfo = netdev_priv(failover_dev);
+ standby = (slave_dev->dev.parent == failover_dev->dev.parent);
+
+ dev_hold(slave_dev);
+
+ if (standby) {
+ rcu_assign_pointer(finfo->standby_dev, slave_dev);
+ dev_get_stats(finfo->standby_dev, &finfo->standby_stats);
+ } else {
+ rcu_assign_pointer(finfo->primary_dev, slave_dev);
+ dev_get_stats(finfo->primary_dev, &finfo->primary_stats);
+ failover_dev->min_mtu = slave_dev->min_mtu;
+ failover_dev->max_mtu = slave_dev->max_mtu;
+ }
+
+ netdev_info(failover_dev, "failover slave:%s joined\n",
+ slave_dev->name);
+
+ return 0;
+
+err_set_mtu:
+ dev_close(slave_dev);
+err_dev_open:
+ return err;
+}
+
+/* Called when slave dev is injecting data into network stack.
+ * Change the associated network device from lower dev to virtio.
+ * note: already called with rcu_read_lock
+ */
+static rx_handler_result_t failover_handle_frame(struct sk_buff **pskb)
+{
+ struct sk_buff *skb = *pskb;
+ struct net_device *ndev = rcu_dereference(skb->dev->rx_handler_data);
+
+ skb->dev = ndev;
+
+ return RX_HANDLER_ANOTHER;
+}
+
+static struct net_device *failover_get_bymac(u8 *mac, struct failover_ops **ops)
+{
+ struct net_device *failover_dev;
+ struct failover *failover;
+
+ spin_lock(&failover_lock);
+ list_for_each_entry(failover, &failover_list, list) {
+ failover_dev = rtnl_dereference(failover->failover_dev);
+ if (ether_addr_equal(failover_dev->perm_addr, mac)) {
+ *ops = rtnl_dereference(failover->ops);
+ spin_unlock(&failover_lock);
+ return failover_dev;
+ }
+ }
+ spin_unlock(&failover_lock);
+ return NULL;
+}
+
+static int failover_slave_register(struct net_device *slave_dev)
+{
+ struct failover_ops *failover_ops;
+ struct net_device *failover_dev;
+ int ret;
+
+ ASSERT_RTNL();
+
+ failover_dev = failover_get_bymac(slave_dev->perm_addr, &failover_ops);
+ if (!failover_dev)
+ goto done;
+
+ ret = failover_slave_pre_register(slave_dev, failover_dev,
+ failover_ops);
+ if (ret)
+ goto done;
+
+ ret = netdev_rx_handler_register(slave_dev, failover_ops ?
+ failover_ops->handle_frame :
+ failover_handle_frame, failover_dev);
+ if (ret) {
+ netdev_err(slave_dev, "can not register failover rx handler (err = %d)\n",
+ ret);
+ goto done;
+ }
+
+ ret = netdev_upper_dev_link(slave_dev, failover_dev, NULL);
+ if (ret) {
+ netdev_err(slave_dev, "can not set failover device %s (err = %d)\n",
+ failover_dev->name, ret);
+ goto upper_link_failed;
+ }
+
+ slave_dev->priv_flags |= IFF_FAILOVER_SLAVE;
+
+ ret = failover_slave_join(slave_dev, failover_dev, failover_ops);
+ if (ret)
+ goto err_join;
+
+ call_netdevice_notifiers(NETDEV_JOIN, slave_dev);
+
+ netdev_info(failover_dev, "failover slave:%s registered\n",
+ slave_dev->name);
+
+ goto done;
+
+err_join:
+ netdev_upper_dev_unlink(slave_dev, failover_dev);
+ slave_dev->priv_flags &= ~IFF_FAILOVER_SLAVE;
+upper_link_failed:
+ netdev_rx_handler_unregister(slave_dev);
+done:
+ return NOTIFY_DONE;
+}
+
+static int failover_slave_pre_unregister(struct net_device *slave_dev,
+ struct net_device *failover_dev,
+ struct failover_ops *failover_ops)
+{
+ struct net_device *standby_dev, *primary_dev;
+ struct failover_info *finfo;
+
+ if (failover_ops) {
+ if (!failover_ops->slave_pre_unregister)
+ return -EINVAL;
+
+ return failover_ops->slave_pre_unregister(slave_dev,
+ failover_dev);
+ }
+
+ finfo = netdev_priv(failover_dev);
+ primary_dev = rtnl_dereference(finfo->primary_dev);
+ standby_dev = rtnl_dereference(finfo->standby_dev);
+
+ if (slave_dev != primary_dev && slave_dev != standby_dev)
+ return -EINVAL;
+
+ return 0;
+}
+
+static int failover_slave_release(struct net_device *slave_dev,
+ struct net_device *failover_dev,
+ struct failover_ops *failover_ops)
+{
+ struct net_device *standby_dev, *primary_dev;
+ struct failover_info *finfo;
+
+ if (failover_ops) {
+ if (!failover_ops->slave_release)
+ return -EINVAL;
+
+ return failover_ops->slave_release(slave_dev, failover_dev);
+ }
+
+ finfo = netdev_priv(failover_dev);
+ primary_dev = rtnl_dereference(finfo->primary_dev);
+ standby_dev = rtnl_dereference(finfo->standby_dev);
+
+ if (slave_dev == standby_dev) {
+ RCU_INIT_POINTER(finfo->standby_dev, NULL);
+ } else {
+ RCU_INIT_POINTER(finfo->primary_dev, NULL);
+ if (standby_dev) {
+ failover_dev->min_mtu = standby_dev->min_mtu;
+ failover_dev->max_mtu = standby_dev->max_mtu;
+ }
+ }
+
+ dev_put(slave_dev);
+
+ netdev_info(failover_dev, "failover slave:%s released\n",
+ slave_dev->name);
+
+ return 0;
+}
+
+int failover_slave_unregister(struct net_device *slave_dev)
+{
+ struct failover_ops *failover_ops;
+ struct net_device *failover_dev;
+ int ret;
+
+ if (!netif_is_failover_slave(slave_dev))
+ goto done;
+
+ ASSERT_RTNL();
+
+ failover_dev = failover_get_bymac(slave_dev->perm_addr, &failover_ops);
+ if (!failover_dev)
+ goto done;
+
+ ret = failover_slave_pre_unregister(slave_dev, failover_dev,
+ failover_ops);
+ if (ret)
+ goto done;
+
+ netdev_rx_handler_unregister(slave_dev);
+ netdev_upper_dev_unlink(slave_dev, failover_dev);
+ slave_dev->priv_flags &= ~IFF_FAILOVER_SLAVE;
+
+ failover_slave_release(slave_dev, failover_dev, failover_ops);
+
+ netdev_info(failover_dev, "failover slave:%s unregistered\n",
+ slave_dev->name);
+
+done:
+ return NOTIFY_DONE;
+}
+EXPORT_SYMBOL_GPL(failover_slave_unregister);
+
+static bool failover_xmit_ready(struct net_device *dev)
+{
+ return netif_running(dev) && netif_carrier_ok(dev);
+}
+
+static int failover_slave_link_change(struct net_device *slave_dev)
+{
+ struct net_device *failover_dev, *primary_dev, *standby_dev;
+ struct failover_ops *failover_ops;
+ struct failover_info *finfo;
+
+ if (!netif_is_failover_slave(slave_dev))
+ goto done;
+
+ ASSERT_RTNL();
+
+ failover_dev = failover_get_bymac(slave_dev->perm_addr, &failover_ops);
+ if (!failover_dev)
+ goto done;
+
+ if (failover_ops) {
+ if (!failover_ops->slave_link_change)
+ goto done;
+
+ return failover_ops->slave_link_change(slave_dev, failover_dev);
+ }
+
+ if (!netif_running(failover_dev))
+ return 0;
+
+ finfo = netdev_priv(failover_dev);
+
+ primary_dev = rtnl_dereference(finfo->primary_dev);
+ standby_dev = rtnl_dereference(finfo->standby_dev);
+
+ if (slave_dev != primary_dev && slave_dev != standby_dev)
+ goto done;
+
+ if ((primary_dev && failover_xmit_ready(primary_dev)) ||
+ (standby_dev && failover_xmit_ready(standby_dev))) {
+ netif_carrier_on(failover_dev);
+ netif_tx_wake_all_queues(failover_dev);
+ } else {
+ netif_carrier_off(failover_dev);
+ netif_tx_stop_all_queues(failover_dev);
+ }
+
+done:
+ return NOTIFY_DONE;
+}
+
+static bool failover_validate_event_dev(struct net_device *dev)
+{
+ /* Skip parent events */
+ if (netif_is_failover(dev))
+ return false;
+
+ /* Avoid non-Ethernet type devices */
+ if (dev->type != ARPHRD_ETHER)
+ return false;
+
+ return true;
+}
+
+static int
+failover_event(struct notifier_block *this, unsigned long event, void *ptr)
+{
+ struct net_device *event_dev = netdev_notifier_info_to_dev(ptr);
+
+ if (!failover_validate_event_dev(event_dev))
+ return NOTIFY_DONE;
+
+ switch (event) {
+ case NETDEV_REGISTER:
+ return failover_slave_register(event_dev);
+ case NETDEV_UNREGISTER:
+ return failover_slave_unregister(event_dev);
+ case NETDEV_UP:
+ case NETDEV_DOWN:
+ case NETDEV_CHANGE:
+ return failover_slave_link_change(event_dev);
+ default:
+ return NOTIFY_DONE;
+ }
+}
+
+static struct notifier_block failover_notifier = {
+ .notifier_call = failover_event,
+};
+
+static int failover_open(struct net_device *dev)
+{
+ struct failover_info *finfo = netdev_priv(dev);
+ struct net_device *primary_dev, *standby_dev;
+ int err;
+
+ netif_carrier_off(dev);
+ netif_tx_wake_all_queues(dev);
+
+ primary_dev = rtnl_dereference(finfo->primary_dev);
+ if (primary_dev) {
+ err = dev_open(primary_dev);
+ if (err)
+ goto err_primary_open;
+ }
+
+ standby_dev = rtnl_dereference(finfo->standby_dev);
+ if (standby_dev) {
+ err = dev_open(standby_dev);
+ if (err)
+ goto err_standby_open;
+ }
+
+ return 0;
+
+err_standby_open:
+ dev_close(primary_dev);
+err_primary_open:
+ netif_tx_disable(dev);
+ return err;
+}
+
+static int failover_close(struct net_device *dev)
+{
+ struct failover_info *finfo = netdev_priv(dev);
+ struct net_device *slave_dev;
+
+ netif_tx_disable(dev);
+
+ slave_dev = rtnl_dereference(finfo->primary_dev);
+ if (slave_dev)
+ dev_close(slave_dev);
+
+ slave_dev = rtnl_dereference(finfo->standby_dev);
+ if (slave_dev)
+ dev_close(slave_dev);
+
+ return 0;
+}
+
+static netdev_tx_t failover_drop_xmit(struct sk_buff *skb,
+ struct net_device *dev)
+{
+ atomic_long_inc(&dev->tx_dropped);
+ dev_kfree_skb_any(skb);
+ return NETDEV_TX_OK;
+}
+
+static netdev_tx_t failover_start_xmit(struct sk_buff *skb,
+ struct net_device *dev)
+{
+ struct failover_info *finfo = netdev_priv(dev);
+ struct net_device *xmit_dev;
+
+ /* Try xmit via primary netdev followed by standby netdev */
+ xmit_dev = rcu_dereference_bh(finfo->primary_dev);
+ if (!xmit_dev || !failover_xmit_ready(xmit_dev)) {
+ xmit_dev = rcu_dereference_bh(finfo->standby_dev);
+ if (!xmit_dev || !failover_xmit_ready(xmit_dev))
+ return failover_drop_xmit(skb, dev);
+ }
+
+ skb->dev = xmit_dev;
+ skb->queue_mapping = qdisc_skb_cb(skb)->slave_dev_queue_mapping;
+
+ return dev_queue_xmit(skb);
+}
+
+static u16 failover_select_queue(struct net_device *dev, struct sk_buff *skb,
+ void *accel_priv,
+ select_queue_fallback_t fallback)
+{
+ struct failover_info *finfo = netdev_priv(dev);
+ struct net_device *primary_dev;
+ u16 txq;
+
+ rcu_read_lock();
+ primary_dev = rcu_dereference(finfo->primary_dev);
+ if (primary_dev) {
+ const struct net_device_ops *ops = primary_dev->netdev_ops;
+
+ if (ops->ndo_select_queue)
+ txq = ops->ndo_select_queue(primary_dev, skb,
+ accel_priv, fallback);
+ else
+ txq = fallback(primary_dev, skb);
+
+ qdisc_skb_cb(skb)->slave_dev_queue_mapping = skb->queue_mapping;
+
+ return txq;
+ }
+
+ txq = skb_rx_queue_recorded(skb) ? skb_get_rx_queue(skb) : 0;
+
+ /* Save the original txq to restore before passing to the driver */
+ qdisc_skb_cb(skb)->slave_dev_queue_mapping = skb->queue_mapping;
+
+ if (unlikely(txq >= dev->real_num_tx_queues)) {
+ do {
+ txq -= dev->real_num_tx_queues;
+ } while (txq >= dev->real_num_tx_queues);
+ }
+
+ return txq;
+}
+
+/* fold stats, assuming all rtnl_link_stats64 fields are u64, but
+ * that some drivers can provide 32finfot values only.
+ */
+static void failover_fold_stats(struct rtnl_link_stats64 *_res,
+ const struct rtnl_link_stats64 *_new,
+ const struct rtnl_link_stats64 *_old)
+{
+ const u64 *new = (const u64 *)_new;
+ const u64 *old = (const u64 *)_old;
+ u64 *res = (u64 *)_res;
+ int i;
+
+ for (i = 0; i < sizeof(*_res) / sizeof(u64); i++) {
+ u64 nv = new[i];
+ u64 ov = old[i];
+ s64 delta = nv - ov;
+
+ /* detects if this particular field is 32bit only */
+ if (((nv | ov) >> 32) == 0)
+ delta = (s64)(s32)((u32)nv - (u32)ov);
+
+ /* filter anomalies, some drivers reset their stats
+ * at down/up events.
+ */
+ if (delta > 0)
+ res[i] += delta;
+ }
+}
+
+static void failover_get_stats(struct net_device *dev,
+ struct rtnl_link_stats64 *stats)
+{
+ struct failover_info *finfo = netdev_priv(dev);
+ const struct rtnl_link_stats64 *new;
+ struct rtnl_link_stats64 temp;
+ struct net_device *slave_dev;
+
+ spin_lock(&finfo->stats_lock);
+ memcpy(stats, &finfo->failover_stats, sizeof(*stats));
+
+ rcu_read_lock();
+
+ slave_dev = rcu_dereference(finfo->primary_dev);
+ if (slave_dev) {
+ new = dev_get_stats(slave_dev, &temp);
+ failover_fold_stats(stats, new, &finfo->primary_stats);
+ memcpy(&finfo->primary_stats, new, sizeof(*new));
+ }
+
+ slave_dev = rcu_dereference(finfo->standby_dev);
+ if (slave_dev) {
+ new = dev_get_stats(slave_dev, &temp);
+ failover_fold_stats(stats, new, &finfo->standby_stats);
+ memcpy(&finfo->standby_stats, new, sizeof(*new));
+ }
+
+ rcu_read_unlock();
+
+ memcpy(&finfo->failover_stats, stats, sizeof(*stats));
+ spin_unlock(&finfo->stats_lock);
+}
+
+static int failover_change_mtu(struct net_device *dev, int new_mtu)
+{
+ struct failover_info *finfo = netdev_priv(dev);
+ struct net_device *primary_dev, *standby_dev;
+ int ret = 0;
+
+ primary_dev = rcu_dereference(finfo->primary_dev);
+ if (primary_dev) {
+ ret = dev_set_mtu(primary_dev, new_mtu);
+ if (ret)
+ return ret;
+ }
+
+ standby_dev = rcu_dereference(finfo->standby_dev);
+ if (standby_dev) {
+ ret = dev_set_mtu(standby_dev, new_mtu);
+ if (ret) {
+ dev_set_mtu(primary_dev, dev->mtu);
+ return ret;
+ }
+ }
+
+ dev->mtu = new_mtu;
+ return 0;
+}
+
+static void failover_set_rx_mode(struct net_device *dev)
+{
+ struct failover_info *finfo = netdev_priv(dev);
+ struct net_device *slave_dev;
+
+ rcu_read_lock();
+
+ slave_dev = rcu_dereference(finfo->primary_dev);
+ if (slave_dev) {
+ dev_uc_sync_multiple(slave_dev, dev);
+ dev_mc_sync_multiple(slave_dev, dev);
+ }
+
+ slave_dev = rcu_dereference(finfo->standby_dev);
+ if (slave_dev) {
+ dev_uc_sync_multiple(slave_dev, dev);
+ dev_mc_sync_multiple(slave_dev, dev);
+ }
+
+ rcu_read_unlock();
+}
+
+static const struct net_device_ops failover_dev_ops = {
+ .ndo_open = failover_open,
+ .ndo_stop = failover_close,
+ .ndo_start_xmit = failover_start_xmit,
+ .ndo_select_queue = failover_select_queue,
+ .ndo_get_stats64 = failover_get_stats,
+ .ndo_change_mtu = failover_change_mtu,
+ .ndo_set_rx_mode = failover_set_rx_mode,
+ .ndo_validate_addr = eth_validate_addr,
+ .ndo_features_check = passthru_features_check,
+};
+
+#define FAILOVER_NAME "failover"
+#define FAILOVER_VERSION "0.1"
+
+static void failover_ethtool_get_drvinfo(struct net_device *dev,
+ struct ethtool_drvinfo *drvinfo)
+{
+ strlcpy(drvinfo->driver, FAILOVER_NAME, sizeof(drvinfo->driver));
+ strlcpy(drvinfo->version, FAILOVER_VERSION, sizeof(drvinfo->version));
+}
+
+int failover_ethtool_get_link_ksettings(struct net_device *dev,
+ struct ethtool_link_ksettings *cmd)
+{
+ struct failover_info *finfo = netdev_priv(dev);
+ struct net_device *slave_dev;
+
+ slave_dev = rtnl_dereference(finfo->primary_dev);
+ if (!slave_dev || !failover_xmit_ready(slave_dev)) {
+ slave_dev = rtnl_dereference(finfo->standby_dev);
+ if (!slave_dev || !failover_xmit_ready(slave_dev)) {
+ cmd->base.duplex = DUPLEX_UNKNOWN;
+ cmd->base.port = PORT_OTHER;
+ cmd->base.speed = SPEED_UNKNOWN;
+
+ return 0;
+ }
+ }
+
+ return __ethtool_get_link_ksettings(slave_dev, cmd);
+}
+EXPORT_SYMBOL_GPL(failover_ethtool_get_link_ksettings);
+
+static const struct ethtool_ops failover_ethtool_ops = {
+ .get_drvinfo = failover_ethtool_get_drvinfo,
+ .get_link = ethtool_op_get_link,
+ .get_link_ksettings = failover_ethtool_get_link_ksettings,
+};
+
+static void failover_register_existing_slave(struct net_device *failover_dev)
+{
+ struct net *net = dev_net(failover_dev);
+ struct net_device *dev;
+
+ rtnl_lock();
+ for_each_netdev(net, dev) {
+ if (dev == failover_dev)
+ continue;
+ if (!failover_validate_event_dev(dev))
+ continue;
+ if (ether_addr_equal(failover_dev->perm_addr, dev->perm_addr))
+ failover_slave_register(dev);
+ }
+ rtnl_unlock();
+}
+
+int failover_register(struct net_device *dev, struct failover_ops *ops,
+ struct failover **pfailover)
+{
+ struct failover *failover;
+
+ failover = kzalloc(sizeof(*failover), GFP_KERNEL);
+ if (!failover)
+ return -ENOMEM;
+
+ rcu_assign_pointer(failover->ops, ops);
+ dev_hold(dev);
+ dev->priv_flags |= IFF_FAILOVER;
+ rcu_assign_pointer(failover->failover_dev, dev);
+
+ spin_lock(&failover_lock);
+ list_add_tail(&failover->list, &failover_list);
+ spin_unlock(&failover_lock);
+
+ failover_register_existing_slave(dev);
+
+ *pfailover = failover;
+ return 0;
+}
+EXPORT_SYMBOL_GPL(failover_register);
+
+void failover_unregister(struct failover *failover)
+{
+ struct net_device *failover_dev;
+
+ failover_dev = rcu_dereference(failover->failover_dev);
+
+ failover_dev->priv_flags &= ~IFF_FAILOVER;
+ dev_put(failover_dev);
+
+ spin_lock(&failover_lock);
+ list_del(&failover->list);
+ spin_unlock(&failover_lock);
+
+ kfree(failover);
+}
+EXPORT_SYMBOL_GPL(failover_unregister);
+
+int failover_create(struct net_device *standby_dev, struct failover **pfailover)
+{
+ struct device *dev = standby_dev->dev.parent;
+ struct net_device *failover_dev;
+ int err;
+
+ /* Alloc at least 2 queues, for now we are going with 16 assuming
+ * that most devices being bonded won't have too many queues.
+ */
+ failover_dev = alloc_etherdev_mq(sizeof(struct failover_info), 16);
+ if (!failover_dev) {
+ dev_err(dev, "Unable to allocate failover_netdev!\n");
+ return -ENOMEM;
+ }
+
+ dev_net_set(failover_dev, dev_net(standby_dev));
+ SET_NETDEV_DEV(failover_dev, dev);
+
+ failover_dev->netdev_ops = &failover_dev_ops;
+ failover_dev->ethtool_ops = &failover_ethtool_ops;
+
+ /* Initialize the device options */
+ failover_dev->priv_flags |= IFF_UNICAST_FLT | IFF_NO_QUEUE;
+ failover_dev->priv_flags &= ~(IFF_XMIT_DST_RELEASE |
+ IFF_TX_SKB_SHARING);
+
+ /* don't acquire failover netdev's netif_tx_lock when transmitting */
+ failover_dev->features |= NETIF_F_LLTX;
+
+ /* Don't allow failover devices to change network namespaces. */
+ failover_dev->features |= NETIF_F_NETNS_LOCAL;
+
+ failover_dev->hw_features = NETIF_F_HW_CSUM | NETIF_F_SG |
+ NETIF_F_FRAGLIST | NETIF_F_ALL_TSO |
+ NETIF_F_HIGHDMA | NETIF_F_LRO;
+
+ failover_dev->hw_features |= NETIF_F_GSO_ENCAP_ALL;
+ failover_dev->features |= failover_dev->hw_features;
+
+ memcpy(failover_dev->dev_addr, standby_dev->dev_addr,
+ failover_dev->addr_len);
+
+ failover_dev->min_mtu = standby_dev->min_mtu;
+ failover_dev->max_mtu = standby_dev->max_mtu;
+
+ err = register_netdev(failover_dev);
+ if (err < 0) {
+ dev_err(dev, "Unable to register failover_dev!\n");
+ goto err_register_netdev;
+ }
+
+ netif_carrier_off(failover_dev);
+
+ err = failover_register(failover_dev, NULL, pfailover);
+ if (err < 0)
+ goto err_failover;
+
+ return 0;
+
+err_failover:
+ unregister_netdev(failover_dev);
+err_register_netdev:
+ free_netdev(failover_dev);
+
+ return err;
+}
+EXPORT_SYMBOL_GPL(failover_create);
+
+void failover_destroy(struct failover *failover)
+{
+ struct net_device *failover_dev;
+ struct net_device *slave_dev;
+ struct failover_info *finfo;
+
+ if (!failover)
+ return;
+
+ failover_dev = rcu_dereference(failover->failover_dev);
+ finfo = netdev_priv(failover_dev);
+
+ netif_device_detach(failover_dev);
+
+ rtnl_lock();
+
+ slave_dev = rtnl_dereference(finfo->primary_dev);
+ if (slave_dev)
+ failover_slave_unregister(slave_dev);
+
+ slave_dev = rtnl_dereference(finfo->standby_dev);
+ if (slave_dev)
+ failover_slave_unregister(slave_dev);
+
+ failover_unregister(failover);
+
+ unregister_netdevice(failover_dev);
+
+ rtnl_unlock();
+
+ free_netdev(failover_dev);
+}
+EXPORT_SYMBOL_GPL(failover_destroy);
+
+static __init int
+failover_init(void)
+{
+ register_netdevice_notifier(&failover_notifier);
+
+ return 0;
+}
+module_init(failover_init);
+
+static __exit
+void failover_exit(void)
+{
+ unregister_netdevice_notifier(&failover_notifier);
+}
+module_exit(failover_exit);
+
+MODULE_DESCRIPTION("Failover infrastructure/interface for Paravirtual drivers");
+MODULE_LICENSE("GPL v2");
--
2.14.3
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply related [flat|nested] 114+ messages in thread
* [PATCH v7 net-next 3/4] virtio_net: Extend virtio to use VF datapath when available
2018-04-20 1:42 ` [virtio-dev] " Sridhar Samudrala
@ 2018-04-20 1:42 ` Sridhar Samudrala
-1 siblings, 0 replies; 114+ messages in thread
From: Sridhar Samudrala @ 2018-04-20 1:42 UTC (permalink / raw)
To: mst, stephen, davem, netdev, virtualization, virtio-dev,
jesse.brandeburg, alexander.h.duyck, kubakici, sridhar.samudrala,
jasowang, loseweigh, jiri
This patch enables virtio_net to switch over to a VF datapath when a VF
netdev is present with the same MAC address. It allows live migration
of a VM with a direct attached VF without the need to setup a bond/team
between a VF and virtio net device in the guest.
The hypervisor needs to enable only one datapath at any time so that
packets don't get looped back to the VM over the other datapath. When a VF
is plugged, the virtio datapath link state can be marked as down. The
hypervisor needs to unplug the VF device from the guest on the source host
and reset the MAC filter of the VF to initiate failover of datapath to
virtio before starting the migration. After the migration is completed,
the destination hypervisor sets the MAC filter on the VF and plugs it back
to the guest to switch over to VF datapath.
It uses the generic failover framework that provides 2 functions to create
and destroy a master failover netdev. When STANDBY feature is enabled, an
additional netdev(failover netdev) is created that acts as a master device
and tracks the state of the 2 lower netdevs. The original virtio_net netdev
is marked as 'standby' netdev and a passthru device with the same MAC is
registered as 'primary' netdev.
This patch is based on the discussion initiated by Jesse on this thread.
https://marc.info/?l=linux-virtualization&m=151189725224231&w=2
Signed-off-by: Sridhar Samudrala <sridhar.samudrala@intel.com>
---
drivers/net/Kconfig | 1 +
drivers/net/virtio_net.c | 36 +++++++++++++++++++++++++++++++++++-
2 files changed, 36 insertions(+), 1 deletion(-)
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 891846655000..5abe328973da 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -331,6 +331,7 @@ config VETH
config VIRTIO_NET
tristate "Virtio network driver"
depends on VIRTIO
+ depends on MAY_USE_FAILOVER
---help---
This is the virtual network driver for virtio. It can be used with
QEMU based VMMs (like KVM or Xen). Say Y or M.
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 6f95719ede40..42b9f9bff48b 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -30,8 +30,11 @@
#include <linux/cpu.h>
#include <linux/average.h>
#include <linux/filter.h>
+#include <linux/netdevice.h>
+#include <linux/pci.h>
#include <net/route.h>
#include <net/xdp.h>
+#include <net/failover.h>
static int napi_weight = NAPI_POLL_WEIGHT;
module_param(napi_weight, int, 0444);
@@ -206,6 +209,9 @@ struct virtnet_info {
u32 speed;
unsigned long guest_offloads;
+
+ /* failover when STANDBY feature enabled */
+ struct failover *failover;
};
struct padded_vnet_hdr {
@@ -2275,6 +2281,22 @@ static int virtnet_xdp(struct net_device *dev, struct netdev_bpf *xdp)
}
}
+static int virtnet_get_phys_port_name(struct net_device *dev, char *buf,
+ size_t len)
+{
+ struct virtnet_info *vi = netdev_priv(dev);
+ int ret;
+
+ if (!virtio_has_feature(vi->vdev, VIRTIO_NET_F_STANDBY))
+ return -EOPNOTSUPP;
+
+ ret = snprintf(buf, len, "_sby");
+ if (ret >= len)
+ return -EOPNOTSUPP;
+
+ return 0;
+}
+
static const struct net_device_ops virtnet_netdev = {
.ndo_open = virtnet_open,
.ndo_stop = virtnet_close,
@@ -2292,6 +2314,7 @@ static const struct net_device_ops virtnet_netdev = {
.ndo_xdp_xmit = virtnet_xdp_xmit,
.ndo_xdp_flush = virtnet_xdp_flush,
.ndo_features_check = passthru_features_check,
+ .ndo_get_phys_port_name = virtnet_get_phys_port_name,
};
static void virtnet_config_changed_work(struct work_struct *work)
@@ -2839,10 +2862,16 @@ static int virtnet_probe(struct virtio_device *vdev)
virtnet_init_settings(dev);
+ if (virtio_has_feature(vdev, VIRTIO_NET_F_STANDBY)) {
+ err = failover_create(vi->dev, &vi->failover);
+ if (err)
+ goto free_vqs;
+ }
+
err = register_netdev(dev);
if (err) {
pr_debug("virtio_net: registering device failed\n");
- goto free_vqs;
+ goto free_failover;
}
virtio_device_ready(vdev);
@@ -2879,6 +2908,8 @@ static int virtnet_probe(struct virtio_device *vdev)
vi->vdev->config->reset(vdev);
unregister_netdev(dev);
+free_failover:
+ failover_destroy(vi->failover);
free_vqs:
cancel_delayed_work_sync(&vi->refill);
free_receive_page_frags(vi);
@@ -2913,6 +2944,8 @@ static void virtnet_remove(struct virtio_device *vdev)
unregister_netdev(vi->dev);
+ failover_destroy(vi->failover);
+
remove_vq_common(vi);
free_netdev(vi->dev);
@@ -3010,6 +3043,7 @@ static __init int virtio_net_driver_init(void)
ret = register_virtio_driver(&virtio_net_driver);
if (ret)
goto err_virtio;
+
return 0;
err_virtio:
cpuhp_remove_multi_state(CPUHP_VIRT_NET_DEAD);
--
2.14.3
^ permalink raw reply related [flat|nested] 114+ messages in thread
* [PATCH v7 net-next 3/4] virtio_net: Extend virtio to use VF datapath when available
2018-04-20 1:42 ` [virtio-dev] " Sridhar Samudrala
` (5 preceding siblings ...)
(?)
@ 2018-04-20 1:42 ` Sridhar Samudrala
-1 siblings, 0 replies; 114+ messages in thread
From: Sridhar Samudrala @ 2018-04-20 1:42 UTC (permalink / raw)
To: mst, stephen, davem, netdev, virtualization, virtio-dev,
jesse.brandeburg, alexander.h.duyck, kubakici, sridhar.samudrala,
jasowang, loseweigh, jiri
This patch enables virtio_net to switch over to a VF datapath when a VF
netdev is present with the same MAC address. It allows live migration
of a VM with a direct attached VF without the need to setup a bond/team
between a VF and virtio net device in the guest.
The hypervisor needs to enable only one datapath at any time so that
packets don't get looped back to the VM over the other datapath. When a VF
is plugged, the virtio datapath link state can be marked as down. The
hypervisor needs to unplug the VF device from the guest on the source host
and reset the MAC filter of the VF to initiate failover of datapath to
virtio before starting the migration. After the migration is completed,
the destination hypervisor sets the MAC filter on the VF and plugs it back
to the guest to switch over to VF datapath.
It uses the generic failover framework that provides 2 functions to create
and destroy a master failover netdev. When STANDBY feature is enabled, an
additional netdev(failover netdev) is created that acts as a master device
and tracks the state of the 2 lower netdevs. The original virtio_net netdev
is marked as 'standby' netdev and a passthru device with the same MAC is
registered as 'primary' netdev.
This patch is based on the discussion initiated by Jesse on this thread.
https://marc.info/?l=linux-virtualization&m=151189725224231&w=2
Signed-off-by: Sridhar Samudrala <sridhar.samudrala@intel.com>
---
drivers/net/Kconfig | 1 +
drivers/net/virtio_net.c | 36 +++++++++++++++++++++++++++++++++++-
2 files changed, 36 insertions(+), 1 deletion(-)
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 891846655000..5abe328973da 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -331,6 +331,7 @@ config VETH
config VIRTIO_NET
tristate "Virtio network driver"
depends on VIRTIO
+ depends on MAY_USE_FAILOVER
---help---
This is the virtual network driver for virtio. It can be used with
QEMU based VMMs (like KVM or Xen). Say Y or M.
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 6f95719ede40..42b9f9bff48b 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -30,8 +30,11 @@
#include <linux/cpu.h>
#include <linux/average.h>
#include <linux/filter.h>
+#include <linux/netdevice.h>
+#include <linux/pci.h>
#include <net/route.h>
#include <net/xdp.h>
+#include <net/failover.h>
static int napi_weight = NAPI_POLL_WEIGHT;
module_param(napi_weight, int, 0444);
@@ -206,6 +209,9 @@ struct virtnet_info {
u32 speed;
unsigned long guest_offloads;
+
+ /* failover when STANDBY feature enabled */
+ struct failover *failover;
};
struct padded_vnet_hdr {
@@ -2275,6 +2281,22 @@ static int virtnet_xdp(struct net_device *dev, struct netdev_bpf *xdp)
}
}
+static int virtnet_get_phys_port_name(struct net_device *dev, char *buf,
+ size_t len)
+{
+ struct virtnet_info *vi = netdev_priv(dev);
+ int ret;
+
+ if (!virtio_has_feature(vi->vdev, VIRTIO_NET_F_STANDBY))
+ return -EOPNOTSUPP;
+
+ ret = snprintf(buf, len, "_sby");
+ if (ret >= len)
+ return -EOPNOTSUPP;
+
+ return 0;
+}
+
static const struct net_device_ops virtnet_netdev = {
.ndo_open = virtnet_open,
.ndo_stop = virtnet_close,
@@ -2292,6 +2314,7 @@ static const struct net_device_ops virtnet_netdev = {
.ndo_xdp_xmit = virtnet_xdp_xmit,
.ndo_xdp_flush = virtnet_xdp_flush,
.ndo_features_check = passthru_features_check,
+ .ndo_get_phys_port_name = virtnet_get_phys_port_name,
};
static void virtnet_config_changed_work(struct work_struct *work)
@@ -2839,10 +2862,16 @@ static int virtnet_probe(struct virtio_device *vdev)
virtnet_init_settings(dev);
+ if (virtio_has_feature(vdev, VIRTIO_NET_F_STANDBY)) {
+ err = failover_create(vi->dev, &vi->failover);
+ if (err)
+ goto free_vqs;
+ }
+
err = register_netdev(dev);
if (err) {
pr_debug("virtio_net: registering device failed\n");
- goto free_vqs;
+ goto free_failover;
}
virtio_device_ready(vdev);
@@ -2879,6 +2908,8 @@ static int virtnet_probe(struct virtio_device *vdev)
vi->vdev->config->reset(vdev);
unregister_netdev(dev);
+free_failover:
+ failover_destroy(vi->failover);
free_vqs:
cancel_delayed_work_sync(&vi->refill);
free_receive_page_frags(vi);
@@ -2913,6 +2944,8 @@ static void virtnet_remove(struct virtio_device *vdev)
unregister_netdev(vi->dev);
+ failover_destroy(vi->failover);
+
remove_vq_common(vi);
free_netdev(vi->dev);
@@ -3010,6 +3043,7 @@ static __init int virtio_net_driver_init(void)
ret = register_virtio_driver(&virtio_net_driver);
if (ret)
goto err_virtio;
+
return 0;
err_virtio:
cpuhp_remove_multi_state(CPUHP_VIRT_NET_DEAD);
--
2.14.3
^ permalink raw reply related [flat|nested] 114+ messages in thread
* [virtio-dev] [PATCH v7 net-next 3/4] virtio_net: Extend virtio to use VF datapath when available
@ 2018-04-20 1:42 ` Sridhar Samudrala
0 siblings, 0 replies; 114+ messages in thread
From: Sridhar Samudrala @ 2018-04-20 1:42 UTC (permalink / raw)
To: mst, stephen, davem, netdev, virtualization, virtio-dev,
jesse.brandeburg, alexander.h.duyck, kubakici, sridhar.samudrala,
jasowang, loseweigh, jiri
This patch enables virtio_net to switch over to a VF datapath when a VF
netdev is present with the same MAC address. It allows live migration
of a VM with a direct attached VF without the need to setup a bond/team
between a VF and virtio net device in the guest.
The hypervisor needs to enable only one datapath at any time so that
packets don't get looped back to the VM over the other datapath. When a VF
is plugged, the virtio datapath link state can be marked as down. The
hypervisor needs to unplug the VF device from the guest on the source host
and reset the MAC filter of the VF to initiate failover of datapath to
virtio before starting the migration. After the migration is completed,
the destination hypervisor sets the MAC filter on the VF and plugs it back
to the guest to switch over to VF datapath.
It uses the generic failover framework that provides 2 functions to create
and destroy a master failover netdev. When STANDBY feature is enabled, an
additional netdev(failover netdev) is created that acts as a master device
and tracks the state of the 2 lower netdevs. The original virtio_net netdev
is marked as 'standby' netdev and a passthru device with the same MAC is
registered as 'primary' netdev.
This patch is based on the discussion initiated by Jesse on this thread.
https://marc.info/?l=linux-virtualization&m=151189725224231&w=2
Signed-off-by: Sridhar Samudrala <sridhar.samudrala@intel.com>
---
drivers/net/Kconfig | 1 +
drivers/net/virtio_net.c | 36 +++++++++++++++++++++++++++++++++++-
2 files changed, 36 insertions(+), 1 deletion(-)
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 891846655000..5abe328973da 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -331,6 +331,7 @@ config VETH
config VIRTIO_NET
tristate "Virtio network driver"
depends on VIRTIO
+ depends on MAY_USE_FAILOVER
---help---
This is the virtual network driver for virtio. It can be used with
QEMU based VMMs (like KVM or Xen). Say Y or M.
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 6f95719ede40..42b9f9bff48b 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -30,8 +30,11 @@
#include <linux/cpu.h>
#include <linux/average.h>
#include <linux/filter.h>
+#include <linux/netdevice.h>
+#include <linux/pci.h>
#include <net/route.h>
#include <net/xdp.h>
+#include <net/failover.h>
static int napi_weight = NAPI_POLL_WEIGHT;
module_param(napi_weight, int, 0444);
@@ -206,6 +209,9 @@ struct virtnet_info {
u32 speed;
unsigned long guest_offloads;
+
+ /* failover when STANDBY feature enabled */
+ struct failover *failover;
};
struct padded_vnet_hdr {
@@ -2275,6 +2281,22 @@ static int virtnet_xdp(struct net_device *dev, struct netdev_bpf *xdp)
}
}
+static int virtnet_get_phys_port_name(struct net_device *dev, char *buf,
+ size_t len)
+{
+ struct virtnet_info *vi = netdev_priv(dev);
+ int ret;
+
+ if (!virtio_has_feature(vi->vdev, VIRTIO_NET_F_STANDBY))
+ return -EOPNOTSUPP;
+
+ ret = snprintf(buf, len, "_sby");
+ if (ret >= len)
+ return -EOPNOTSUPP;
+
+ return 0;
+}
+
static const struct net_device_ops virtnet_netdev = {
.ndo_open = virtnet_open,
.ndo_stop = virtnet_close,
@@ -2292,6 +2314,7 @@ static const struct net_device_ops virtnet_netdev = {
.ndo_xdp_xmit = virtnet_xdp_xmit,
.ndo_xdp_flush = virtnet_xdp_flush,
.ndo_features_check = passthru_features_check,
+ .ndo_get_phys_port_name = virtnet_get_phys_port_name,
};
static void virtnet_config_changed_work(struct work_struct *work)
@@ -2839,10 +2862,16 @@ static int virtnet_probe(struct virtio_device *vdev)
virtnet_init_settings(dev);
+ if (virtio_has_feature(vdev, VIRTIO_NET_F_STANDBY)) {
+ err = failover_create(vi->dev, &vi->failover);
+ if (err)
+ goto free_vqs;
+ }
+
err = register_netdev(dev);
if (err) {
pr_debug("virtio_net: registering device failed\n");
- goto free_vqs;
+ goto free_failover;
}
virtio_device_ready(vdev);
@@ -2879,6 +2908,8 @@ static int virtnet_probe(struct virtio_device *vdev)
vi->vdev->config->reset(vdev);
unregister_netdev(dev);
+free_failover:
+ failover_destroy(vi->failover);
free_vqs:
cancel_delayed_work_sync(&vi->refill);
free_receive_page_frags(vi);
@@ -2913,6 +2944,8 @@ static void virtnet_remove(struct virtio_device *vdev)
unregister_netdev(vi->dev);
+ failover_destroy(vi->failover);
+
remove_vq_common(vi);
free_netdev(vi->dev);
@@ -3010,6 +3043,7 @@ static __init int virtio_net_driver_init(void)
ret = register_virtio_driver(&virtio_net_driver);
if (ret)
goto err_virtio;
+
return 0;
err_virtio:
cpuhp_remove_multi_state(CPUHP_VIRT_NET_DEAD);
--
2.14.3
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply related [flat|nested] 114+ messages in thread
* [PATCH v7 net-next 4/4] netvsc: refactor notifier/event handling code to use the failover framework
2018-04-20 1:42 ` [virtio-dev] " Sridhar Samudrala
@ 2018-04-20 1:42 ` Sridhar Samudrala
-1 siblings, 0 replies; 114+ messages in thread
From: Sridhar Samudrala @ 2018-04-20 1:42 UTC (permalink / raw)
To: mst, stephen, davem, netdev, virtualization, virtio-dev,
jesse.brandeburg, alexander.h.duyck, kubakici, sridhar.samudrala,
jasowang, loseweigh, jiri
Use the registration/notification framework supported by the generic
failover infrastructure.
Signed-off-by: Sridhar Samudrala <sridhar.samudrala@intel.com>
---
drivers/net/hyperv/Kconfig | 1 +
drivers/net/hyperv/hyperv_net.h | 2 +
drivers/net/hyperv/netvsc_drv.c | 208 ++++++++++------------------------------
3 files changed, 55 insertions(+), 156 deletions(-)
diff --git a/drivers/net/hyperv/Kconfig b/drivers/net/hyperv/Kconfig
index 936968d23559..56099d10beed 100644
--- a/drivers/net/hyperv/Kconfig
+++ b/drivers/net/hyperv/Kconfig
@@ -1,5 +1,6 @@
config HYPERV_NET
tristate "Microsoft Hyper-V virtual network driver"
depends on HYPERV
+ depends on MAY_USE_FAILOVER
help
Select this option to enable the Hyper-V virtual network driver.
diff --git a/drivers/net/hyperv/hyperv_net.h b/drivers/net/hyperv/hyperv_net.h
index 960f06141472..d8c2ff698693 100644
--- a/drivers/net/hyperv/hyperv_net.h
+++ b/drivers/net/hyperv/hyperv_net.h
@@ -768,6 +768,8 @@ struct net_device_context {
u32 vf_alloc;
/* Serial number of the VF to team with */
u32 vf_serial;
+
+ struct failover *failover;
};
/* Per channel data */
diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
index ecc84954c511..8404c22de32b 100644
--- a/drivers/net/hyperv/netvsc_drv.c
+++ b/drivers/net/hyperv/netvsc_drv.c
@@ -43,6 +43,7 @@
#include <net/pkt_sched.h>
#include <net/checksum.h>
#include <net/ip6_checksum.h>
+#include <net/failover.h>
#include "hyperv_net.h"
@@ -1763,46 +1764,6 @@ static void netvsc_link_change(struct work_struct *w)
rtnl_unlock();
}
-static struct net_device *get_netvsc_bymac(const u8 *mac)
-{
- struct net_device *dev;
-
- ASSERT_RTNL();
-
- for_each_netdev(&init_net, dev) {
- if (dev->netdev_ops != &device_ops)
- continue; /* not a netvsc device */
-
- if (ether_addr_equal(mac, dev->perm_addr))
- return dev;
- }
-
- return NULL;
-}
-
-static struct net_device *get_netvsc_byref(struct net_device *vf_netdev)
-{
- struct net_device *dev;
-
- ASSERT_RTNL();
-
- for_each_netdev(&init_net, dev) {
- struct net_device_context *net_device_ctx;
-
- if (dev->netdev_ops != &device_ops)
- continue; /* not a netvsc device */
-
- net_device_ctx = netdev_priv(dev);
- if (!rtnl_dereference(net_device_ctx->nvdev))
- continue; /* device is removed */
-
- if (rtnl_dereference(net_device_ctx->vf_netdev) == vf_netdev)
- return dev; /* a match */
- }
-
- return NULL;
-}
-
/* Called when VF is injecting data into network stack.
* Change the associated network device from VF to netvsc.
* note: already called with rcu_read_lock
@@ -1829,39 +1790,15 @@ static int netvsc_vf_join(struct net_device *vf_netdev,
struct net_device *ndev)
{
struct net_device_context *ndev_ctx = netdev_priv(ndev);
- int ret;
-
- ret = netdev_rx_handler_register(vf_netdev,
- netvsc_vf_handle_frame, ndev);
- if (ret != 0) {
- netdev_err(vf_netdev,
- "can not register netvsc VF receive handler (err = %d)\n",
- ret);
- goto rx_handler_failed;
- }
-
- ret = netdev_upper_dev_link(vf_netdev, ndev, NULL);
- if (ret != 0) {
- netdev_err(vf_netdev,
- "can not set master device %s (err = %d)\n",
- ndev->name, ret);
- goto upper_link_failed;
- }
-
- /* set slave flag before open to prevent IPv6 addrconf */
- vf_netdev->flags |= IFF_SLAVE;
schedule_delayed_work(&ndev_ctx->vf_takeover, VF_TAKEOVER_INT);
- call_netdevice_notifiers(NETDEV_JOIN, vf_netdev);
-
netdev_info(vf_netdev, "joined to %s\n", ndev->name);
- return 0;
-upper_link_failed:
- netdev_rx_handler_unregister(vf_netdev);
-rx_handler_failed:
- return ret;
+ dev_hold(vf_netdev);
+ rcu_assign_pointer(ndev_ctx->vf_netdev, vf_netdev);
+
+ return 0;
}
static void __netvsc_vf_setup(struct net_device *ndev,
@@ -1914,85 +1851,82 @@ static void netvsc_vf_setup(struct work_struct *w)
rtnl_unlock();
}
-static int netvsc_register_vf(struct net_device *vf_netdev)
+static int netvsc_vf_pre_register(struct net_device *vf_netdev,
+ struct net_device *ndev)
{
- struct net_device *ndev;
struct net_device_context *net_device_ctx;
struct netvsc_device *netvsc_dev;
- if (vf_netdev->addr_len != ETH_ALEN)
- return NOTIFY_DONE;
-
- /*
- * We will use the MAC address to locate the synthetic interface to
- * associate with the VF interface. If we don't find a matching
- * synthetic interface, move on.
- */
- ndev = get_netvsc_bymac(vf_netdev->perm_addr);
- if (!ndev)
- return NOTIFY_DONE;
-
net_device_ctx = netdev_priv(ndev);
netvsc_dev = rtnl_dereference(net_device_ctx->nvdev);
if (!netvsc_dev || rtnl_dereference(net_device_ctx->vf_netdev))
- return NOTIFY_DONE;
-
- if (netvsc_vf_join(vf_netdev, ndev) != 0)
- return NOTIFY_DONE;
+ return -EEXIST;
netdev_info(ndev, "VF registering: %s\n", vf_netdev->name);
- dev_hold(vf_netdev);
- rcu_assign_pointer(net_device_ctx->vf_netdev, vf_netdev);
- return NOTIFY_OK;
+ return 0;
}
/* VF up/down change detected, schedule to change data path */
-static int netvsc_vf_changed(struct net_device *vf_netdev)
+static int netvsc_vf_changed(struct net_device *vf_netdev,
+ struct net_device *ndev)
{
struct net_device_context *net_device_ctx;
struct netvsc_device *netvsc_dev;
- struct net_device *ndev;
bool vf_is_up = netif_running(vf_netdev);
- ndev = get_netvsc_byref(vf_netdev);
- if (!ndev)
- return NOTIFY_DONE;
-
net_device_ctx = netdev_priv(ndev);
netvsc_dev = rtnl_dereference(net_device_ctx->nvdev);
if (!netvsc_dev)
- return NOTIFY_DONE;
+ return -EINVAL;
netvsc_switch_datapath(ndev, vf_is_up);
netdev_info(ndev, "Data path switched %s VF: %s\n",
vf_is_up ? "to" : "from", vf_netdev->name);
- return NOTIFY_OK;
+ return 0;
}
-static int netvsc_unregister_vf(struct net_device *vf_netdev)
+static int netvsc_vf_release(struct net_device *vf_netdev,
+ struct net_device *ndev)
{
- struct net_device *ndev;
struct net_device_context *net_device_ctx;
- ndev = get_netvsc_byref(vf_netdev);
- if (!ndev)
- return NOTIFY_DONE;
-
net_device_ctx = netdev_priv(ndev);
- cancel_delayed_work_sync(&net_device_ctx->vf_takeover);
+ if (vf_netdev != rtnl_dereference(net_device_ctx->vf_netdev))
+ return -EINVAL;
- netdev_info(ndev, "VF unregistering: %s\n", vf_netdev->name);
+ cancel_delayed_work_sync(&net_device_ctx->vf_takeover);
- netdev_rx_handler_unregister(vf_netdev);
- netdev_upper_dev_unlink(vf_netdev, ndev);
RCU_INIT_POINTER(net_device_ctx->vf_netdev, NULL);
dev_put(vf_netdev);
- return NOTIFY_OK;
+ return 0;
}
+static int netvsc_vf_pre_unregister(struct net_device *vf_netdev,
+ struct net_device *ndev)
+{
+ struct net_device_context *net_device_ctx;
+
+ net_device_ctx = netdev_priv(ndev);
+ if (vf_netdev != rtnl_dereference(net_device_ctx->vf_netdev))
+ return -EINVAL;
+
+ netdev_info(ndev, "VF unregistering: %s\n", vf_netdev->name);
+
+ return 0;
+}
+
+static struct failover_ops netvsc_failover_ops = {
+ .slave_pre_register = netvsc_vf_pre_register,
+ .slave_join = netvsc_vf_join,
+ .slave_pre_unregister = netvsc_vf_pre_unregister,
+ .slave_release = netvsc_vf_release,
+ .slave_link_change = netvsc_vf_changed,
+ .handle_frame = netvsc_vf_handle_frame,
+};
+
static int netvsc_probe(struct hv_device *dev,
const struct hv_vmbus_device_id *dev_id)
{
@@ -2082,8 +2016,15 @@ static int netvsc_probe(struct hv_device *dev,
goto register_failed;
}
+ ret = failover_register(net, &netvsc_failover_ops,
+ &net_device_ctx->failover);
+ if (ret != 0)
+ goto err_failover;
+
return ret;
+err_failover:
+ unregister_netdev(net);
register_failed:
rndis_filter_device_remove(dev, nvdev);
rndis_failed:
@@ -2124,13 +2065,15 @@ static int netvsc_remove(struct hv_device *dev)
rtnl_lock();
vf_netdev = rtnl_dereference(ndev_ctx->vf_netdev);
if (vf_netdev)
- netvsc_unregister_vf(vf_netdev);
+ failover_slave_unregister(vf_netdev);
if (nvdev)
rndis_filter_device_remove(dev, nvdev);
unregister_netdevice(net);
+ failover_unregister(ndev_ctx->failover);
+
rtnl_unlock();
rcu_read_unlock();
@@ -2157,54 +2100,8 @@ static struct hv_driver netvsc_drv = {
.remove = netvsc_remove,
};
-/*
- * On Hyper-V, every VF interface is matched with a corresponding
- * synthetic interface. The synthetic interface is presented first
- * to the guest. When the corresponding VF instance is registered,
- * we will take care of switching the data path.
- */
-static int netvsc_netdev_event(struct notifier_block *this,
- unsigned long event, void *ptr)
-{
- struct net_device *event_dev = netdev_notifier_info_to_dev(ptr);
-
- /* Skip our own events */
- if (event_dev->netdev_ops == &device_ops)
- return NOTIFY_DONE;
-
- /* Avoid non-Ethernet type devices */
- if (event_dev->type != ARPHRD_ETHER)
- return NOTIFY_DONE;
-
- /* Avoid Vlan dev with same MAC registering as VF */
- if (is_vlan_dev(event_dev))
- return NOTIFY_DONE;
-
- /* Avoid Bonding master dev with same MAC registering as VF */
- if ((event_dev->priv_flags & IFF_BONDING) &&
- (event_dev->flags & IFF_MASTER))
- return NOTIFY_DONE;
-
- switch (event) {
- case NETDEV_REGISTER:
- return netvsc_register_vf(event_dev);
- case NETDEV_UNREGISTER:
- return netvsc_unregister_vf(event_dev);
- case NETDEV_UP:
- case NETDEV_DOWN:
- return netvsc_vf_changed(event_dev);
- default:
- return NOTIFY_DONE;
- }
-}
-
-static struct notifier_block netvsc_netdev_notifier = {
- .notifier_call = netvsc_netdev_event,
-};
-
static void __exit netvsc_drv_exit(void)
{
- unregister_netdevice_notifier(&netvsc_netdev_notifier);
vmbus_driver_unregister(&netvsc_drv);
}
@@ -2224,7 +2121,6 @@ static int __init netvsc_drv_init(void)
if (ret)
return ret;
- register_netdevice_notifier(&netvsc_netdev_notifier);
return 0;
}
--
2.14.3
^ permalink raw reply related [flat|nested] 114+ messages in thread
* [PATCH v7 net-next 4/4] netvsc: refactor notifier/event handling code to use the failover framework
2018-04-20 1:42 ` [virtio-dev] " Sridhar Samudrala
` (6 preceding siblings ...)
(?)
@ 2018-04-20 1:42 ` Sridhar Samudrala
-1 siblings, 0 replies; 114+ messages in thread
From: Sridhar Samudrala @ 2018-04-20 1:42 UTC (permalink / raw)
To: mst, stephen, davem, netdev, virtualization, virtio-dev,
jesse.brandeburg, alexander.h.duyck, kubakici, sridhar.samudrala,
jasowang, loseweigh, jiri
Use the registration/notification framework supported by the generic
failover infrastructure.
Signed-off-by: Sridhar Samudrala <sridhar.samudrala@intel.com>
---
drivers/net/hyperv/Kconfig | 1 +
drivers/net/hyperv/hyperv_net.h | 2 +
drivers/net/hyperv/netvsc_drv.c | 208 ++++++++++------------------------------
3 files changed, 55 insertions(+), 156 deletions(-)
diff --git a/drivers/net/hyperv/Kconfig b/drivers/net/hyperv/Kconfig
index 936968d23559..56099d10beed 100644
--- a/drivers/net/hyperv/Kconfig
+++ b/drivers/net/hyperv/Kconfig
@@ -1,5 +1,6 @@
config HYPERV_NET
tristate "Microsoft Hyper-V virtual network driver"
depends on HYPERV
+ depends on MAY_USE_FAILOVER
help
Select this option to enable the Hyper-V virtual network driver.
diff --git a/drivers/net/hyperv/hyperv_net.h b/drivers/net/hyperv/hyperv_net.h
index 960f06141472..d8c2ff698693 100644
--- a/drivers/net/hyperv/hyperv_net.h
+++ b/drivers/net/hyperv/hyperv_net.h
@@ -768,6 +768,8 @@ struct net_device_context {
u32 vf_alloc;
/* Serial number of the VF to team with */
u32 vf_serial;
+
+ struct failover *failover;
};
/* Per channel data */
diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
index ecc84954c511..8404c22de32b 100644
--- a/drivers/net/hyperv/netvsc_drv.c
+++ b/drivers/net/hyperv/netvsc_drv.c
@@ -43,6 +43,7 @@
#include <net/pkt_sched.h>
#include <net/checksum.h>
#include <net/ip6_checksum.h>
+#include <net/failover.h>
#include "hyperv_net.h"
@@ -1763,46 +1764,6 @@ static void netvsc_link_change(struct work_struct *w)
rtnl_unlock();
}
-static struct net_device *get_netvsc_bymac(const u8 *mac)
-{
- struct net_device *dev;
-
- ASSERT_RTNL();
-
- for_each_netdev(&init_net, dev) {
- if (dev->netdev_ops != &device_ops)
- continue; /* not a netvsc device */
-
- if (ether_addr_equal(mac, dev->perm_addr))
- return dev;
- }
-
- return NULL;
-}
-
-static struct net_device *get_netvsc_byref(struct net_device *vf_netdev)
-{
- struct net_device *dev;
-
- ASSERT_RTNL();
-
- for_each_netdev(&init_net, dev) {
- struct net_device_context *net_device_ctx;
-
- if (dev->netdev_ops != &device_ops)
- continue; /* not a netvsc device */
-
- net_device_ctx = netdev_priv(dev);
- if (!rtnl_dereference(net_device_ctx->nvdev))
- continue; /* device is removed */
-
- if (rtnl_dereference(net_device_ctx->vf_netdev) == vf_netdev)
- return dev; /* a match */
- }
-
- return NULL;
-}
-
/* Called when VF is injecting data into network stack.
* Change the associated network device from VF to netvsc.
* note: already called with rcu_read_lock
@@ -1829,39 +1790,15 @@ static int netvsc_vf_join(struct net_device *vf_netdev,
struct net_device *ndev)
{
struct net_device_context *ndev_ctx = netdev_priv(ndev);
- int ret;
-
- ret = netdev_rx_handler_register(vf_netdev,
- netvsc_vf_handle_frame, ndev);
- if (ret != 0) {
- netdev_err(vf_netdev,
- "can not register netvsc VF receive handler (err = %d)\n",
- ret);
- goto rx_handler_failed;
- }
-
- ret = netdev_upper_dev_link(vf_netdev, ndev, NULL);
- if (ret != 0) {
- netdev_err(vf_netdev,
- "can not set master device %s (err = %d)\n",
- ndev->name, ret);
- goto upper_link_failed;
- }
-
- /* set slave flag before open to prevent IPv6 addrconf */
- vf_netdev->flags |= IFF_SLAVE;
schedule_delayed_work(&ndev_ctx->vf_takeover, VF_TAKEOVER_INT);
- call_netdevice_notifiers(NETDEV_JOIN, vf_netdev);
-
netdev_info(vf_netdev, "joined to %s\n", ndev->name);
- return 0;
-upper_link_failed:
- netdev_rx_handler_unregister(vf_netdev);
-rx_handler_failed:
- return ret;
+ dev_hold(vf_netdev);
+ rcu_assign_pointer(ndev_ctx->vf_netdev, vf_netdev);
+
+ return 0;
}
static void __netvsc_vf_setup(struct net_device *ndev,
@@ -1914,85 +1851,82 @@ static void netvsc_vf_setup(struct work_struct *w)
rtnl_unlock();
}
-static int netvsc_register_vf(struct net_device *vf_netdev)
+static int netvsc_vf_pre_register(struct net_device *vf_netdev,
+ struct net_device *ndev)
{
- struct net_device *ndev;
struct net_device_context *net_device_ctx;
struct netvsc_device *netvsc_dev;
- if (vf_netdev->addr_len != ETH_ALEN)
- return NOTIFY_DONE;
-
- /*
- * We will use the MAC address to locate the synthetic interface to
- * associate with the VF interface. If we don't find a matching
- * synthetic interface, move on.
- */
- ndev = get_netvsc_bymac(vf_netdev->perm_addr);
- if (!ndev)
- return NOTIFY_DONE;
-
net_device_ctx = netdev_priv(ndev);
netvsc_dev = rtnl_dereference(net_device_ctx->nvdev);
if (!netvsc_dev || rtnl_dereference(net_device_ctx->vf_netdev))
- return NOTIFY_DONE;
-
- if (netvsc_vf_join(vf_netdev, ndev) != 0)
- return NOTIFY_DONE;
+ return -EEXIST;
netdev_info(ndev, "VF registering: %s\n", vf_netdev->name);
- dev_hold(vf_netdev);
- rcu_assign_pointer(net_device_ctx->vf_netdev, vf_netdev);
- return NOTIFY_OK;
+ return 0;
}
/* VF up/down change detected, schedule to change data path */
-static int netvsc_vf_changed(struct net_device *vf_netdev)
+static int netvsc_vf_changed(struct net_device *vf_netdev,
+ struct net_device *ndev)
{
struct net_device_context *net_device_ctx;
struct netvsc_device *netvsc_dev;
- struct net_device *ndev;
bool vf_is_up = netif_running(vf_netdev);
- ndev = get_netvsc_byref(vf_netdev);
- if (!ndev)
- return NOTIFY_DONE;
-
net_device_ctx = netdev_priv(ndev);
netvsc_dev = rtnl_dereference(net_device_ctx->nvdev);
if (!netvsc_dev)
- return NOTIFY_DONE;
+ return -EINVAL;
netvsc_switch_datapath(ndev, vf_is_up);
netdev_info(ndev, "Data path switched %s VF: %s\n",
vf_is_up ? "to" : "from", vf_netdev->name);
- return NOTIFY_OK;
+ return 0;
}
-static int netvsc_unregister_vf(struct net_device *vf_netdev)
+static int netvsc_vf_release(struct net_device *vf_netdev,
+ struct net_device *ndev)
{
- struct net_device *ndev;
struct net_device_context *net_device_ctx;
- ndev = get_netvsc_byref(vf_netdev);
- if (!ndev)
- return NOTIFY_DONE;
-
net_device_ctx = netdev_priv(ndev);
- cancel_delayed_work_sync(&net_device_ctx->vf_takeover);
+ if (vf_netdev != rtnl_dereference(net_device_ctx->vf_netdev))
+ return -EINVAL;
- netdev_info(ndev, "VF unregistering: %s\n", vf_netdev->name);
+ cancel_delayed_work_sync(&net_device_ctx->vf_takeover);
- netdev_rx_handler_unregister(vf_netdev);
- netdev_upper_dev_unlink(vf_netdev, ndev);
RCU_INIT_POINTER(net_device_ctx->vf_netdev, NULL);
dev_put(vf_netdev);
- return NOTIFY_OK;
+ return 0;
}
+static int netvsc_vf_pre_unregister(struct net_device *vf_netdev,
+ struct net_device *ndev)
+{
+ struct net_device_context *net_device_ctx;
+
+ net_device_ctx = netdev_priv(ndev);
+ if (vf_netdev != rtnl_dereference(net_device_ctx->vf_netdev))
+ return -EINVAL;
+
+ netdev_info(ndev, "VF unregistering: %s\n", vf_netdev->name);
+
+ return 0;
+}
+
+static struct failover_ops netvsc_failover_ops = {
+ .slave_pre_register = netvsc_vf_pre_register,
+ .slave_join = netvsc_vf_join,
+ .slave_pre_unregister = netvsc_vf_pre_unregister,
+ .slave_release = netvsc_vf_release,
+ .slave_link_change = netvsc_vf_changed,
+ .handle_frame = netvsc_vf_handle_frame,
+};
+
static int netvsc_probe(struct hv_device *dev,
const struct hv_vmbus_device_id *dev_id)
{
@@ -2082,8 +2016,15 @@ static int netvsc_probe(struct hv_device *dev,
goto register_failed;
}
+ ret = failover_register(net, &netvsc_failover_ops,
+ &net_device_ctx->failover);
+ if (ret != 0)
+ goto err_failover;
+
return ret;
+err_failover:
+ unregister_netdev(net);
register_failed:
rndis_filter_device_remove(dev, nvdev);
rndis_failed:
@@ -2124,13 +2065,15 @@ static int netvsc_remove(struct hv_device *dev)
rtnl_lock();
vf_netdev = rtnl_dereference(ndev_ctx->vf_netdev);
if (vf_netdev)
- netvsc_unregister_vf(vf_netdev);
+ failover_slave_unregister(vf_netdev);
if (nvdev)
rndis_filter_device_remove(dev, nvdev);
unregister_netdevice(net);
+ failover_unregister(ndev_ctx->failover);
+
rtnl_unlock();
rcu_read_unlock();
@@ -2157,54 +2100,8 @@ static struct hv_driver netvsc_drv = {
.remove = netvsc_remove,
};
-/*
- * On Hyper-V, every VF interface is matched with a corresponding
- * synthetic interface. The synthetic interface is presented first
- * to the guest. When the corresponding VF instance is registered,
- * we will take care of switching the data path.
- */
-static int netvsc_netdev_event(struct notifier_block *this,
- unsigned long event, void *ptr)
-{
- struct net_device *event_dev = netdev_notifier_info_to_dev(ptr);
-
- /* Skip our own events */
- if (event_dev->netdev_ops == &device_ops)
- return NOTIFY_DONE;
-
- /* Avoid non-Ethernet type devices */
- if (event_dev->type != ARPHRD_ETHER)
- return NOTIFY_DONE;
-
- /* Avoid Vlan dev with same MAC registering as VF */
- if (is_vlan_dev(event_dev))
- return NOTIFY_DONE;
-
- /* Avoid Bonding master dev with same MAC registering as VF */
- if ((event_dev->priv_flags & IFF_BONDING) &&
- (event_dev->flags & IFF_MASTER))
- return NOTIFY_DONE;
-
- switch (event) {
- case NETDEV_REGISTER:
- return netvsc_register_vf(event_dev);
- case NETDEV_UNREGISTER:
- return netvsc_unregister_vf(event_dev);
- case NETDEV_UP:
- case NETDEV_DOWN:
- return netvsc_vf_changed(event_dev);
- default:
- return NOTIFY_DONE;
- }
-}
-
-static struct notifier_block netvsc_netdev_notifier = {
- .notifier_call = netvsc_netdev_event,
-};
-
static void __exit netvsc_drv_exit(void)
{
- unregister_netdevice_notifier(&netvsc_netdev_notifier);
vmbus_driver_unregister(&netvsc_drv);
}
@@ -2224,7 +2121,6 @@ static int __init netvsc_drv_init(void)
if (ret)
return ret;
- register_netdevice_notifier(&netvsc_netdev_notifier);
return 0;
}
--
2.14.3
^ permalink raw reply related [flat|nested] 114+ messages in thread
* [virtio-dev] [PATCH v7 net-next 4/4] netvsc: refactor notifier/event handling code to use the failover framework
@ 2018-04-20 1:42 ` Sridhar Samudrala
0 siblings, 0 replies; 114+ messages in thread
From: Sridhar Samudrala @ 2018-04-20 1:42 UTC (permalink / raw)
To: mst, stephen, davem, netdev, virtualization, virtio-dev,
jesse.brandeburg, alexander.h.duyck, kubakici, sridhar.samudrala,
jasowang, loseweigh, jiri
Use the registration/notification framework supported by the generic
failover infrastructure.
Signed-off-by: Sridhar Samudrala <sridhar.samudrala@intel.com>
---
drivers/net/hyperv/Kconfig | 1 +
drivers/net/hyperv/hyperv_net.h | 2 +
drivers/net/hyperv/netvsc_drv.c | 208 ++++++++++------------------------------
3 files changed, 55 insertions(+), 156 deletions(-)
diff --git a/drivers/net/hyperv/Kconfig b/drivers/net/hyperv/Kconfig
index 936968d23559..56099d10beed 100644
--- a/drivers/net/hyperv/Kconfig
+++ b/drivers/net/hyperv/Kconfig
@@ -1,5 +1,6 @@
config HYPERV_NET
tristate "Microsoft Hyper-V virtual network driver"
depends on HYPERV
+ depends on MAY_USE_FAILOVER
help
Select this option to enable the Hyper-V virtual network driver.
diff --git a/drivers/net/hyperv/hyperv_net.h b/drivers/net/hyperv/hyperv_net.h
index 960f06141472..d8c2ff698693 100644
--- a/drivers/net/hyperv/hyperv_net.h
+++ b/drivers/net/hyperv/hyperv_net.h
@@ -768,6 +768,8 @@ struct net_device_context {
u32 vf_alloc;
/* Serial number of the VF to team with */
u32 vf_serial;
+
+ struct failover *failover;
};
/* Per channel data */
diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
index ecc84954c511..8404c22de32b 100644
--- a/drivers/net/hyperv/netvsc_drv.c
+++ b/drivers/net/hyperv/netvsc_drv.c
@@ -43,6 +43,7 @@
#include <net/pkt_sched.h>
#include <net/checksum.h>
#include <net/ip6_checksum.h>
+#include <net/failover.h>
#include "hyperv_net.h"
@@ -1763,46 +1764,6 @@ static void netvsc_link_change(struct work_struct *w)
rtnl_unlock();
}
-static struct net_device *get_netvsc_bymac(const u8 *mac)
-{
- struct net_device *dev;
-
- ASSERT_RTNL();
-
- for_each_netdev(&init_net, dev) {
- if (dev->netdev_ops != &device_ops)
- continue; /* not a netvsc device */
-
- if (ether_addr_equal(mac, dev->perm_addr))
- return dev;
- }
-
- return NULL;
-}
-
-static struct net_device *get_netvsc_byref(struct net_device *vf_netdev)
-{
- struct net_device *dev;
-
- ASSERT_RTNL();
-
- for_each_netdev(&init_net, dev) {
- struct net_device_context *net_device_ctx;
-
- if (dev->netdev_ops != &device_ops)
- continue; /* not a netvsc device */
-
- net_device_ctx = netdev_priv(dev);
- if (!rtnl_dereference(net_device_ctx->nvdev))
- continue; /* device is removed */
-
- if (rtnl_dereference(net_device_ctx->vf_netdev) == vf_netdev)
- return dev; /* a match */
- }
-
- return NULL;
-}
-
/* Called when VF is injecting data into network stack.
* Change the associated network device from VF to netvsc.
* note: already called with rcu_read_lock
@@ -1829,39 +1790,15 @@ static int netvsc_vf_join(struct net_device *vf_netdev,
struct net_device *ndev)
{
struct net_device_context *ndev_ctx = netdev_priv(ndev);
- int ret;
-
- ret = netdev_rx_handler_register(vf_netdev,
- netvsc_vf_handle_frame, ndev);
- if (ret != 0) {
- netdev_err(vf_netdev,
- "can not register netvsc VF receive handler (err = %d)\n",
- ret);
- goto rx_handler_failed;
- }
-
- ret = netdev_upper_dev_link(vf_netdev, ndev, NULL);
- if (ret != 0) {
- netdev_err(vf_netdev,
- "can not set master device %s (err = %d)\n",
- ndev->name, ret);
- goto upper_link_failed;
- }
-
- /* set slave flag before open to prevent IPv6 addrconf */
- vf_netdev->flags |= IFF_SLAVE;
schedule_delayed_work(&ndev_ctx->vf_takeover, VF_TAKEOVER_INT);
- call_netdevice_notifiers(NETDEV_JOIN, vf_netdev);
-
netdev_info(vf_netdev, "joined to %s\n", ndev->name);
- return 0;
-upper_link_failed:
- netdev_rx_handler_unregister(vf_netdev);
-rx_handler_failed:
- return ret;
+ dev_hold(vf_netdev);
+ rcu_assign_pointer(ndev_ctx->vf_netdev, vf_netdev);
+
+ return 0;
}
static void __netvsc_vf_setup(struct net_device *ndev,
@@ -1914,85 +1851,82 @@ static void netvsc_vf_setup(struct work_struct *w)
rtnl_unlock();
}
-static int netvsc_register_vf(struct net_device *vf_netdev)
+static int netvsc_vf_pre_register(struct net_device *vf_netdev,
+ struct net_device *ndev)
{
- struct net_device *ndev;
struct net_device_context *net_device_ctx;
struct netvsc_device *netvsc_dev;
- if (vf_netdev->addr_len != ETH_ALEN)
- return NOTIFY_DONE;
-
- /*
- * We will use the MAC address to locate the synthetic interface to
- * associate with the VF interface. If we don't find a matching
- * synthetic interface, move on.
- */
- ndev = get_netvsc_bymac(vf_netdev->perm_addr);
- if (!ndev)
- return NOTIFY_DONE;
-
net_device_ctx = netdev_priv(ndev);
netvsc_dev = rtnl_dereference(net_device_ctx->nvdev);
if (!netvsc_dev || rtnl_dereference(net_device_ctx->vf_netdev))
- return NOTIFY_DONE;
-
- if (netvsc_vf_join(vf_netdev, ndev) != 0)
- return NOTIFY_DONE;
+ return -EEXIST;
netdev_info(ndev, "VF registering: %s\n", vf_netdev->name);
- dev_hold(vf_netdev);
- rcu_assign_pointer(net_device_ctx->vf_netdev, vf_netdev);
- return NOTIFY_OK;
+ return 0;
}
/* VF up/down change detected, schedule to change data path */
-static int netvsc_vf_changed(struct net_device *vf_netdev)
+static int netvsc_vf_changed(struct net_device *vf_netdev,
+ struct net_device *ndev)
{
struct net_device_context *net_device_ctx;
struct netvsc_device *netvsc_dev;
- struct net_device *ndev;
bool vf_is_up = netif_running(vf_netdev);
- ndev = get_netvsc_byref(vf_netdev);
- if (!ndev)
- return NOTIFY_DONE;
-
net_device_ctx = netdev_priv(ndev);
netvsc_dev = rtnl_dereference(net_device_ctx->nvdev);
if (!netvsc_dev)
- return NOTIFY_DONE;
+ return -EINVAL;
netvsc_switch_datapath(ndev, vf_is_up);
netdev_info(ndev, "Data path switched %s VF: %s\n",
vf_is_up ? "to" : "from", vf_netdev->name);
- return NOTIFY_OK;
+ return 0;
}
-static int netvsc_unregister_vf(struct net_device *vf_netdev)
+static int netvsc_vf_release(struct net_device *vf_netdev,
+ struct net_device *ndev)
{
- struct net_device *ndev;
struct net_device_context *net_device_ctx;
- ndev = get_netvsc_byref(vf_netdev);
- if (!ndev)
- return NOTIFY_DONE;
-
net_device_ctx = netdev_priv(ndev);
- cancel_delayed_work_sync(&net_device_ctx->vf_takeover);
+ if (vf_netdev != rtnl_dereference(net_device_ctx->vf_netdev))
+ return -EINVAL;
- netdev_info(ndev, "VF unregistering: %s\n", vf_netdev->name);
+ cancel_delayed_work_sync(&net_device_ctx->vf_takeover);
- netdev_rx_handler_unregister(vf_netdev);
- netdev_upper_dev_unlink(vf_netdev, ndev);
RCU_INIT_POINTER(net_device_ctx->vf_netdev, NULL);
dev_put(vf_netdev);
- return NOTIFY_OK;
+ return 0;
}
+static int netvsc_vf_pre_unregister(struct net_device *vf_netdev,
+ struct net_device *ndev)
+{
+ struct net_device_context *net_device_ctx;
+
+ net_device_ctx = netdev_priv(ndev);
+ if (vf_netdev != rtnl_dereference(net_device_ctx->vf_netdev))
+ return -EINVAL;
+
+ netdev_info(ndev, "VF unregistering: %s\n", vf_netdev->name);
+
+ return 0;
+}
+
+static struct failover_ops netvsc_failover_ops = {
+ .slave_pre_register = netvsc_vf_pre_register,
+ .slave_join = netvsc_vf_join,
+ .slave_pre_unregister = netvsc_vf_pre_unregister,
+ .slave_release = netvsc_vf_release,
+ .slave_link_change = netvsc_vf_changed,
+ .handle_frame = netvsc_vf_handle_frame,
+};
+
static int netvsc_probe(struct hv_device *dev,
const struct hv_vmbus_device_id *dev_id)
{
@@ -2082,8 +2016,15 @@ static int netvsc_probe(struct hv_device *dev,
goto register_failed;
}
+ ret = failover_register(net, &netvsc_failover_ops,
+ &net_device_ctx->failover);
+ if (ret != 0)
+ goto err_failover;
+
return ret;
+err_failover:
+ unregister_netdev(net);
register_failed:
rndis_filter_device_remove(dev, nvdev);
rndis_failed:
@@ -2124,13 +2065,15 @@ static int netvsc_remove(struct hv_device *dev)
rtnl_lock();
vf_netdev = rtnl_dereference(ndev_ctx->vf_netdev);
if (vf_netdev)
- netvsc_unregister_vf(vf_netdev);
+ failover_slave_unregister(vf_netdev);
if (nvdev)
rndis_filter_device_remove(dev, nvdev);
unregister_netdevice(net);
+ failover_unregister(ndev_ctx->failover);
+
rtnl_unlock();
rcu_read_unlock();
@@ -2157,54 +2100,8 @@ static struct hv_driver netvsc_drv = {
.remove = netvsc_remove,
};
-/*
- * On Hyper-V, every VF interface is matched with a corresponding
- * synthetic interface. The synthetic interface is presented first
- * to the guest. When the corresponding VF instance is registered,
- * we will take care of switching the data path.
- */
-static int netvsc_netdev_event(struct notifier_block *this,
- unsigned long event, void *ptr)
-{
- struct net_device *event_dev = netdev_notifier_info_to_dev(ptr);
-
- /* Skip our own events */
- if (event_dev->netdev_ops == &device_ops)
- return NOTIFY_DONE;
-
- /* Avoid non-Ethernet type devices */
- if (event_dev->type != ARPHRD_ETHER)
- return NOTIFY_DONE;
-
- /* Avoid Vlan dev with same MAC registering as VF */
- if (is_vlan_dev(event_dev))
- return NOTIFY_DONE;
-
- /* Avoid Bonding master dev with same MAC registering as VF */
- if ((event_dev->priv_flags & IFF_BONDING) &&
- (event_dev->flags & IFF_MASTER))
- return NOTIFY_DONE;
-
- switch (event) {
- case NETDEV_REGISTER:
- return netvsc_register_vf(event_dev);
- case NETDEV_UNREGISTER:
- return netvsc_unregister_vf(event_dev);
- case NETDEV_UP:
- case NETDEV_DOWN:
- return netvsc_vf_changed(event_dev);
- default:
- return NOTIFY_DONE;
- }
-}
-
-static struct notifier_block netvsc_netdev_notifier = {
- .notifier_call = netvsc_netdev_event,
-};
-
static void __exit netvsc_drv_exit(void)
{
- unregister_netdevice_notifier(&netvsc_netdev_notifier);
vmbus_driver_unregister(&netvsc_drv);
}
@@ -2224,7 +2121,6 @@ static int __init netvsc_drv_init(void)
if (ret)
return ret;
- register_netdevice_notifier(&netvsc_netdev_notifier);
return 0;
}
--
2.14.3
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply related [flat|nested] 114+ messages in thread
* Re: [PATCH v7 net-next 2/4] net: Introduce generic failover module
2018-04-20 1:42 ` [virtio-dev] " Sridhar Samudrala
@ 2018-04-20 2:44 ` Michael S. Tsirkin
-1 siblings, 0 replies; 114+ messages in thread
From: Michael S. Tsirkin @ 2018-04-20 2:44 UTC (permalink / raw)
To: Sridhar Samudrala
Cc: stephen, davem, netdev, virtualization, virtio-dev,
jesse.brandeburg, alexander.h.duyck, kubakici, jasowang,
loseweigh, jiri
On Thu, Apr 19, 2018 at 06:42:02PM -0700, Sridhar Samudrala wrote:
> This provides a generic interface for paravirtual drivers to listen
> for netdev register/unregister/link change events from pci ethernet
> devices with the same MAC and takeover their datapath. The notifier and
> event handling code is based on the existing netvsc implementation.
>
> It exposes 2 sets of interfaces to the paravirtual drivers.
> 1. existing netvsc driver that uses 2 netdev model. In this model, no
> master netdev is created. The paravirtual driver registers each instance
> of netvsc as a 'failover' instance along with a set of ops to manage the
> slave events.
> failover_register()
> failover_unregister()
> 2. new virtio_net based solution that uses 3 netdev model. In this model,
> the failover module provides interfaces to create/destroy additional master
> netdev and all the slave events are managed internally.
> failover_create()
> failover_destroy()
> These functions call failover_register()/failover_unregister() with the
> master netdev created by the failover module.
>
> Signed-off-by: Sridhar Samudrala <sridhar.samudrala@intel.com>
I like this patch. Yes something to improve (see below)
> ---
> include/linux/netdevice.h | 16 +
> include/net/failover.h | 96 ++++++
> net/Kconfig | 18 +
> net/core/Makefile | 1 +
> net/core/failover.c | 844 ++++++++++++++++++++++++++++++++++++++++++++++
> 5 files changed, 975 insertions(+)
> create mode 100644 include/net/failover.h
> create mode 100644 net/core/failover.c
>
> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> index cf44503ea81a..ed535b6724e1 100644
> --- a/include/linux/netdevice.h
> +++ b/include/linux/netdevice.h
> @@ -1401,6 +1401,8 @@ struct net_device_ops {
> * entity (i.e. the master device for bridged veth)
> * @IFF_MACSEC: device is a MACsec device
> * @IFF_NO_RX_HANDLER: device doesn't support the rx_handler hook
> + * @IFF_FAILOVER: device is a failover master device
> + * @IFF_FAILOVER_SLAVE: device is lower dev of a failover master device
> */
> enum netdev_priv_flags {
> IFF_802_1Q_VLAN = 1<<0,
> @@ -1430,6 +1432,8 @@ enum netdev_priv_flags {
> IFF_PHONY_HEADROOM = 1<<24,
> IFF_MACSEC = 1<<25,
> IFF_NO_RX_HANDLER = 1<<26,
> + IFF_FAILOVER = 1<<27,
> + IFF_FAILOVER_SLAVE = 1<<28,
> };
>
> #define IFF_802_1Q_VLAN IFF_802_1Q_VLAN
> @@ -1458,6 +1462,8 @@ enum netdev_priv_flags {
> #define IFF_RXFH_CONFIGURED IFF_RXFH_CONFIGURED
> #define IFF_MACSEC IFF_MACSEC
> #define IFF_NO_RX_HANDLER IFF_NO_RX_HANDLER
> +#define IFF_FAILOVER IFF_FAILOVER
> +#define IFF_FAILOVER_SLAVE IFF_FAILOVER_SLAVE
>
> /**
> * struct net_device - The DEVICE structure.
> @@ -4308,6 +4314,16 @@ static inline bool netif_is_rxfh_configured(const struct net_device *dev)
> return dev->priv_flags & IFF_RXFH_CONFIGURED;
> }
>
> +static inline bool netif_is_failover(const struct net_device *dev)
> +{
> + return dev->priv_flags & IFF_FAILOVER;
> +}
> +
> +static inline bool netif_is_failover_slave(const struct net_device *dev)
> +{
> + return dev->priv_flags & IFF_FAILOVER_SLAVE;
> +}
> +
> /* This device needs to keep skb dst for qdisc enqueue or ndo_start_xmit() */
> static inline void netif_keep_dst(struct net_device *dev)
> {
> diff --git a/include/net/failover.h b/include/net/failover.h
> new file mode 100644
> index 000000000000..0b8601043d90
> --- /dev/null
> +++ b/include/net/failover.h
> @@ -0,0 +1,96 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/* Copyright (c) 2018, Intel Corporation. */
> +
> +#ifndef _NET_FAILOVER_H
> +#define _NET_FAILOVER_H
> +
> +#include <linux/netdevice.h>
> +
> +struct failover_ops {
> + int (*slave_pre_register)(struct net_device *slave_dev,
> + struct net_device *failover_dev);
> + int (*slave_join)(struct net_device *slave_dev,
> + struct net_device *failover_dev);
> + int (*slave_pre_unregister)(struct net_device *slave_dev,
> + struct net_device *failover_dev);
> + int (*slave_release)(struct net_device *slave_dev,
> + struct net_device *failover_dev);
> + int (*slave_link_change)(struct net_device *slave_dev,
> + struct net_device *failover_dev);
> + rx_handler_result_t (*handle_frame)(struct sk_buff **pskb);
> +};
> +
> +struct failover {
> + struct list_head list;
> + struct net_device __rcu *failover_dev;
> + struct failover_ops __rcu *ops;
> +};
> +
> +/* failover state */
> +struct failover_info {
> + /* primary netdev with same MAC */
> + struct net_device __rcu *primary_dev;
> +
> + /* standby netdev */
> + struct net_device __rcu *standby_dev;
> +
> + /* primary netdev stats */
> + struct rtnl_link_stats64 primary_stats;
> +
> + /* standby netdev stats */
> + struct rtnl_link_stats64 standby_stats;
> +
> + /* aggregated stats */
> + struct rtnl_link_stats64 failover_stats;
> +
> + /* spinlock while updating stats */
> + spinlock_t stats_lock;
> +};
> +
> +#if IS_ENABLED(CONFIG_NET_FAILOVER)
> +
> +int failover_create(struct net_device *standby_dev,
> + struct failover **pfailover);
> +void failover_destroy(struct failover *failover);
> +
> +int failover_register(struct net_device *standby_dev, struct failover_ops *ops,
> + struct failover **pfailover);
> +void failover_unregister(struct failover *failover);
> +
> +int failover_slave_unregister(struct net_device *slave_dev);
> +
> +#else
> +
> +static inline
> +int failover_create(struct net_device *standby_dev,
> + struct failover **pfailover);
> +{
> + return 0;
> +}
> +
> +static inline
> +void failover_destroy(struct failover *failover)
> +{
> +}
> +
> +static inline
> +int failover_register(struct net_device *standby_dev, struct failover_ops *ops,
> + struct pfailover **pfailover);
> +{
> + return 0;
> +}
> +
> +static inline
> +void failover_unregister(struct failover *failover)
> +{
> +}
> +
> +static inline
> +int failover_slave_unregister(struct net_device *slave_dev)
> +{
> + return 0;
> +}
> +
> +#endif
> +
> +#endif /* _NET_FAILOVER_H */
> diff --git a/net/Kconfig b/net/Kconfig
> index 0428f12c25c2..388b99dfee10 100644
> --- a/net/Kconfig
> +++ b/net/Kconfig
> @@ -423,6 +423,24 @@ config MAY_USE_DEVLINK
> on MAY_USE_DEVLINK to ensure they do not cause link errors when
> devlink is a loadable module and the driver using it is built-in.
>
> +config NET_FAILOVER
> + tristate "Failover interface"
> + help
> + This provides a generic interface for paravirtual drivers to listen
> + for netdev register/unregister/link change events from pci ethernet
> + devices with the same MAC and takeover their datapath. This also
> + enables live migration of a VM with direct attached VF by failing
> + over to the paravirtual datapath when the VF is unplugged.
> +
> +config MAY_USE_FAILOVER
> + tristate
> + default m if NET_FAILOVER=m
> + default y if NET_FAILOVER=y || NET_FAILOVER=n
> + help
> + Drivers using the failover infrastructure should have a dependency
> + on MAY_USE_FAILOVER to ensure they do not cause link errors when
> + failover is a loadable module and the driver using it is built-in.
> +
> endif # if NET
>
> # Used by archs to tell that they support BPF JIT compiler plus which flavour.
> diff --git a/net/core/Makefile b/net/core/Makefile
> index 6dbbba8c57ae..cef17518bb7d 100644
> --- a/net/core/Makefile
> +++ b/net/core/Makefile
> @@ -30,3 +30,4 @@ obj-$(CONFIG_DST_CACHE) += dst_cache.o
> obj-$(CONFIG_HWBM) += hwbm.o
> obj-$(CONFIG_NET_DEVLINK) += devlink.o
> obj-$(CONFIG_GRO_CELLS) += gro_cells.o
> +obj-$(CONFIG_NET_FAILOVER) += failover.o
> diff --git a/net/core/failover.c b/net/core/failover.c
> new file mode 100644
> index 000000000000..7bee762cb737
> --- /dev/null
> +++ b/net/core/failover.c
> @@ -0,0 +1,844 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/* Copyright (c) 2018, Intel Corporation. */
I think you should copy the header from bond_main.c upon which
some of the code seems to be based.
> +
> +/* A common module to handle registrations and notifications for paravirtual
> + * drivers to enable accelerated datapath and support VF live migration.
> + *
> + * The notifier and event handling code is based on netvsc driver.
> + */
> +
> +#include <linux/netdevice.h>
> +#include <linux/etherdevice.h>
> +#include <linux/ethtool.h>
> +#include <linux/module.h>
> +#include <linux/slab.h>
> +#include <linux/netdevice.h>
> +#include <linux/netpoll.h>
> +#include <linux/rtnetlink.h>
> +#include <linux/if_vlan.h>
> +#include <linux/pci.h>
> +#include <net/sch_generic.h>
> +#include <uapi/linux/if_arp.h>
> +#include <net/failover.h>
> +
> +static LIST_HEAD(failover_list);
> +static DEFINE_SPINLOCK(failover_lock);
> +
> +static int failover_slave_pre_register(struct net_device *slave_dev,
> + struct net_device *failover_dev,
> + struct failover_ops *failover_ops)
> +{
> + struct failover_info *finfo;
> + bool standby;
> +
> + if (failover_ops) {
> + if (!failover_ops->slave_pre_register)
> + return -EINVAL;
> +
> + return failover_ops->slave_pre_register(slave_dev,
> + failover_dev);
> + }
> +
> + finfo = netdev_priv(failover_dev);
> + standby = (slave_dev->dev.parent == failover_dev->dev.parent);
> + if (standby ? rtnl_dereference(finfo->standby_dev) :
> + rtnl_dereference(finfo->primary_dev)) {
> + netdev_err(failover_dev, "%s attempting to register as slave dev when %s already present\n",
> + slave_dev->name, standby ? "standby" : "primary");
> + return -EEXIST;
> + }
> +
> + /* Avoid non pci devices as primary netdev */
Why? Pls change this comment so it explains the motivation
rather than just repeat what the code does.
> + if (!standby && (!slave_dev->dev.parent ||
> + !dev_is_pci(slave_dev->dev.parent)))
> + return -EINVAL;
> +
> + return 0;
> +}
> +
> +static int failover_slave_join(struct net_device *slave_dev,
> + struct net_device *failover_dev,
> + struct failover_ops *failover_ops)
> +{
> + struct failover_info *finfo;
> + int err, orig_mtu;
> + bool standby;
> +
> + if (failover_ops) {
> + if (!failover_ops->slave_join)
> + return -EINVAL;
> +
> + return failover_ops->slave_join(slave_dev, failover_dev);
> + }
> +
> + if (netif_running(failover_dev)) {
> + err = dev_open(slave_dev);
> + if (err && (err != -EBUSY)) {
> + netdev_err(failover_dev, "Opening slave %s failed err:%d\n",
> + slave_dev->name, err);
> + goto err_dev_open;
> + }
> + }
> +
> + /* Align MTU of slave with failover dev */
> + orig_mtu = slave_dev->mtu;
I suspect this was copied from bond. this variable is never
used and I'm even surprised gcc did not warn about this.
> + err = dev_set_mtu(slave_dev, failover_dev->mtu);
How do we know slave supports this MTU? same applies to
failover_change_mtu.
> + if (err) {
> + netdev_err(failover_dev, "unable to change mtu of %s to %u register failed\n",
> + slave_dev->name, failover_dev->mtu);
> + goto err_set_mtu;
> + }
> +
> + finfo = netdev_priv(failover_dev);
> + standby = (slave_dev->dev.parent == failover_dev->dev.parent);
> +
> + dev_hold(slave_dev);
> +
> + if (standby) {
> + rcu_assign_pointer(finfo->standby_dev, slave_dev);
> + dev_get_stats(finfo->standby_dev, &finfo->standby_stats);
> + } else {
> + rcu_assign_pointer(finfo->primary_dev, slave_dev);
> + dev_get_stats(finfo->primary_dev, &finfo->primary_stats);
> + failover_dev->min_mtu = slave_dev->min_mtu;
> + failover_dev->max_mtu = slave_dev->max_mtu;
> + }
> +
> + netdev_info(failover_dev, "failover slave:%s joined\n",
> + slave_dev->name);
> +
> + return 0;
> +
> +err_set_mtu:
> + dev_close(slave_dev);
> +err_dev_open:
> + return err;
> +}
> +
> +/* Called when slave dev is injecting data into network stack.
> + * Change the associated network device from lower dev to virtio.
> + * note: already called with rcu_read_lock
> + */
> +static rx_handler_result_t failover_handle_frame(struct sk_buff **pskb)
> +{
> + struct sk_buff *skb = *pskb;
> + struct net_device *ndev = rcu_dereference(skb->dev->rx_handler_data);
> +
> + skb->dev = ndev;
> +
> + return RX_HANDLER_ANOTHER;
> +}
> +
> +static struct net_device *failover_get_bymac(u8 *mac, struct failover_ops **ops)
> +{
> + struct net_device *failover_dev;
> + struct failover *failover;
> +
> + spin_lock(&failover_lock);
> + list_for_each_entry(failover, &failover_list, list) {
> + failover_dev = rtnl_dereference(failover->failover_dev);
> + if (ether_addr_equal(failover_dev->perm_addr, mac)) {
> + *ops = rtnl_dereference(failover->ops);
> + spin_unlock(&failover_lock);
> + return failover_dev;
> + }
> + }
> + spin_unlock(&failover_lock);
> + return NULL;
> +}
> +
> +static int failover_slave_register(struct net_device *slave_dev)
> +{
> + struct failover_ops *failover_ops;
> + struct net_device *failover_dev;
> + int ret;
> +
> + ASSERT_RTNL();
> +
> + failover_dev = failover_get_bymac(slave_dev->perm_addr, &failover_ops);
> + if (!failover_dev)
> + goto done;
> +
> + ret = failover_slave_pre_register(slave_dev, failover_dev,
> + failover_ops);
> + if (ret)
> + goto done;
> +
> + ret = netdev_rx_handler_register(slave_dev, failover_ops ?
> + failover_ops->handle_frame :
> + failover_handle_frame, failover_dev);
> + if (ret) {
> + netdev_err(slave_dev, "can not register failover rx handler (err = %d)\n",
> + ret);
> + goto done;
> + }
> +
> + ret = netdev_upper_dev_link(slave_dev, failover_dev, NULL);
> + if (ret) {
> + netdev_err(slave_dev, "can not set failover device %s (err = %d)\n",
> + failover_dev->name, ret);
> + goto upper_link_failed;
> + }
> +
> + slave_dev->priv_flags |= IFF_FAILOVER_SLAVE;
> +
> + ret = failover_slave_join(slave_dev, failover_dev, failover_ops);
> + if (ret)
> + goto err_join;
> +
> + call_netdevice_notifiers(NETDEV_JOIN, slave_dev);
> +
> + netdev_info(failover_dev, "failover slave:%s registered\n",
> + slave_dev->name);
> +
> + goto done;
> +
> +err_join:
> + netdev_upper_dev_unlink(slave_dev, failover_dev);
> + slave_dev->priv_flags &= ~IFF_FAILOVER_SLAVE;
> +upper_link_failed:
> + netdev_rx_handler_unregister(slave_dev);
> +done:
> + return NOTIFY_DONE;
> +}
> +
> +static int failover_slave_pre_unregister(struct net_device *slave_dev,
> + struct net_device *failover_dev,
> + struct failover_ops *failover_ops)
> +{
> + struct net_device *standby_dev, *primary_dev;
> + struct failover_info *finfo;
> +
> + if (failover_ops) {
> + if (!failover_ops->slave_pre_unregister)
> + return -EINVAL;
> +
> + return failover_ops->slave_pre_unregister(slave_dev,
> + failover_dev);
> + }
> +
> + finfo = netdev_priv(failover_dev);
> + primary_dev = rtnl_dereference(finfo->primary_dev);
> + standby_dev = rtnl_dereference(finfo->standby_dev);
> +
> + if (slave_dev != primary_dev && slave_dev != standby_dev)
> + return -EINVAL;
> +
> + return 0;
> +}
> +
> +static int failover_slave_release(struct net_device *slave_dev,
> + struct net_device *failover_dev,
> + struct failover_ops *failover_ops)
> +{
> + struct net_device *standby_dev, *primary_dev;
> + struct failover_info *finfo;
> +
> + if (failover_ops) {
> + if (!failover_ops->slave_release)
> + return -EINVAL;
> +
> + return failover_ops->slave_release(slave_dev, failover_dev);
> + }
> +
> + finfo = netdev_priv(failover_dev);
> + primary_dev = rtnl_dereference(finfo->primary_dev);
> + standby_dev = rtnl_dereference(finfo->standby_dev);
> +
> + if (slave_dev == standby_dev) {
> + RCU_INIT_POINTER(finfo->standby_dev, NULL);
> + } else {
> + RCU_INIT_POINTER(finfo->primary_dev, NULL);
> + if (standby_dev) {
> + failover_dev->min_mtu = standby_dev->min_mtu;
> + failover_dev->max_mtu = standby_dev->max_mtu;
> + }
> + }
> +
> + dev_put(slave_dev);
> +
> + netdev_info(failover_dev, "failover slave:%s released\n",
> + slave_dev->name);
> +
> + return 0;
> +}
> +
> +int failover_slave_unregister(struct net_device *slave_dev)
> +{
> + struct failover_ops *failover_ops;
> + struct net_device *failover_dev;
> + int ret;
> +
> + if (!netif_is_failover_slave(slave_dev))
> + goto done;
> +
> + ASSERT_RTNL();
> +
> + failover_dev = failover_get_bymac(slave_dev->perm_addr, &failover_ops);
> + if (!failover_dev)
> + goto done;
> +
> + ret = failover_slave_pre_unregister(slave_dev, failover_dev,
> + failover_ops);
> + if (ret)
> + goto done;
> +
> + netdev_rx_handler_unregister(slave_dev);
> + netdev_upper_dev_unlink(slave_dev, failover_dev);
> + slave_dev->priv_flags &= ~IFF_FAILOVER_SLAVE;
> +
> + failover_slave_release(slave_dev, failover_dev, failover_ops);
Don't you need to get stats from it? This device is going away ...
> +
> + netdev_info(failover_dev, "failover slave:%s unregistered\n",
> + slave_dev->name);
> +
> +done:
> + return NOTIFY_DONE;
> +}
> +EXPORT_SYMBOL_GPL(failover_slave_unregister);
> +
> +static bool failover_xmit_ready(struct net_device *dev)
> +{
> + return netif_running(dev) && netif_carrier_ok(dev);
> +}
> +
> +static int failover_slave_link_change(struct net_device *slave_dev)
> +{
> + struct net_device *failover_dev, *primary_dev, *standby_dev;
> + struct failover_ops *failover_ops;
> + struct failover_info *finfo;
> +
> + if (!netif_is_failover_slave(slave_dev))
> + goto done;
> +
> + ASSERT_RTNL();
> +
> + failover_dev = failover_get_bymac(slave_dev->perm_addr, &failover_ops);
> + if (!failover_dev)
> + goto done;
> +
> + if (failover_ops) {
> + if (!failover_ops->slave_link_change)
> + goto done;
> +
> + return failover_ops->slave_link_change(slave_dev, failover_dev);
> + }
> +
> + if (!netif_running(failover_dev))
> + return 0;
> +
> + finfo = netdev_priv(failover_dev);
> +
> + primary_dev = rtnl_dereference(finfo->primary_dev);
> + standby_dev = rtnl_dereference(finfo->standby_dev);
> +
> + if (slave_dev != primary_dev && slave_dev != standby_dev)
> + goto done;
> +
> + if ((primary_dev && failover_xmit_ready(primary_dev)) ||
> + (standby_dev && failover_xmit_ready(standby_dev))) {
> + netif_carrier_on(failover_dev);
> + netif_tx_wake_all_queues(failover_dev);
> + } else {
> + netif_carrier_off(failover_dev);
> + netif_tx_stop_all_queues(failover_dev);
And I think it's a good idea to get stats from device here too.
> + }
> +
> +done:
> + return NOTIFY_DONE;
> +}
> +
> +static bool failover_validate_event_dev(struct net_device *dev)
> +{
> + /* Skip parent events */
> + if (netif_is_failover(dev))
> + return false;
> +
> + /* Avoid non-Ethernet type devices */
... for now. It would be possible easy to make this generic -
just copy things like type and addr_len from slave.
> + if (dev->type != ARPHRD_ETHER)
> + return false;
> +
> + return true;
> +}
> +
> +static int
> +failover_event(struct notifier_block *this, unsigned long event, void *ptr)
> +{
> + struct net_device *event_dev = netdev_notifier_info_to_dev(ptr);
> +
> + if (!failover_validate_event_dev(event_dev))
> + return NOTIFY_DONE;
> +
> + switch (event) {
> + case NETDEV_REGISTER:
> + return failover_slave_register(event_dev);
> + case NETDEV_UNREGISTER:
> + return failover_slave_unregister(event_dev);
> + case NETDEV_UP:
> + case NETDEV_DOWN:
> + case NETDEV_CHANGE:
> + return failover_slave_link_change(event_dev);
> + default:
> + return NOTIFY_DONE;
> + }
> +}
> +
> +static struct notifier_block failover_notifier = {
> + .notifier_call = failover_event,
> +};
> +
> +static int failover_open(struct net_device *dev)
> +{
> + struct failover_info *finfo = netdev_priv(dev);
> + struct net_device *primary_dev, *standby_dev;
> + int err;
> +
> + netif_carrier_off(dev);
> + netif_tx_wake_all_queues(dev);
> +
> + primary_dev = rtnl_dereference(finfo->primary_dev);
> + if (primary_dev) {
> + err = dev_open(primary_dev);
> + if (err)
> + goto err_primary_open;
> + }
> +
> + standby_dev = rtnl_dereference(finfo->standby_dev);
> + if (standby_dev) {
> + err = dev_open(standby_dev);
> + if (err)
> + goto err_standby_open;
> + }
> +
> + return 0;
> +
> +err_standby_open:
> + dev_close(primary_dev);
> +err_primary_open:
> + netif_tx_disable(dev);
> + return err;
> +}
> +
> +static int failover_close(struct net_device *dev)
> +{
> + struct failover_info *finfo = netdev_priv(dev);
> + struct net_device *slave_dev;
> +
> + netif_tx_disable(dev);
> +
> + slave_dev = rtnl_dereference(finfo->primary_dev);
> + if (slave_dev)
> + dev_close(slave_dev);
> +
> + slave_dev = rtnl_dereference(finfo->standby_dev);
> + if (slave_dev)
> + dev_close(slave_dev);
> +
> + return 0;
> +}
> +
> +static netdev_tx_t failover_drop_xmit(struct sk_buff *skb,
> + struct net_device *dev)
> +{
> + atomic_long_inc(&dev->tx_dropped);
> + dev_kfree_skb_any(skb);
> + return NETDEV_TX_OK;
> +}
> +
> +static netdev_tx_t failover_start_xmit(struct sk_buff *skb,
> + struct net_device *dev)
> +{
> + struct failover_info *finfo = netdev_priv(dev);
> + struct net_device *xmit_dev;
> +
> + /* Try xmit via primary netdev followed by standby netdev */
> + xmit_dev = rcu_dereference_bh(finfo->primary_dev);
> + if (!xmit_dev || !failover_xmit_ready(xmit_dev)) {
> + xmit_dev = rcu_dereference_bh(finfo->standby_dev);
> + if (!xmit_dev || !failover_xmit_ready(xmit_dev))
> + return failover_drop_xmit(skb, dev);
> + }
> +
> + skb->dev = xmit_dev;
> + skb->queue_mapping = qdisc_skb_cb(skb)->slave_dev_queue_mapping;
> +
> + return dev_queue_xmit(skb);
> +}
Is this going through qdisc twice? Won't this hurt performance
measureably?
> +
> +static u16 failover_select_queue(struct net_device *dev, struct sk_buff *skb,
> + void *accel_priv,
> + select_queue_fallback_t fallback)
> +{
> + struct failover_info *finfo = netdev_priv(dev);
> + struct net_device *primary_dev;
> + u16 txq;
> +
> + rcu_read_lock();
> + primary_dev = rcu_dereference(finfo->primary_dev);
> + if (primary_dev) {
> + const struct net_device_ops *ops = primary_dev->netdev_ops;
> +
> + if (ops->ndo_select_queue)
> + txq = ops->ndo_select_queue(primary_dev, skb,
> + accel_priv, fallback);
> + else
> + txq = fallback(primary_dev, skb);
> +
> + qdisc_skb_cb(skb)->slave_dev_queue_mapping = skb->queue_mapping;
> +
> + return txq;
> + }
> +
> + txq = skb_rx_queue_recorded(skb) ? skb_get_rx_queue(skb) : 0;
> +
> + /* Save the original txq to restore before passing to the driver */
> + qdisc_skb_cb(skb)->slave_dev_queue_mapping = skb->queue_mapping;
> +
> + if (unlikely(txq >= dev->real_num_tx_queues)) {
> + do {
> + txq -= dev->real_num_tx_queues;
> + } while (txq >= dev->real_num_tx_queues);
> + }
> +
> + return txq;
> +}
> +
> +/* fold stats, assuming all rtnl_link_stats64 fields are u64, but
> + * that some drivers can provide 32finfot values only.
> + */
> +static void failover_fold_stats(struct rtnl_link_stats64 *_res,
> + const struct rtnl_link_stats64 *_new,
> + const struct rtnl_link_stats64 *_old)
> +{
> + const u64 *new = (const u64 *)_new;
> + const u64 *old = (const u64 *)_old;
> + u64 *res = (u64 *)_res;
> + int i;
> +
> + for (i = 0; i < sizeof(*_res) / sizeof(u64); i++) {
> + u64 nv = new[i];
> + u64 ov = old[i];
> + s64 delta = nv - ov;
> +
> + /* detects if this particular field is 32bit only */
> + if (((nv | ov) >> 32) == 0)
> + delta = (s64)(s32)((u32)nv - (u32)ov);
> +
> + /* filter anomalies, some drivers reset their stats
> + * at down/up events.
> + */
> + if (delta > 0)
> + res[i] += delta;
> + }
> +}
> +
> +static void failover_get_stats(struct net_device *dev,
> + struct rtnl_link_stats64 *stats)
> +{
> + struct failover_info *finfo = netdev_priv(dev);
> + const struct rtnl_link_stats64 *new;
> + struct rtnl_link_stats64 temp;
> + struct net_device *slave_dev;
> +
> + spin_lock(&finfo->stats_lock);
> + memcpy(stats, &finfo->failover_stats, sizeof(*stats));
> +
> + rcu_read_lock();
> +
> + slave_dev = rcu_dereference(finfo->primary_dev);
> + if (slave_dev) {
> + new = dev_get_stats(slave_dev, &temp);
> + failover_fold_stats(stats, new, &finfo->primary_stats);
> + memcpy(&finfo->primary_stats, new, sizeof(*new));
> + }
> +
> + slave_dev = rcu_dereference(finfo->standby_dev);
> + if (slave_dev) {
> + new = dev_get_stats(slave_dev, &temp);
> + failover_fold_stats(stats, new, &finfo->standby_stats);
> + memcpy(&finfo->standby_stats, new, sizeof(*new));
> + }
> +
> + rcu_read_unlock();
> +
> + memcpy(&finfo->failover_stats, stats, sizeof(*stats));
> + spin_unlock(&finfo->stats_lock);
> +}
> +
> +static int failover_change_mtu(struct net_device *dev, int new_mtu)
> +{
> + struct failover_info *finfo = netdev_priv(dev);
> + struct net_device *primary_dev, *standby_dev;
> + int ret = 0;
> +
> + primary_dev = rcu_dereference(finfo->primary_dev);
> + if (primary_dev) {
> + ret = dev_set_mtu(primary_dev, new_mtu);
> + if (ret)
> + return ret;
> + }
> +
> + standby_dev = rcu_dereference(finfo->standby_dev);
> + if (standby_dev) {
> + ret = dev_set_mtu(standby_dev, new_mtu);
> + if (ret) {
> + dev_set_mtu(primary_dev, dev->mtu);
> + return ret;
> + }
> + }
> +
> + dev->mtu = new_mtu;
> + return 0;
> +}
> +
> +static void failover_set_rx_mode(struct net_device *dev)
> +{
> + struct failover_info *finfo = netdev_priv(dev);
> + struct net_device *slave_dev;
> +
> + rcu_read_lock();
> +
> + slave_dev = rcu_dereference(finfo->primary_dev);
> + if (slave_dev) {
> + dev_uc_sync_multiple(slave_dev, dev);
> + dev_mc_sync_multiple(slave_dev, dev);
> + }
> +
> + slave_dev = rcu_dereference(finfo->standby_dev);
> + if (slave_dev) {
> + dev_uc_sync_multiple(slave_dev, dev);
> + dev_mc_sync_multiple(slave_dev, dev);
> + }
> +
> + rcu_read_unlock();
> +}
> +
> +static const struct net_device_ops failover_dev_ops = {
> + .ndo_open = failover_open,
> + .ndo_stop = failover_close,
> + .ndo_start_xmit = failover_start_xmit,
> + .ndo_select_queue = failover_select_queue,
> + .ndo_get_stats64 = failover_get_stats,
> + .ndo_change_mtu = failover_change_mtu,
> + .ndo_set_rx_mode = failover_set_rx_mode,
> + .ndo_validate_addr = eth_validate_addr,
> + .ndo_features_check = passthru_features_check,
xdp support?
> +};
> +
> +#define FAILOVER_NAME "failover"
> +#define FAILOVER_VERSION "0.1"
> +
> +static void failover_ethtool_get_drvinfo(struct net_device *dev,
> + struct ethtool_drvinfo *drvinfo)
> +{
> + strlcpy(drvinfo->driver, FAILOVER_NAME, sizeof(drvinfo->driver));
> + strlcpy(drvinfo->version, FAILOVER_VERSION, sizeof(drvinfo->version));
> +}
> +
> +int failover_ethtool_get_link_ksettings(struct net_device *dev,
> + struct ethtool_link_ksettings *cmd)
> +{
> + struct failover_info *finfo = netdev_priv(dev);
> + struct net_device *slave_dev;
> +
> + slave_dev = rtnl_dereference(finfo->primary_dev);
> + if (!slave_dev || !failover_xmit_ready(slave_dev)) {
> + slave_dev = rtnl_dereference(finfo->standby_dev);
> + if (!slave_dev || !failover_xmit_ready(slave_dev)) {
> + cmd->base.duplex = DUPLEX_UNKNOWN;
> + cmd->base.port = PORT_OTHER;
> + cmd->base.speed = SPEED_UNKNOWN;
> +
> + return 0;
> + }
> + }
> +
> + return __ethtool_get_link_ksettings(slave_dev, cmd);
> +}
> +EXPORT_SYMBOL_GPL(failover_ethtool_get_link_ksettings);
> +
> +static const struct ethtool_ops failover_ethtool_ops = {
> + .get_drvinfo = failover_ethtool_get_drvinfo,
> + .get_link = ethtool_op_get_link,
> + .get_link_ksettings = failover_ethtool_get_link_ksettings,
> +};
> +
> +static void failover_register_existing_slave(struct net_device *failover_dev)
> +{
> + struct net *net = dev_net(failover_dev);
> + struct net_device *dev;
> +
> + rtnl_lock();
> + for_each_netdev(net, dev) {
> + if (dev == failover_dev)
> + continue;
> + if (!failover_validate_event_dev(dev))
> + continue;
> + if (ether_addr_equal(failover_dev->perm_addr, dev->perm_addr))
> + failover_slave_register(dev);
> + }
> + rtnl_unlock();
> +}
> +
> +int failover_register(struct net_device *dev, struct failover_ops *ops,
> + struct failover **pfailover)
> +{
> + struct failover *failover;
> +
> + failover = kzalloc(sizeof(*failover), GFP_KERNEL);
> + if (!failover)
> + return -ENOMEM;
> +
> + rcu_assign_pointer(failover->ops, ops);
> + dev_hold(dev);
> + dev->priv_flags |= IFF_FAILOVER;
> + rcu_assign_pointer(failover->failover_dev, dev);
> +
> + spin_lock(&failover_lock);
> + list_add_tail(&failover->list, &failover_list);
> + spin_unlock(&failover_lock);
> +
> + failover_register_existing_slave(dev);
> +
> + *pfailover = failover;
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(failover_register);
> +
> +void failover_unregister(struct failover *failover)
> +{
> + struct net_device *failover_dev;
> +
> + failover_dev = rcu_dereference(failover->failover_dev);
> +
> + failover_dev->priv_flags &= ~IFF_FAILOVER;
> + dev_put(failover_dev);
> +
> + spin_lock(&failover_lock);
> + list_del(&failover->list);
> + spin_unlock(&failover_lock);
> +
> + kfree(failover);
> +}
> +EXPORT_SYMBOL_GPL(failover_unregister);
> +
> +int failover_create(struct net_device *standby_dev, struct failover **pfailover)
> +{
> + struct device *dev = standby_dev->dev.parent;
> + struct net_device *failover_dev;
> + int err;
> +
> + /* Alloc at least 2 queues, for now we are going with 16 assuming
> + * that most devices being bonded won't have too many queues.
> + */
> + failover_dev = alloc_etherdev_mq(sizeof(struct failover_info), 16);
> + if (!failover_dev) {
> + dev_err(dev, "Unable to allocate failover_netdev!\n");
> + return -ENOMEM;
> + }
> +
> + dev_net_set(failover_dev, dev_net(standby_dev));
> + SET_NETDEV_DEV(failover_dev, dev);
> +
> + failover_dev->netdev_ops = &failover_dev_ops;
> + failover_dev->ethtool_ops = &failover_ethtool_ops;
> +
> + /* Initialize the device options */
> + failover_dev->priv_flags |= IFF_UNICAST_FLT | IFF_NO_QUEUE;
> + failover_dev->priv_flags &= ~(IFF_XMIT_DST_RELEASE |
> + IFF_TX_SKB_SHARING);
> +
> + /* don't acquire failover netdev's netif_tx_lock when transmitting */
> + failover_dev->features |= NETIF_F_LLTX;
> +
> + /* Don't allow failover devices to change network namespaces. */
> + failover_dev->features |= NETIF_F_NETNS_LOCAL;
> +
> + failover_dev->hw_features = NETIF_F_HW_CSUM | NETIF_F_SG |
> + NETIF_F_FRAGLIST | NETIF_F_ALL_TSO |
> + NETIF_F_HIGHDMA | NETIF_F_LRO;
OK but then you must make sure your primary and standby both
support these features.
> +
> + failover_dev->hw_features |= NETIF_F_GSO_ENCAP_ALL;
> + failover_dev->features |= failover_dev->hw_features;
> +
> + memcpy(failover_dev->dev_addr, standby_dev->dev_addr,
> + failover_dev->addr_len);
> +
> + failover_dev->min_mtu = standby_dev->min_mtu;
> + failover_dev->max_mtu = standby_dev->max_mtu;
OK MTU is copied, fine. But is this always enough?
How about e.g. hard_header_len? min_header_len? needed_headroom?
needed_tailroom? I'd worry that even if you cover existing ones more
might be added with time. A function copying config between devices
probably belongs in some central place IMHO.
> +
> + err = register_netdev(failover_dev);
> + if (err < 0) {
> + dev_err(dev, "Unable to register failover_dev!\n");
> + goto err_register_netdev;
> + }
> +
> + netif_carrier_off(failover_dev);
> +
> + err = failover_register(failover_dev, NULL, pfailover);
> + if (err < 0)
> + goto err_failover;
> +
> + return 0;
> +
> +err_failover:
> + unregister_netdev(failover_dev);
> +err_register_netdev:
> + free_netdev(failover_dev);
> +
> + return err;
> +}
> +EXPORT_SYMBOL_GPL(failover_create);
> +
> +void failover_destroy(struct failover *failover)
> +{
> + struct net_device *failover_dev;
> + struct net_device *slave_dev;
> + struct failover_info *finfo;
> +
> + if (!failover)
> + return;
> +
> + failover_dev = rcu_dereference(failover->failover_dev);
> + finfo = netdev_priv(failover_dev);
> +
> + netif_device_detach(failover_dev);
> +
> + rtnl_lock();
> +
> + slave_dev = rtnl_dereference(finfo->primary_dev);
> + if (slave_dev)
> + failover_slave_unregister(slave_dev);
> +
> + slave_dev = rtnl_dereference(finfo->standby_dev);
> + if (slave_dev)
> + failover_slave_unregister(slave_dev);
> +
> + failover_unregister(failover);
> +
> + unregister_netdevice(failover_dev);
> +
> + rtnl_unlock();
> +
> + free_netdev(failover_dev);
> +}
> +EXPORT_SYMBOL_GPL(failover_destroy);
> +
> +static __init int
> +failover_init(void)
> +{
> + register_netdevice_notifier(&failover_notifier);
> +
> + return 0;
> +}
> +module_init(failover_init);
> +
> +static __exit
> +void failover_exit(void)
> +{
> + unregister_netdevice_notifier(&failover_notifier);
> +}
> +module_exit(failover_exit);
> +
> +MODULE_DESCRIPTION("Failover infrastructure/interface for Paravirtual drivers");
> +MODULE_LICENSE("GPL v2");
> --
> 2.14.3
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 net-next 2/4] net: Introduce generic failover module
2018-04-20 1:42 ` [virtio-dev] " Sridhar Samudrala
(?)
@ 2018-04-20 2:44 ` Michael S. Tsirkin
-1 siblings, 0 replies; 114+ messages in thread
From: Michael S. Tsirkin @ 2018-04-20 2:44 UTC (permalink / raw)
To: Sridhar Samudrala
Cc: alexander.h.duyck, virtio-dev, jiri, kubakici, netdev,
virtualization, loseweigh, davem
On Thu, Apr 19, 2018 at 06:42:02PM -0700, Sridhar Samudrala wrote:
> This provides a generic interface for paravirtual drivers to listen
> for netdev register/unregister/link change events from pci ethernet
> devices with the same MAC and takeover their datapath. The notifier and
> event handling code is based on the existing netvsc implementation.
>
> It exposes 2 sets of interfaces to the paravirtual drivers.
> 1. existing netvsc driver that uses 2 netdev model. In this model, no
> master netdev is created. The paravirtual driver registers each instance
> of netvsc as a 'failover' instance along with a set of ops to manage the
> slave events.
> failover_register()
> failover_unregister()
> 2. new virtio_net based solution that uses 3 netdev model. In this model,
> the failover module provides interfaces to create/destroy additional master
> netdev and all the slave events are managed internally.
> failover_create()
> failover_destroy()
> These functions call failover_register()/failover_unregister() with the
> master netdev created by the failover module.
>
> Signed-off-by: Sridhar Samudrala <sridhar.samudrala@intel.com>
I like this patch. Yes something to improve (see below)
> ---
> include/linux/netdevice.h | 16 +
> include/net/failover.h | 96 ++++++
> net/Kconfig | 18 +
> net/core/Makefile | 1 +
> net/core/failover.c | 844 ++++++++++++++++++++++++++++++++++++++++++++++
> 5 files changed, 975 insertions(+)
> create mode 100644 include/net/failover.h
> create mode 100644 net/core/failover.c
>
> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> index cf44503ea81a..ed535b6724e1 100644
> --- a/include/linux/netdevice.h
> +++ b/include/linux/netdevice.h
> @@ -1401,6 +1401,8 @@ struct net_device_ops {
> * entity (i.e. the master device for bridged veth)
> * @IFF_MACSEC: device is a MACsec device
> * @IFF_NO_RX_HANDLER: device doesn't support the rx_handler hook
> + * @IFF_FAILOVER: device is a failover master device
> + * @IFF_FAILOVER_SLAVE: device is lower dev of a failover master device
> */
> enum netdev_priv_flags {
> IFF_802_1Q_VLAN = 1<<0,
> @@ -1430,6 +1432,8 @@ enum netdev_priv_flags {
> IFF_PHONY_HEADROOM = 1<<24,
> IFF_MACSEC = 1<<25,
> IFF_NO_RX_HANDLER = 1<<26,
> + IFF_FAILOVER = 1<<27,
> + IFF_FAILOVER_SLAVE = 1<<28,
> };
>
> #define IFF_802_1Q_VLAN IFF_802_1Q_VLAN
> @@ -1458,6 +1462,8 @@ enum netdev_priv_flags {
> #define IFF_RXFH_CONFIGURED IFF_RXFH_CONFIGURED
> #define IFF_MACSEC IFF_MACSEC
> #define IFF_NO_RX_HANDLER IFF_NO_RX_HANDLER
> +#define IFF_FAILOVER IFF_FAILOVER
> +#define IFF_FAILOVER_SLAVE IFF_FAILOVER_SLAVE
>
> /**
> * struct net_device - The DEVICE structure.
> @@ -4308,6 +4314,16 @@ static inline bool netif_is_rxfh_configured(const struct net_device *dev)
> return dev->priv_flags & IFF_RXFH_CONFIGURED;
> }
>
> +static inline bool netif_is_failover(const struct net_device *dev)
> +{
> + return dev->priv_flags & IFF_FAILOVER;
> +}
> +
> +static inline bool netif_is_failover_slave(const struct net_device *dev)
> +{
> + return dev->priv_flags & IFF_FAILOVER_SLAVE;
> +}
> +
> /* This device needs to keep skb dst for qdisc enqueue or ndo_start_xmit() */
> static inline void netif_keep_dst(struct net_device *dev)
> {
> diff --git a/include/net/failover.h b/include/net/failover.h
> new file mode 100644
> index 000000000000..0b8601043d90
> --- /dev/null
> +++ b/include/net/failover.h
> @@ -0,0 +1,96 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/* Copyright (c) 2018, Intel Corporation. */
> +
> +#ifndef _NET_FAILOVER_H
> +#define _NET_FAILOVER_H
> +
> +#include <linux/netdevice.h>
> +
> +struct failover_ops {
> + int (*slave_pre_register)(struct net_device *slave_dev,
> + struct net_device *failover_dev);
> + int (*slave_join)(struct net_device *slave_dev,
> + struct net_device *failover_dev);
> + int (*slave_pre_unregister)(struct net_device *slave_dev,
> + struct net_device *failover_dev);
> + int (*slave_release)(struct net_device *slave_dev,
> + struct net_device *failover_dev);
> + int (*slave_link_change)(struct net_device *slave_dev,
> + struct net_device *failover_dev);
> + rx_handler_result_t (*handle_frame)(struct sk_buff **pskb);
> +};
> +
> +struct failover {
> + struct list_head list;
> + struct net_device __rcu *failover_dev;
> + struct failover_ops __rcu *ops;
> +};
> +
> +/* failover state */
> +struct failover_info {
> + /* primary netdev with same MAC */
> + struct net_device __rcu *primary_dev;
> +
> + /* standby netdev */
> + struct net_device __rcu *standby_dev;
> +
> + /* primary netdev stats */
> + struct rtnl_link_stats64 primary_stats;
> +
> + /* standby netdev stats */
> + struct rtnl_link_stats64 standby_stats;
> +
> + /* aggregated stats */
> + struct rtnl_link_stats64 failover_stats;
> +
> + /* spinlock while updating stats */
> + spinlock_t stats_lock;
> +};
> +
> +#if IS_ENABLED(CONFIG_NET_FAILOVER)
> +
> +int failover_create(struct net_device *standby_dev,
> + struct failover **pfailover);
> +void failover_destroy(struct failover *failover);
> +
> +int failover_register(struct net_device *standby_dev, struct failover_ops *ops,
> + struct failover **pfailover);
> +void failover_unregister(struct failover *failover);
> +
> +int failover_slave_unregister(struct net_device *slave_dev);
> +
> +#else
> +
> +static inline
> +int failover_create(struct net_device *standby_dev,
> + struct failover **pfailover);
> +{
> + return 0;
> +}
> +
> +static inline
> +void failover_destroy(struct failover *failover)
> +{
> +}
> +
> +static inline
> +int failover_register(struct net_device *standby_dev, struct failover_ops *ops,
> + struct pfailover **pfailover);
> +{
> + return 0;
> +}
> +
> +static inline
> +void failover_unregister(struct failover *failover)
> +{
> +}
> +
> +static inline
> +int failover_slave_unregister(struct net_device *slave_dev)
> +{
> + return 0;
> +}
> +
> +#endif
> +
> +#endif /* _NET_FAILOVER_H */
> diff --git a/net/Kconfig b/net/Kconfig
> index 0428f12c25c2..388b99dfee10 100644
> --- a/net/Kconfig
> +++ b/net/Kconfig
> @@ -423,6 +423,24 @@ config MAY_USE_DEVLINK
> on MAY_USE_DEVLINK to ensure they do not cause link errors when
> devlink is a loadable module and the driver using it is built-in.
>
> +config NET_FAILOVER
> + tristate "Failover interface"
> + help
> + This provides a generic interface for paravirtual drivers to listen
> + for netdev register/unregister/link change events from pci ethernet
> + devices with the same MAC and takeover their datapath. This also
> + enables live migration of a VM with direct attached VF by failing
> + over to the paravirtual datapath when the VF is unplugged.
> +
> +config MAY_USE_FAILOVER
> + tristate
> + default m if NET_FAILOVER=m
> + default y if NET_FAILOVER=y || NET_FAILOVER=n
> + help
> + Drivers using the failover infrastructure should have a dependency
> + on MAY_USE_FAILOVER to ensure they do not cause link errors when
> + failover is a loadable module and the driver using it is built-in.
> +
> endif # if NET
>
> # Used by archs to tell that they support BPF JIT compiler plus which flavour.
> diff --git a/net/core/Makefile b/net/core/Makefile
> index 6dbbba8c57ae..cef17518bb7d 100644
> --- a/net/core/Makefile
> +++ b/net/core/Makefile
> @@ -30,3 +30,4 @@ obj-$(CONFIG_DST_CACHE) += dst_cache.o
> obj-$(CONFIG_HWBM) += hwbm.o
> obj-$(CONFIG_NET_DEVLINK) += devlink.o
> obj-$(CONFIG_GRO_CELLS) += gro_cells.o
> +obj-$(CONFIG_NET_FAILOVER) += failover.o
> diff --git a/net/core/failover.c b/net/core/failover.c
> new file mode 100644
> index 000000000000..7bee762cb737
> --- /dev/null
> +++ b/net/core/failover.c
> @@ -0,0 +1,844 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/* Copyright (c) 2018, Intel Corporation. */
I think you should copy the header from bond_main.c upon which
some of the code seems to be based.
> +
> +/* A common module to handle registrations and notifications for paravirtual
> + * drivers to enable accelerated datapath and support VF live migration.
> + *
> + * The notifier and event handling code is based on netvsc driver.
> + */
> +
> +#include <linux/netdevice.h>
> +#include <linux/etherdevice.h>
> +#include <linux/ethtool.h>
> +#include <linux/module.h>
> +#include <linux/slab.h>
> +#include <linux/netdevice.h>
> +#include <linux/netpoll.h>
> +#include <linux/rtnetlink.h>
> +#include <linux/if_vlan.h>
> +#include <linux/pci.h>
> +#include <net/sch_generic.h>
> +#include <uapi/linux/if_arp.h>
> +#include <net/failover.h>
> +
> +static LIST_HEAD(failover_list);
> +static DEFINE_SPINLOCK(failover_lock);
> +
> +static int failover_slave_pre_register(struct net_device *slave_dev,
> + struct net_device *failover_dev,
> + struct failover_ops *failover_ops)
> +{
> + struct failover_info *finfo;
> + bool standby;
> +
> + if (failover_ops) {
> + if (!failover_ops->slave_pre_register)
> + return -EINVAL;
> +
> + return failover_ops->slave_pre_register(slave_dev,
> + failover_dev);
> + }
> +
> + finfo = netdev_priv(failover_dev);
> + standby = (slave_dev->dev.parent == failover_dev->dev.parent);
> + if (standby ? rtnl_dereference(finfo->standby_dev) :
> + rtnl_dereference(finfo->primary_dev)) {
> + netdev_err(failover_dev, "%s attempting to register as slave dev when %s already present\n",
> + slave_dev->name, standby ? "standby" : "primary");
> + return -EEXIST;
> + }
> +
> + /* Avoid non pci devices as primary netdev */
Why? Pls change this comment so it explains the motivation
rather than just repeat what the code does.
> + if (!standby && (!slave_dev->dev.parent ||
> + !dev_is_pci(slave_dev->dev.parent)))
> + return -EINVAL;
> +
> + return 0;
> +}
> +
> +static int failover_slave_join(struct net_device *slave_dev,
> + struct net_device *failover_dev,
> + struct failover_ops *failover_ops)
> +{
> + struct failover_info *finfo;
> + int err, orig_mtu;
> + bool standby;
> +
> + if (failover_ops) {
> + if (!failover_ops->slave_join)
> + return -EINVAL;
> +
> + return failover_ops->slave_join(slave_dev, failover_dev);
> + }
> +
> + if (netif_running(failover_dev)) {
> + err = dev_open(slave_dev);
> + if (err && (err != -EBUSY)) {
> + netdev_err(failover_dev, "Opening slave %s failed err:%d\n",
> + slave_dev->name, err);
> + goto err_dev_open;
> + }
> + }
> +
> + /* Align MTU of slave with failover dev */
> + orig_mtu = slave_dev->mtu;
I suspect this was copied from bond. this variable is never
used and I'm even surprised gcc did not warn about this.
> + err = dev_set_mtu(slave_dev, failover_dev->mtu);
How do we know slave supports this MTU? same applies to
failover_change_mtu.
> + if (err) {
> + netdev_err(failover_dev, "unable to change mtu of %s to %u register failed\n",
> + slave_dev->name, failover_dev->mtu);
> + goto err_set_mtu;
> + }
> +
> + finfo = netdev_priv(failover_dev);
> + standby = (slave_dev->dev.parent == failover_dev->dev.parent);
> +
> + dev_hold(slave_dev);
> +
> + if (standby) {
> + rcu_assign_pointer(finfo->standby_dev, slave_dev);
> + dev_get_stats(finfo->standby_dev, &finfo->standby_stats);
> + } else {
> + rcu_assign_pointer(finfo->primary_dev, slave_dev);
> + dev_get_stats(finfo->primary_dev, &finfo->primary_stats);
> + failover_dev->min_mtu = slave_dev->min_mtu;
> + failover_dev->max_mtu = slave_dev->max_mtu;
> + }
> +
> + netdev_info(failover_dev, "failover slave:%s joined\n",
> + slave_dev->name);
> +
> + return 0;
> +
> +err_set_mtu:
> + dev_close(slave_dev);
> +err_dev_open:
> + return err;
> +}
> +
> +/* Called when slave dev is injecting data into network stack.
> + * Change the associated network device from lower dev to virtio.
> + * note: already called with rcu_read_lock
> + */
> +static rx_handler_result_t failover_handle_frame(struct sk_buff **pskb)
> +{
> + struct sk_buff *skb = *pskb;
> + struct net_device *ndev = rcu_dereference(skb->dev->rx_handler_data);
> +
> + skb->dev = ndev;
> +
> + return RX_HANDLER_ANOTHER;
> +}
> +
> +static struct net_device *failover_get_bymac(u8 *mac, struct failover_ops **ops)
> +{
> + struct net_device *failover_dev;
> + struct failover *failover;
> +
> + spin_lock(&failover_lock);
> + list_for_each_entry(failover, &failover_list, list) {
> + failover_dev = rtnl_dereference(failover->failover_dev);
> + if (ether_addr_equal(failover_dev->perm_addr, mac)) {
> + *ops = rtnl_dereference(failover->ops);
> + spin_unlock(&failover_lock);
> + return failover_dev;
> + }
> + }
> + spin_unlock(&failover_lock);
> + return NULL;
> +}
> +
> +static int failover_slave_register(struct net_device *slave_dev)
> +{
> + struct failover_ops *failover_ops;
> + struct net_device *failover_dev;
> + int ret;
> +
> + ASSERT_RTNL();
> +
> + failover_dev = failover_get_bymac(slave_dev->perm_addr, &failover_ops);
> + if (!failover_dev)
> + goto done;
> +
> + ret = failover_slave_pre_register(slave_dev, failover_dev,
> + failover_ops);
> + if (ret)
> + goto done;
> +
> + ret = netdev_rx_handler_register(slave_dev, failover_ops ?
> + failover_ops->handle_frame :
> + failover_handle_frame, failover_dev);
> + if (ret) {
> + netdev_err(slave_dev, "can not register failover rx handler (err = %d)\n",
> + ret);
> + goto done;
> + }
> +
> + ret = netdev_upper_dev_link(slave_dev, failover_dev, NULL);
> + if (ret) {
> + netdev_err(slave_dev, "can not set failover device %s (err = %d)\n",
> + failover_dev->name, ret);
> + goto upper_link_failed;
> + }
> +
> + slave_dev->priv_flags |= IFF_FAILOVER_SLAVE;
> +
> + ret = failover_slave_join(slave_dev, failover_dev, failover_ops);
> + if (ret)
> + goto err_join;
> +
> + call_netdevice_notifiers(NETDEV_JOIN, slave_dev);
> +
> + netdev_info(failover_dev, "failover slave:%s registered\n",
> + slave_dev->name);
> +
> + goto done;
> +
> +err_join:
> + netdev_upper_dev_unlink(slave_dev, failover_dev);
> + slave_dev->priv_flags &= ~IFF_FAILOVER_SLAVE;
> +upper_link_failed:
> + netdev_rx_handler_unregister(slave_dev);
> +done:
> + return NOTIFY_DONE;
> +}
> +
> +static int failover_slave_pre_unregister(struct net_device *slave_dev,
> + struct net_device *failover_dev,
> + struct failover_ops *failover_ops)
> +{
> + struct net_device *standby_dev, *primary_dev;
> + struct failover_info *finfo;
> +
> + if (failover_ops) {
> + if (!failover_ops->slave_pre_unregister)
> + return -EINVAL;
> +
> + return failover_ops->slave_pre_unregister(slave_dev,
> + failover_dev);
> + }
> +
> + finfo = netdev_priv(failover_dev);
> + primary_dev = rtnl_dereference(finfo->primary_dev);
> + standby_dev = rtnl_dereference(finfo->standby_dev);
> +
> + if (slave_dev != primary_dev && slave_dev != standby_dev)
> + return -EINVAL;
> +
> + return 0;
> +}
> +
> +static int failover_slave_release(struct net_device *slave_dev,
> + struct net_device *failover_dev,
> + struct failover_ops *failover_ops)
> +{
> + struct net_device *standby_dev, *primary_dev;
> + struct failover_info *finfo;
> +
> + if (failover_ops) {
> + if (!failover_ops->slave_release)
> + return -EINVAL;
> +
> + return failover_ops->slave_release(slave_dev, failover_dev);
> + }
> +
> + finfo = netdev_priv(failover_dev);
> + primary_dev = rtnl_dereference(finfo->primary_dev);
> + standby_dev = rtnl_dereference(finfo->standby_dev);
> +
> + if (slave_dev == standby_dev) {
> + RCU_INIT_POINTER(finfo->standby_dev, NULL);
> + } else {
> + RCU_INIT_POINTER(finfo->primary_dev, NULL);
> + if (standby_dev) {
> + failover_dev->min_mtu = standby_dev->min_mtu;
> + failover_dev->max_mtu = standby_dev->max_mtu;
> + }
> + }
> +
> + dev_put(slave_dev);
> +
> + netdev_info(failover_dev, "failover slave:%s released\n",
> + slave_dev->name);
> +
> + return 0;
> +}
> +
> +int failover_slave_unregister(struct net_device *slave_dev)
> +{
> + struct failover_ops *failover_ops;
> + struct net_device *failover_dev;
> + int ret;
> +
> + if (!netif_is_failover_slave(slave_dev))
> + goto done;
> +
> + ASSERT_RTNL();
> +
> + failover_dev = failover_get_bymac(slave_dev->perm_addr, &failover_ops);
> + if (!failover_dev)
> + goto done;
> +
> + ret = failover_slave_pre_unregister(slave_dev, failover_dev,
> + failover_ops);
> + if (ret)
> + goto done;
> +
> + netdev_rx_handler_unregister(slave_dev);
> + netdev_upper_dev_unlink(slave_dev, failover_dev);
> + slave_dev->priv_flags &= ~IFF_FAILOVER_SLAVE;
> +
> + failover_slave_release(slave_dev, failover_dev, failover_ops);
Don't you need to get stats from it? This device is going away ...
> +
> + netdev_info(failover_dev, "failover slave:%s unregistered\n",
> + slave_dev->name);
> +
> +done:
> + return NOTIFY_DONE;
> +}
> +EXPORT_SYMBOL_GPL(failover_slave_unregister);
> +
> +static bool failover_xmit_ready(struct net_device *dev)
> +{
> + return netif_running(dev) && netif_carrier_ok(dev);
> +}
> +
> +static int failover_slave_link_change(struct net_device *slave_dev)
> +{
> + struct net_device *failover_dev, *primary_dev, *standby_dev;
> + struct failover_ops *failover_ops;
> + struct failover_info *finfo;
> +
> + if (!netif_is_failover_slave(slave_dev))
> + goto done;
> +
> + ASSERT_RTNL();
> +
> + failover_dev = failover_get_bymac(slave_dev->perm_addr, &failover_ops);
> + if (!failover_dev)
> + goto done;
> +
> + if (failover_ops) {
> + if (!failover_ops->slave_link_change)
> + goto done;
> +
> + return failover_ops->slave_link_change(slave_dev, failover_dev);
> + }
> +
> + if (!netif_running(failover_dev))
> + return 0;
> +
> + finfo = netdev_priv(failover_dev);
> +
> + primary_dev = rtnl_dereference(finfo->primary_dev);
> + standby_dev = rtnl_dereference(finfo->standby_dev);
> +
> + if (slave_dev != primary_dev && slave_dev != standby_dev)
> + goto done;
> +
> + if ((primary_dev && failover_xmit_ready(primary_dev)) ||
> + (standby_dev && failover_xmit_ready(standby_dev))) {
> + netif_carrier_on(failover_dev);
> + netif_tx_wake_all_queues(failover_dev);
> + } else {
> + netif_carrier_off(failover_dev);
> + netif_tx_stop_all_queues(failover_dev);
And I think it's a good idea to get stats from device here too.
> + }
> +
> +done:
> + return NOTIFY_DONE;
> +}
> +
> +static bool failover_validate_event_dev(struct net_device *dev)
> +{
> + /* Skip parent events */
> + if (netif_is_failover(dev))
> + return false;
> +
> + /* Avoid non-Ethernet type devices */
... for now. It would be possible easy to make this generic -
just copy things like type and addr_len from slave.
> + if (dev->type != ARPHRD_ETHER)
> + return false;
> +
> + return true;
> +}
> +
> +static int
> +failover_event(struct notifier_block *this, unsigned long event, void *ptr)
> +{
> + struct net_device *event_dev = netdev_notifier_info_to_dev(ptr);
> +
> + if (!failover_validate_event_dev(event_dev))
> + return NOTIFY_DONE;
> +
> + switch (event) {
> + case NETDEV_REGISTER:
> + return failover_slave_register(event_dev);
> + case NETDEV_UNREGISTER:
> + return failover_slave_unregister(event_dev);
> + case NETDEV_UP:
> + case NETDEV_DOWN:
> + case NETDEV_CHANGE:
> + return failover_slave_link_change(event_dev);
> + default:
> + return NOTIFY_DONE;
> + }
> +}
> +
> +static struct notifier_block failover_notifier = {
> + .notifier_call = failover_event,
> +};
> +
> +static int failover_open(struct net_device *dev)
> +{
> + struct failover_info *finfo = netdev_priv(dev);
> + struct net_device *primary_dev, *standby_dev;
> + int err;
> +
> + netif_carrier_off(dev);
> + netif_tx_wake_all_queues(dev);
> +
> + primary_dev = rtnl_dereference(finfo->primary_dev);
> + if (primary_dev) {
> + err = dev_open(primary_dev);
> + if (err)
> + goto err_primary_open;
> + }
> +
> + standby_dev = rtnl_dereference(finfo->standby_dev);
> + if (standby_dev) {
> + err = dev_open(standby_dev);
> + if (err)
> + goto err_standby_open;
> + }
> +
> + return 0;
> +
> +err_standby_open:
> + dev_close(primary_dev);
> +err_primary_open:
> + netif_tx_disable(dev);
> + return err;
> +}
> +
> +static int failover_close(struct net_device *dev)
> +{
> + struct failover_info *finfo = netdev_priv(dev);
> + struct net_device *slave_dev;
> +
> + netif_tx_disable(dev);
> +
> + slave_dev = rtnl_dereference(finfo->primary_dev);
> + if (slave_dev)
> + dev_close(slave_dev);
> +
> + slave_dev = rtnl_dereference(finfo->standby_dev);
> + if (slave_dev)
> + dev_close(slave_dev);
> +
> + return 0;
> +}
> +
> +static netdev_tx_t failover_drop_xmit(struct sk_buff *skb,
> + struct net_device *dev)
> +{
> + atomic_long_inc(&dev->tx_dropped);
> + dev_kfree_skb_any(skb);
> + return NETDEV_TX_OK;
> +}
> +
> +static netdev_tx_t failover_start_xmit(struct sk_buff *skb,
> + struct net_device *dev)
> +{
> + struct failover_info *finfo = netdev_priv(dev);
> + struct net_device *xmit_dev;
> +
> + /* Try xmit via primary netdev followed by standby netdev */
> + xmit_dev = rcu_dereference_bh(finfo->primary_dev);
> + if (!xmit_dev || !failover_xmit_ready(xmit_dev)) {
> + xmit_dev = rcu_dereference_bh(finfo->standby_dev);
> + if (!xmit_dev || !failover_xmit_ready(xmit_dev))
> + return failover_drop_xmit(skb, dev);
> + }
> +
> + skb->dev = xmit_dev;
> + skb->queue_mapping = qdisc_skb_cb(skb)->slave_dev_queue_mapping;
> +
> + return dev_queue_xmit(skb);
> +}
Is this going through qdisc twice? Won't this hurt performance
measureably?
> +
> +static u16 failover_select_queue(struct net_device *dev, struct sk_buff *skb,
> + void *accel_priv,
> + select_queue_fallback_t fallback)
> +{
> + struct failover_info *finfo = netdev_priv(dev);
> + struct net_device *primary_dev;
> + u16 txq;
> +
> + rcu_read_lock();
> + primary_dev = rcu_dereference(finfo->primary_dev);
> + if (primary_dev) {
> + const struct net_device_ops *ops = primary_dev->netdev_ops;
> +
> + if (ops->ndo_select_queue)
> + txq = ops->ndo_select_queue(primary_dev, skb,
> + accel_priv, fallback);
> + else
> + txq = fallback(primary_dev, skb);
> +
> + qdisc_skb_cb(skb)->slave_dev_queue_mapping = skb->queue_mapping;
> +
> + return txq;
> + }
> +
> + txq = skb_rx_queue_recorded(skb) ? skb_get_rx_queue(skb) : 0;
> +
> + /* Save the original txq to restore before passing to the driver */
> + qdisc_skb_cb(skb)->slave_dev_queue_mapping = skb->queue_mapping;
> +
> + if (unlikely(txq >= dev->real_num_tx_queues)) {
> + do {
> + txq -= dev->real_num_tx_queues;
> + } while (txq >= dev->real_num_tx_queues);
> + }
> +
> + return txq;
> +}
> +
> +/* fold stats, assuming all rtnl_link_stats64 fields are u64, but
> + * that some drivers can provide 32finfot values only.
> + */
> +static void failover_fold_stats(struct rtnl_link_stats64 *_res,
> + const struct rtnl_link_stats64 *_new,
> + const struct rtnl_link_stats64 *_old)
> +{
> + const u64 *new = (const u64 *)_new;
> + const u64 *old = (const u64 *)_old;
> + u64 *res = (u64 *)_res;
> + int i;
> +
> + for (i = 0; i < sizeof(*_res) / sizeof(u64); i++) {
> + u64 nv = new[i];
> + u64 ov = old[i];
> + s64 delta = nv - ov;
> +
> + /* detects if this particular field is 32bit only */
> + if (((nv | ov) >> 32) == 0)
> + delta = (s64)(s32)((u32)nv - (u32)ov);
> +
> + /* filter anomalies, some drivers reset their stats
> + * at down/up events.
> + */
> + if (delta > 0)
> + res[i] += delta;
> + }
> +}
> +
> +static void failover_get_stats(struct net_device *dev,
> + struct rtnl_link_stats64 *stats)
> +{
> + struct failover_info *finfo = netdev_priv(dev);
> + const struct rtnl_link_stats64 *new;
> + struct rtnl_link_stats64 temp;
> + struct net_device *slave_dev;
> +
> + spin_lock(&finfo->stats_lock);
> + memcpy(stats, &finfo->failover_stats, sizeof(*stats));
> +
> + rcu_read_lock();
> +
> + slave_dev = rcu_dereference(finfo->primary_dev);
> + if (slave_dev) {
> + new = dev_get_stats(slave_dev, &temp);
> + failover_fold_stats(stats, new, &finfo->primary_stats);
> + memcpy(&finfo->primary_stats, new, sizeof(*new));
> + }
> +
> + slave_dev = rcu_dereference(finfo->standby_dev);
> + if (slave_dev) {
> + new = dev_get_stats(slave_dev, &temp);
> + failover_fold_stats(stats, new, &finfo->standby_stats);
> + memcpy(&finfo->standby_stats, new, sizeof(*new));
> + }
> +
> + rcu_read_unlock();
> +
> + memcpy(&finfo->failover_stats, stats, sizeof(*stats));
> + spin_unlock(&finfo->stats_lock);
> +}
> +
> +static int failover_change_mtu(struct net_device *dev, int new_mtu)
> +{
> + struct failover_info *finfo = netdev_priv(dev);
> + struct net_device *primary_dev, *standby_dev;
> + int ret = 0;
> +
> + primary_dev = rcu_dereference(finfo->primary_dev);
> + if (primary_dev) {
> + ret = dev_set_mtu(primary_dev, new_mtu);
> + if (ret)
> + return ret;
> + }
> +
> + standby_dev = rcu_dereference(finfo->standby_dev);
> + if (standby_dev) {
> + ret = dev_set_mtu(standby_dev, new_mtu);
> + if (ret) {
> + dev_set_mtu(primary_dev, dev->mtu);
> + return ret;
> + }
> + }
> +
> + dev->mtu = new_mtu;
> + return 0;
> +}
> +
> +static void failover_set_rx_mode(struct net_device *dev)
> +{
> + struct failover_info *finfo = netdev_priv(dev);
> + struct net_device *slave_dev;
> +
> + rcu_read_lock();
> +
> + slave_dev = rcu_dereference(finfo->primary_dev);
> + if (slave_dev) {
> + dev_uc_sync_multiple(slave_dev, dev);
> + dev_mc_sync_multiple(slave_dev, dev);
> + }
> +
> + slave_dev = rcu_dereference(finfo->standby_dev);
> + if (slave_dev) {
> + dev_uc_sync_multiple(slave_dev, dev);
> + dev_mc_sync_multiple(slave_dev, dev);
> + }
> +
> + rcu_read_unlock();
> +}
> +
> +static const struct net_device_ops failover_dev_ops = {
> + .ndo_open = failover_open,
> + .ndo_stop = failover_close,
> + .ndo_start_xmit = failover_start_xmit,
> + .ndo_select_queue = failover_select_queue,
> + .ndo_get_stats64 = failover_get_stats,
> + .ndo_change_mtu = failover_change_mtu,
> + .ndo_set_rx_mode = failover_set_rx_mode,
> + .ndo_validate_addr = eth_validate_addr,
> + .ndo_features_check = passthru_features_check,
xdp support?
> +};
> +
> +#define FAILOVER_NAME "failover"
> +#define FAILOVER_VERSION "0.1"
> +
> +static void failover_ethtool_get_drvinfo(struct net_device *dev,
> + struct ethtool_drvinfo *drvinfo)
> +{
> + strlcpy(drvinfo->driver, FAILOVER_NAME, sizeof(drvinfo->driver));
> + strlcpy(drvinfo->version, FAILOVER_VERSION, sizeof(drvinfo->version));
> +}
> +
> +int failover_ethtool_get_link_ksettings(struct net_device *dev,
> + struct ethtool_link_ksettings *cmd)
> +{
> + struct failover_info *finfo = netdev_priv(dev);
> + struct net_device *slave_dev;
> +
> + slave_dev = rtnl_dereference(finfo->primary_dev);
> + if (!slave_dev || !failover_xmit_ready(slave_dev)) {
> + slave_dev = rtnl_dereference(finfo->standby_dev);
> + if (!slave_dev || !failover_xmit_ready(slave_dev)) {
> + cmd->base.duplex = DUPLEX_UNKNOWN;
> + cmd->base.port = PORT_OTHER;
> + cmd->base.speed = SPEED_UNKNOWN;
> +
> + return 0;
> + }
> + }
> +
> + return __ethtool_get_link_ksettings(slave_dev, cmd);
> +}
> +EXPORT_SYMBOL_GPL(failover_ethtool_get_link_ksettings);
> +
> +static const struct ethtool_ops failover_ethtool_ops = {
> + .get_drvinfo = failover_ethtool_get_drvinfo,
> + .get_link = ethtool_op_get_link,
> + .get_link_ksettings = failover_ethtool_get_link_ksettings,
> +};
> +
> +static void failover_register_existing_slave(struct net_device *failover_dev)
> +{
> + struct net *net = dev_net(failover_dev);
> + struct net_device *dev;
> +
> + rtnl_lock();
> + for_each_netdev(net, dev) {
> + if (dev == failover_dev)
> + continue;
> + if (!failover_validate_event_dev(dev))
> + continue;
> + if (ether_addr_equal(failover_dev->perm_addr, dev->perm_addr))
> + failover_slave_register(dev);
> + }
> + rtnl_unlock();
> +}
> +
> +int failover_register(struct net_device *dev, struct failover_ops *ops,
> + struct failover **pfailover)
> +{
> + struct failover *failover;
> +
> + failover = kzalloc(sizeof(*failover), GFP_KERNEL);
> + if (!failover)
> + return -ENOMEM;
> +
> + rcu_assign_pointer(failover->ops, ops);
> + dev_hold(dev);
> + dev->priv_flags |= IFF_FAILOVER;
> + rcu_assign_pointer(failover->failover_dev, dev);
> +
> + spin_lock(&failover_lock);
> + list_add_tail(&failover->list, &failover_list);
> + spin_unlock(&failover_lock);
> +
> + failover_register_existing_slave(dev);
> +
> + *pfailover = failover;
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(failover_register);
> +
> +void failover_unregister(struct failover *failover)
> +{
> + struct net_device *failover_dev;
> +
> + failover_dev = rcu_dereference(failover->failover_dev);
> +
> + failover_dev->priv_flags &= ~IFF_FAILOVER;
> + dev_put(failover_dev);
> +
> + spin_lock(&failover_lock);
> + list_del(&failover->list);
> + spin_unlock(&failover_lock);
> +
> + kfree(failover);
> +}
> +EXPORT_SYMBOL_GPL(failover_unregister);
> +
> +int failover_create(struct net_device *standby_dev, struct failover **pfailover)
> +{
> + struct device *dev = standby_dev->dev.parent;
> + struct net_device *failover_dev;
> + int err;
> +
> + /* Alloc at least 2 queues, for now we are going with 16 assuming
> + * that most devices being bonded won't have too many queues.
> + */
> + failover_dev = alloc_etherdev_mq(sizeof(struct failover_info), 16);
> + if (!failover_dev) {
> + dev_err(dev, "Unable to allocate failover_netdev!\n");
> + return -ENOMEM;
> + }
> +
> + dev_net_set(failover_dev, dev_net(standby_dev));
> + SET_NETDEV_DEV(failover_dev, dev);
> +
> + failover_dev->netdev_ops = &failover_dev_ops;
> + failover_dev->ethtool_ops = &failover_ethtool_ops;
> +
> + /* Initialize the device options */
> + failover_dev->priv_flags |= IFF_UNICAST_FLT | IFF_NO_QUEUE;
> + failover_dev->priv_flags &= ~(IFF_XMIT_DST_RELEASE |
> + IFF_TX_SKB_SHARING);
> +
> + /* don't acquire failover netdev's netif_tx_lock when transmitting */
> + failover_dev->features |= NETIF_F_LLTX;
> +
> + /* Don't allow failover devices to change network namespaces. */
> + failover_dev->features |= NETIF_F_NETNS_LOCAL;
> +
> + failover_dev->hw_features = NETIF_F_HW_CSUM | NETIF_F_SG |
> + NETIF_F_FRAGLIST | NETIF_F_ALL_TSO |
> + NETIF_F_HIGHDMA | NETIF_F_LRO;
OK but then you must make sure your primary and standby both
support these features.
> +
> + failover_dev->hw_features |= NETIF_F_GSO_ENCAP_ALL;
> + failover_dev->features |= failover_dev->hw_features;
> +
> + memcpy(failover_dev->dev_addr, standby_dev->dev_addr,
> + failover_dev->addr_len);
> +
> + failover_dev->min_mtu = standby_dev->min_mtu;
> + failover_dev->max_mtu = standby_dev->max_mtu;
OK MTU is copied, fine. But is this always enough?
How about e.g. hard_header_len? min_header_len? needed_headroom?
needed_tailroom? I'd worry that even if you cover existing ones more
might be added with time. A function copying config between devices
probably belongs in some central place IMHO.
> +
> + err = register_netdev(failover_dev);
> + if (err < 0) {
> + dev_err(dev, "Unable to register failover_dev!\n");
> + goto err_register_netdev;
> + }
> +
> + netif_carrier_off(failover_dev);
> +
> + err = failover_register(failover_dev, NULL, pfailover);
> + if (err < 0)
> + goto err_failover;
> +
> + return 0;
> +
> +err_failover:
> + unregister_netdev(failover_dev);
> +err_register_netdev:
> + free_netdev(failover_dev);
> +
> + return err;
> +}
> +EXPORT_SYMBOL_GPL(failover_create);
> +
> +void failover_destroy(struct failover *failover)
> +{
> + struct net_device *failover_dev;
> + struct net_device *slave_dev;
> + struct failover_info *finfo;
> +
> + if (!failover)
> + return;
> +
> + failover_dev = rcu_dereference(failover->failover_dev);
> + finfo = netdev_priv(failover_dev);
> +
> + netif_device_detach(failover_dev);
> +
> + rtnl_lock();
> +
> + slave_dev = rtnl_dereference(finfo->primary_dev);
> + if (slave_dev)
> + failover_slave_unregister(slave_dev);
> +
> + slave_dev = rtnl_dereference(finfo->standby_dev);
> + if (slave_dev)
> + failover_slave_unregister(slave_dev);
> +
> + failover_unregister(failover);
> +
> + unregister_netdevice(failover_dev);
> +
> + rtnl_unlock();
> +
> + free_netdev(failover_dev);
> +}
> +EXPORT_SYMBOL_GPL(failover_destroy);
> +
> +static __init int
> +failover_init(void)
> +{
> + register_netdevice_notifier(&failover_notifier);
> +
> + return 0;
> +}
> +module_init(failover_init);
> +
> +static __exit
> +void failover_exit(void)
> +{
> + unregister_netdevice_notifier(&failover_notifier);
> +}
> +module_exit(failover_exit);
> +
> +MODULE_DESCRIPTION("Failover infrastructure/interface for Paravirtual drivers");
> +MODULE_LICENSE("GPL v2");
> --
> 2.14.3
^ permalink raw reply [flat|nested] 114+ messages in thread
* [virtio-dev] Re: [PATCH v7 net-next 2/4] net: Introduce generic failover module
@ 2018-04-20 2:44 ` Michael S. Tsirkin
0 siblings, 0 replies; 114+ messages in thread
From: Michael S. Tsirkin @ 2018-04-20 2:44 UTC (permalink / raw)
To: Sridhar Samudrala
Cc: stephen, davem, netdev, virtualization, virtio-dev,
jesse.brandeburg, alexander.h.duyck, kubakici, jasowang,
loseweigh, jiri
On Thu, Apr 19, 2018 at 06:42:02PM -0700, Sridhar Samudrala wrote:
> This provides a generic interface for paravirtual drivers to listen
> for netdev register/unregister/link change events from pci ethernet
> devices with the same MAC and takeover their datapath. The notifier and
> event handling code is based on the existing netvsc implementation.
>
> It exposes 2 sets of interfaces to the paravirtual drivers.
> 1. existing netvsc driver that uses 2 netdev model. In this model, no
> master netdev is created. The paravirtual driver registers each instance
> of netvsc as a 'failover' instance along with a set of ops to manage the
> slave events.
> failover_register()
> failover_unregister()
> 2. new virtio_net based solution that uses 3 netdev model. In this model,
> the failover module provides interfaces to create/destroy additional master
> netdev and all the slave events are managed internally.
> failover_create()
> failover_destroy()
> These functions call failover_register()/failover_unregister() with the
> master netdev created by the failover module.
>
> Signed-off-by: Sridhar Samudrala <sridhar.samudrala@intel.com>
I like this patch. Yes something to improve (see below)
> ---
> include/linux/netdevice.h | 16 +
> include/net/failover.h | 96 ++++++
> net/Kconfig | 18 +
> net/core/Makefile | 1 +
> net/core/failover.c | 844 ++++++++++++++++++++++++++++++++++++++++++++++
> 5 files changed, 975 insertions(+)
> create mode 100644 include/net/failover.h
> create mode 100644 net/core/failover.c
>
> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> index cf44503ea81a..ed535b6724e1 100644
> --- a/include/linux/netdevice.h
> +++ b/include/linux/netdevice.h
> @@ -1401,6 +1401,8 @@ struct net_device_ops {
> * entity (i.e. the master device for bridged veth)
> * @IFF_MACSEC: device is a MACsec device
> * @IFF_NO_RX_HANDLER: device doesn't support the rx_handler hook
> + * @IFF_FAILOVER: device is a failover master device
> + * @IFF_FAILOVER_SLAVE: device is lower dev of a failover master device
> */
> enum netdev_priv_flags {
> IFF_802_1Q_VLAN = 1<<0,
> @@ -1430,6 +1432,8 @@ enum netdev_priv_flags {
> IFF_PHONY_HEADROOM = 1<<24,
> IFF_MACSEC = 1<<25,
> IFF_NO_RX_HANDLER = 1<<26,
> + IFF_FAILOVER = 1<<27,
> + IFF_FAILOVER_SLAVE = 1<<28,
> };
>
> #define IFF_802_1Q_VLAN IFF_802_1Q_VLAN
> @@ -1458,6 +1462,8 @@ enum netdev_priv_flags {
> #define IFF_RXFH_CONFIGURED IFF_RXFH_CONFIGURED
> #define IFF_MACSEC IFF_MACSEC
> #define IFF_NO_RX_HANDLER IFF_NO_RX_HANDLER
> +#define IFF_FAILOVER IFF_FAILOVER
> +#define IFF_FAILOVER_SLAVE IFF_FAILOVER_SLAVE
>
> /**
> * struct net_device - The DEVICE structure.
> @@ -4308,6 +4314,16 @@ static inline bool netif_is_rxfh_configured(const struct net_device *dev)
> return dev->priv_flags & IFF_RXFH_CONFIGURED;
> }
>
> +static inline bool netif_is_failover(const struct net_device *dev)
> +{
> + return dev->priv_flags & IFF_FAILOVER;
> +}
> +
> +static inline bool netif_is_failover_slave(const struct net_device *dev)
> +{
> + return dev->priv_flags & IFF_FAILOVER_SLAVE;
> +}
> +
> /* This device needs to keep skb dst for qdisc enqueue or ndo_start_xmit() */
> static inline void netif_keep_dst(struct net_device *dev)
> {
> diff --git a/include/net/failover.h b/include/net/failover.h
> new file mode 100644
> index 000000000000..0b8601043d90
> --- /dev/null
> +++ b/include/net/failover.h
> @@ -0,0 +1,96 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/* Copyright (c) 2018, Intel Corporation. */
> +
> +#ifndef _NET_FAILOVER_H
> +#define _NET_FAILOVER_H
> +
> +#include <linux/netdevice.h>
> +
> +struct failover_ops {
> + int (*slave_pre_register)(struct net_device *slave_dev,
> + struct net_device *failover_dev);
> + int (*slave_join)(struct net_device *slave_dev,
> + struct net_device *failover_dev);
> + int (*slave_pre_unregister)(struct net_device *slave_dev,
> + struct net_device *failover_dev);
> + int (*slave_release)(struct net_device *slave_dev,
> + struct net_device *failover_dev);
> + int (*slave_link_change)(struct net_device *slave_dev,
> + struct net_device *failover_dev);
> + rx_handler_result_t (*handle_frame)(struct sk_buff **pskb);
> +};
> +
> +struct failover {
> + struct list_head list;
> + struct net_device __rcu *failover_dev;
> + struct failover_ops __rcu *ops;
> +};
> +
> +/* failover state */
> +struct failover_info {
> + /* primary netdev with same MAC */
> + struct net_device __rcu *primary_dev;
> +
> + /* standby netdev */
> + struct net_device __rcu *standby_dev;
> +
> + /* primary netdev stats */
> + struct rtnl_link_stats64 primary_stats;
> +
> + /* standby netdev stats */
> + struct rtnl_link_stats64 standby_stats;
> +
> + /* aggregated stats */
> + struct rtnl_link_stats64 failover_stats;
> +
> + /* spinlock while updating stats */
> + spinlock_t stats_lock;
> +};
> +
> +#if IS_ENABLED(CONFIG_NET_FAILOVER)
> +
> +int failover_create(struct net_device *standby_dev,
> + struct failover **pfailover);
> +void failover_destroy(struct failover *failover);
> +
> +int failover_register(struct net_device *standby_dev, struct failover_ops *ops,
> + struct failover **pfailover);
> +void failover_unregister(struct failover *failover);
> +
> +int failover_slave_unregister(struct net_device *slave_dev);
> +
> +#else
> +
> +static inline
> +int failover_create(struct net_device *standby_dev,
> + struct failover **pfailover);
> +{
> + return 0;
> +}
> +
> +static inline
> +void failover_destroy(struct failover *failover)
> +{
> +}
> +
> +static inline
> +int failover_register(struct net_device *standby_dev, struct failover_ops *ops,
> + struct pfailover **pfailover);
> +{
> + return 0;
> +}
> +
> +static inline
> +void failover_unregister(struct failover *failover)
> +{
> +}
> +
> +static inline
> +int failover_slave_unregister(struct net_device *slave_dev)
> +{
> + return 0;
> +}
> +
> +#endif
> +
> +#endif /* _NET_FAILOVER_H */
> diff --git a/net/Kconfig b/net/Kconfig
> index 0428f12c25c2..388b99dfee10 100644
> --- a/net/Kconfig
> +++ b/net/Kconfig
> @@ -423,6 +423,24 @@ config MAY_USE_DEVLINK
> on MAY_USE_DEVLINK to ensure they do not cause link errors when
> devlink is a loadable module and the driver using it is built-in.
>
> +config NET_FAILOVER
> + tristate "Failover interface"
> + help
> + This provides a generic interface for paravirtual drivers to listen
> + for netdev register/unregister/link change events from pci ethernet
> + devices with the same MAC and takeover their datapath. This also
> + enables live migration of a VM with direct attached VF by failing
> + over to the paravirtual datapath when the VF is unplugged.
> +
> +config MAY_USE_FAILOVER
> + tristate
> + default m if NET_FAILOVER=m
> + default y if NET_FAILOVER=y || NET_FAILOVER=n
> + help
> + Drivers using the failover infrastructure should have a dependency
> + on MAY_USE_FAILOVER to ensure they do not cause link errors when
> + failover is a loadable module and the driver using it is built-in.
> +
> endif # if NET
>
> # Used by archs to tell that they support BPF JIT compiler plus which flavour.
> diff --git a/net/core/Makefile b/net/core/Makefile
> index 6dbbba8c57ae..cef17518bb7d 100644
> --- a/net/core/Makefile
> +++ b/net/core/Makefile
> @@ -30,3 +30,4 @@ obj-$(CONFIG_DST_CACHE) += dst_cache.o
> obj-$(CONFIG_HWBM) += hwbm.o
> obj-$(CONFIG_NET_DEVLINK) += devlink.o
> obj-$(CONFIG_GRO_CELLS) += gro_cells.o
> +obj-$(CONFIG_NET_FAILOVER) += failover.o
> diff --git a/net/core/failover.c b/net/core/failover.c
> new file mode 100644
> index 000000000000..7bee762cb737
> --- /dev/null
> +++ b/net/core/failover.c
> @@ -0,0 +1,844 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/* Copyright (c) 2018, Intel Corporation. */
I think you should copy the header from bond_main.c upon which
some of the code seems to be based.
> +
> +/* A common module to handle registrations and notifications for paravirtual
> + * drivers to enable accelerated datapath and support VF live migration.
> + *
> + * The notifier and event handling code is based on netvsc driver.
> + */
> +
> +#include <linux/netdevice.h>
> +#include <linux/etherdevice.h>
> +#include <linux/ethtool.h>
> +#include <linux/module.h>
> +#include <linux/slab.h>
> +#include <linux/netdevice.h>
> +#include <linux/netpoll.h>
> +#include <linux/rtnetlink.h>
> +#include <linux/if_vlan.h>
> +#include <linux/pci.h>
> +#include <net/sch_generic.h>
> +#include <uapi/linux/if_arp.h>
> +#include <net/failover.h>
> +
> +static LIST_HEAD(failover_list);
> +static DEFINE_SPINLOCK(failover_lock);
> +
> +static int failover_slave_pre_register(struct net_device *slave_dev,
> + struct net_device *failover_dev,
> + struct failover_ops *failover_ops)
> +{
> + struct failover_info *finfo;
> + bool standby;
> +
> + if (failover_ops) {
> + if (!failover_ops->slave_pre_register)
> + return -EINVAL;
> +
> + return failover_ops->slave_pre_register(slave_dev,
> + failover_dev);
> + }
> +
> + finfo = netdev_priv(failover_dev);
> + standby = (slave_dev->dev.parent == failover_dev->dev.parent);
> + if (standby ? rtnl_dereference(finfo->standby_dev) :
> + rtnl_dereference(finfo->primary_dev)) {
> + netdev_err(failover_dev, "%s attempting to register as slave dev when %s already present\n",
> + slave_dev->name, standby ? "standby" : "primary");
> + return -EEXIST;
> + }
> +
> + /* Avoid non pci devices as primary netdev */
Why? Pls change this comment so it explains the motivation
rather than just repeat what the code does.
> + if (!standby && (!slave_dev->dev.parent ||
> + !dev_is_pci(slave_dev->dev.parent)))
> + return -EINVAL;
> +
> + return 0;
> +}
> +
> +static int failover_slave_join(struct net_device *slave_dev,
> + struct net_device *failover_dev,
> + struct failover_ops *failover_ops)
> +{
> + struct failover_info *finfo;
> + int err, orig_mtu;
> + bool standby;
> +
> + if (failover_ops) {
> + if (!failover_ops->slave_join)
> + return -EINVAL;
> +
> + return failover_ops->slave_join(slave_dev, failover_dev);
> + }
> +
> + if (netif_running(failover_dev)) {
> + err = dev_open(slave_dev);
> + if (err && (err != -EBUSY)) {
> + netdev_err(failover_dev, "Opening slave %s failed err:%d\n",
> + slave_dev->name, err);
> + goto err_dev_open;
> + }
> + }
> +
> + /* Align MTU of slave with failover dev */
> + orig_mtu = slave_dev->mtu;
I suspect this was copied from bond. this variable is never
used and I'm even surprised gcc did not warn about this.
> + err = dev_set_mtu(slave_dev, failover_dev->mtu);
How do we know slave supports this MTU? same applies to
failover_change_mtu.
> + if (err) {
> + netdev_err(failover_dev, "unable to change mtu of %s to %u register failed\n",
> + slave_dev->name, failover_dev->mtu);
> + goto err_set_mtu;
> + }
> +
> + finfo = netdev_priv(failover_dev);
> + standby = (slave_dev->dev.parent == failover_dev->dev.parent);
> +
> + dev_hold(slave_dev);
> +
> + if (standby) {
> + rcu_assign_pointer(finfo->standby_dev, slave_dev);
> + dev_get_stats(finfo->standby_dev, &finfo->standby_stats);
> + } else {
> + rcu_assign_pointer(finfo->primary_dev, slave_dev);
> + dev_get_stats(finfo->primary_dev, &finfo->primary_stats);
> + failover_dev->min_mtu = slave_dev->min_mtu;
> + failover_dev->max_mtu = slave_dev->max_mtu;
> + }
> +
> + netdev_info(failover_dev, "failover slave:%s joined\n",
> + slave_dev->name);
> +
> + return 0;
> +
> +err_set_mtu:
> + dev_close(slave_dev);
> +err_dev_open:
> + return err;
> +}
> +
> +/* Called when slave dev is injecting data into network stack.
> + * Change the associated network device from lower dev to virtio.
> + * note: already called with rcu_read_lock
> + */
> +static rx_handler_result_t failover_handle_frame(struct sk_buff **pskb)
> +{
> + struct sk_buff *skb = *pskb;
> + struct net_device *ndev = rcu_dereference(skb->dev->rx_handler_data);
> +
> + skb->dev = ndev;
> +
> + return RX_HANDLER_ANOTHER;
> +}
> +
> +static struct net_device *failover_get_bymac(u8 *mac, struct failover_ops **ops)
> +{
> + struct net_device *failover_dev;
> + struct failover *failover;
> +
> + spin_lock(&failover_lock);
> + list_for_each_entry(failover, &failover_list, list) {
> + failover_dev = rtnl_dereference(failover->failover_dev);
> + if (ether_addr_equal(failover_dev->perm_addr, mac)) {
> + *ops = rtnl_dereference(failover->ops);
> + spin_unlock(&failover_lock);
> + return failover_dev;
> + }
> + }
> + spin_unlock(&failover_lock);
> + return NULL;
> +}
> +
> +static int failover_slave_register(struct net_device *slave_dev)
> +{
> + struct failover_ops *failover_ops;
> + struct net_device *failover_dev;
> + int ret;
> +
> + ASSERT_RTNL();
> +
> + failover_dev = failover_get_bymac(slave_dev->perm_addr, &failover_ops);
> + if (!failover_dev)
> + goto done;
> +
> + ret = failover_slave_pre_register(slave_dev, failover_dev,
> + failover_ops);
> + if (ret)
> + goto done;
> +
> + ret = netdev_rx_handler_register(slave_dev, failover_ops ?
> + failover_ops->handle_frame :
> + failover_handle_frame, failover_dev);
> + if (ret) {
> + netdev_err(slave_dev, "can not register failover rx handler (err = %d)\n",
> + ret);
> + goto done;
> + }
> +
> + ret = netdev_upper_dev_link(slave_dev, failover_dev, NULL);
> + if (ret) {
> + netdev_err(slave_dev, "can not set failover device %s (err = %d)\n",
> + failover_dev->name, ret);
> + goto upper_link_failed;
> + }
> +
> + slave_dev->priv_flags |= IFF_FAILOVER_SLAVE;
> +
> + ret = failover_slave_join(slave_dev, failover_dev, failover_ops);
> + if (ret)
> + goto err_join;
> +
> + call_netdevice_notifiers(NETDEV_JOIN, slave_dev);
> +
> + netdev_info(failover_dev, "failover slave:%s registered\n",
> + slave_dev->name);
> +
> + goto done;
> +
> +err_join:
> + netdev_upper_dev_unlink(slave_dev, failover_dev);
> + slave_dev->priv_flags &= ~IFF_FAILOVER_SLAVE;
> +upper_link_failed:
> + netdev_rx_handler_unregister(slave_dev);
> +done:
> + return NOTIFY_DONE;
> +}
> +
> +static int failover_slave_pre_unregister(struct net_device *slave_dev,
> + struct net_device *failover_dev,
> + struct failover_ops *failover_ops)
> +{
> + struct net_device *standby_dev, *primary_dev;
> + struct failover_info *finfo;
> +
> + if (failover_ops) {
> + if (!failover_ops->slave_pre_unregister)
> + return -EINVAL;
> +
> + return failover_ops->slave_pre_unregister(slave_dev,
> + failover_dev);
> + }
> +
> + finfo = netdev_priv(failover_dev);
> + primary_dev = rtnl_dereference(finfo->primary_dev);
> + standby_dev = rtnl_dereference(finfo->standby_dev);
> +
> + if (slave_dev != primary_dev && slave_dev != standby_dev)
> + return -EINVAL;
> +
> + return 0;
> +}
> +
> +static int failover_slave_release(struct net_device *slave_dev,
> + struct net_device *failover_dev,
> + struct failover_ops *failover_ops)
> +{
> + struct net_device *standby_dev, *primary_dev;
> + struct failover_info *finfo;
> +
> + if (failover_ops) {
> + if (!failover_ops->slave_release)
> + return -EINVAL;
> +
> + return failover_ops->slave_release(slave_dev, failover_dev);
> + }
> +
> + finfo = netdev_priv(failover_dev);
> + primary_dev = rtnl_dereference(finfo->primary_dev);
> + standby_dev = rtnl_dereference(finfo->standby_dev);
> +
> + if (slave_dev == standby_dev) {
> + RCU_INIT_POINTER(finfo->standby_dev, NULL);
> + } else {
> + RCU_INIT_POINTER(finfo->primary_dev, NULL);
> + if (standby_dev) {
> + failover_dev->min_mtu = standby_dev->min_mtu;
> + failover_dev->max_mtu = standby_dev->max_mtu;
> + }
> + }
> +
> + dev_put(slave_dev);
> +
> + netdev_info(failover_dev, "failover slave:%s released\n",
> + slave_dev->name);
> +
> + return 0;
> +}
> +
> +int failover_slave_unregister(struct net_device *slave_dev)
> +{
> + struct failover_ops *failover_ops;
> + struct net_device *failover_dev;
> + int ret;
> +
> + if (!netif_is_failover_slave(slave_dev))
> + goto done;
> +
> + ASSERT_RTNL();
> +
> + failover_dev = failover_get_bymac(slave_dev->perm_addr, &failover_ops);
> + if (!failover_dev)
> + goto done;
> +
> + ret = failover_slave_pre_unregister(slave_dev, failover_dev,
> + failover_ops);
> + if (ret)
> + goto done;
> +
> + netdev_rx_handler_unregister(slave_dev);
> + netdev_upper_dev_unlink(slave_dev, failover_dev);
> + slave_dev->priv_flags &= ~IFF_FAILOVER_SLAVE;
> +
> + failover_slave_release(slave_dev, failover_dev, failover_ops);
Don't you need to get stats from it? This device is going away ...
> +
> + netdev_info(failover_dev, "failover slave:%s unregistered\n",
> + slave_dev->name);
> +
> +done:
> + return NOTIFY_DONE;
> +}
> +EXPORT_SYMBOL_GPL(failover_slave_unregister);
> +
> +static bool failover_xmit_ready(struct net_device *dev)
> +{
> + return netif_running(dev) && netif_carrier_ok(dev);
> +}
> +
> +static int failover_slave_link_change(struct net_device *slave_dev)
> +{
> + struct net_device *failover_dev, *primary_dev, *standby_dev;
> + struct failover_ops *failover_ops;
> + struct failover_info *finfo;
> +
> + if (!netif_is_failover_slave(slave_dev))
> + goto done;
> +
> + ASSERT_RTNL();
> +
> + failover_dev = failover_get_bymac(slave_dev->perm_addr, &failover_ops);
> + if (!failover_dev)
> + goto done;
> +
> + if (failover_ops) {
> + if (!failover_ops->slave_link_change)
> + goto done;
> +
> + return failover_ops->slave_link_change(slave_dev, failover_dev);
> + }
> +
> + if (!netif_running(failover_dev))
> + return 0;
> +
> + finfo = netdev_priv(failover_dev);
> +
> + primary_dev = rtnl_dereference(finfo->primary_dev);
> + standby_dev = rtnl_dereference(finfo->standby_dev);
> +
> + if (slave_dev != primary_dev && slave_dev != standby_dev)
> + goto done;
> +
> + if ((primary_dev && failover_xmit_ready(primary_dev)) ||
> + (standby_dev && failover_xmit_ready(standby_dev))) {
> + netif_carrier_on(failover_dev);
> + netif_tx_wake_all_queues(failover_dev);
> + } else {
> + netif_carrier_off(failover_dev);
> + netif_tx_stop_all_queues(failover_dev);
And I think it's a good idea to get stats from device here too.
> + }
> +
> +done:
> + return NOTIFY_DONE;
> +}
> +
> +static bool failover_validate_event_dev(struct net_device *dev)
> +{
> + /* Skip parent events */
> + if (netif_is_failover(dev))
> + return false;
> +
> + /* Avoid non-Ethernet type devices */
... for now. It would be possible easy to make this generic -
just copy things like type and addr_len from slave.
> + if (dev->type != ARPHRD_ETHER)
> + return false;
> +
> + return true;
> +}
> +
> +static int
> +failover_event(struct notifier_block *this, unsigned long event, void *ptr)
> +{
> + struct net_device *event_dev = netdev_notifier_info_to_dev(ptr);
> +
> + if (!failover_validate_event_dev(event_dev))
> + return NOTIFY_DONE;
> +
> + switch (event) {
> + case NETDEV_REGISTER:
> + return failover_slave_register(event_dev);
> + case NETDEV_UNREGISTER:
> + return failover_slave_unregister(event_dev);
> + case NETDEV_UP:
> + case NETDEV_DOWN:
> + case NETDEV_CHANGE:
> + return failover_slave_link_change(event_dev);
> + default:
> + return NOTIFY_DONE;
> + }
> +}
> +
> +static struct notifier_block failover_notifier = {
> + .notifier_call = failover_event,
> +};
> +
> +static int failover_open(struct net_device *dev)
> +{
> + struct failover_info *finfo = netdev_priv(dev);
> + struct net_device *primary_dev, *standby_dev;
> + int err;
> +
> + netif_carrier_off(dev);
> + netif_tx_wake_all_queues(dev);
> +
> + primary_dev = rtnl_dereference(finfo->primary_dev);
> + if (primary_dev) {
> + err = dev_open(primary_dev);
> + if (err)
> + goto err_primary_open;
> + }
> +
> + standby_dev = rtnl_dereference(finfo->standby_dev);
> + if (standby_dev) {
> + err = dev_open(standby_dev);
> + if (err)
> + goto err_standby_open;
> + }
> +
> + return 0;
> +
> +err_standby_open:
> + dev_close(primary_dev);
> +err_primary_open:
> + netif_tx_disable(dev);
> + return err;
> +}
> +
> +static int failover_close(struct net_device *dev)
> +{
> + struct failover_info *finfo = netdev_priv(dev);
> + struct net_device *slave_dev;
> +
> + netif_tx_disable(dev);
> +
> + slave_dev = rtnl_dereference(finfo->primary_dev);
> + if (slave_dev)
> + dev_close(slave_dev);
> +
> + slave_dev = rtnl_dereference(finfo->standby_dev);
> + if (slave_dev)
> + dev_close(slave_dev);
> +
> + return 0;
> +}
> +
> +static netdev_tx_t failover_drop_xmit(struct sk_buff *skb,
> + struct net_device *dev)
> +{
> + atomic_long_inc(&dev->tx_dropped);
> + dev_kfree_skb_any(skb);
> + return NETDEV_TX_OK;
> +}
> +
> +static netdev_tx_t failover_start_xmit(struct sk_buff *skb,
> + struct net_device *dev)
> +{
> + struct failover_info *finfo = netdev_priv(dev);
> + struct net_device *xmit_dev;
> +
> + /* Try xmit via primary netdev followed by standby netdev */
> + xmit_dev = rcu_dereference_bh(finfo->primary_dev);
> + if (!xmit_dev || !failover_xmit_ready(xmit_dev)) {
> + xmit_dev = rcu_dereference_bh(finfo->standby_dev);
> + if (!xmit_dev || !failover_xmit_ready(xmit_dev))
> + return failover_drop_xmit(skb, dev);
> + }
> +
> + skb->dev = xmit_dev;
> + skb->queue_mapping = qdisc_skb_cb(skb)->slave_dev_queue_mapping;
> +
> + return dev_queue_xmit(skb);
> +}
Is this going through qdisc twice? Won't this hurt performance
measureably?
> +
> +static u16 failover_select_queue(struct net_device *dev, struct sk_buff *skb,
> + void *accel_priv,
> + select_queue_fallback_t fallback)
> +{
> + struct failover_info *finfo = netdev_priv(dev);
> + struct net_device *primary_dev;
> + u16 txq;
> +
> + rcu_read_lock();
> + primary_dev = rcu_dereference(finfo->primary_dev);
> + if (primary_dev) {
> + const struct net_device_ops *ops = primary_dev->netdev_ops;
> +
> + if (ops->ndo_select_queue)
> + txq = ops->ndo_select_queue(primary_dev, skb,
> + accel_priv, fallback);
> + else
> + txq = fallback(primary_dev, skb);
> +
> + qdisc_skb_cb(skb)->slave_dev_queue_mapping = skb->queue_mapping;
> +
> + return txq;
> + }
> +
> + txq = skb_rx_queue_recorded(skb) ? skb_get_rx_queue(skb) : 0;
> +
> + /* Save the original txq to restore before passing to the driver */
> + qdisc_skb_cb(skb)->slave_dev_queue_mapping = skb->queue_mapping;
> +
> + if (unlikely(txq >= dev->real_num_tx_queues)) {
> + do {
> + txq -= dev->real_num_tx_queues;
> + } while (txq >= dev->real_num_tx_queues);
> + }
> +
> + return txq;
> +}
> +
> +/* fold stats, assuming all rtnl_link_stats64 fields are u64, but
> + * that some drivers can provide 32finfot values only.
> + */
> +static void failover_fold_stats(struct rtnl_link_stats64 *_res,
> + const struct rtnl_link_stats64 *_new,
> + const struct rtnl_link_stats64 *_old)
> +{
> + const u64 *new = (const u64 *)_new;
> + const u64 *old = (const u64 *)_old;
> + u64 *res = (u64 *)_res;
> + int i;
> +
> + for (i = 0; i < sizeof(*_res) / sizeof(u64); i++) {
> + u64 nv = new[i];
> + u64 ov = old[i];
> + s64 delta = nv - ov;
> +
> + /* detects if this particular field is 32bit only */
> + if (((nv | ov) >> 32) == 0)
> + delta = (s64)(s32)((u32)nv - (u32)ov);
> +
> + /* filter anomalies, some drivers reset their stats
> + * at down/up events.
> + */
> + if (delta > 0)
> + res[i] += delta;
> + }
> +}
> +
> +static void failover_get_stats(struct net_device *dev,
> + struct rtnl_link_stats64 *stats)
> +{
> + struct failover_info *finfo = netdev_priv(dev);
> + const struct rtnl_link_stats64 *new;
> + struct rtnl_link_stats64 temp;
> + struct net_device *slave_dev;
> +
> + spin_lock(&finfo->stats_lock);
> + memcpy(stats, &finfo->failover_stats, sizeof(*stats));
> +
> + rcu_read_lock();
> +
> + slave_dev = rcu_dereference(finfo->primary_dev);
> + if (slave_dev) {
> + new = dev_get_stats(slave_dev, &temp);
> + failover_fold_stats(stats, new, &finfo->primary_stats);
> + memcpy(&finfo->primary_stats, new, sizeof(*new));
> + }
> +
> + slave_dev = rcu_dereference(finfo->standby_dev);
> + if (slave_dev) {
> + new = dev_get_stats(slave_dev, &temp);
> + failover_fold_stats(stats, new, &finfo->standby_stats);
> + memcpy(&finfo->standby_stats, new, sizeof(*new));
> + }
> +
> + rcu_read_unlock();
> +
> + memcpy(&finfo->failover_stats, stats, sizeof(*stats));
> + spin_unlock(&finfo->stats_lock);
> +}
> +
> +static int failover_change_mtu(struct net_device *dev, int new_mtu)
> +{
> + struct failover_info *finfo = netdev_priv(dev);
> + struct net_device *primary_dev, *standby_dev;
> + int ret = 0;
> +
> + primary_dev = rcu_dereference(finfo->primary_dev);
> + if (primary_dev) {
> + ret = dev_set_mtu(primary_dev, new_mtu);
> + if (ret)
> + return ret;
> + }
> +
> + standby_dev = rcu_dereference(finfo->standby_dev);
> + if (standby_dev) {
> + ret = dev_set_mtu(standby_dev, new_mtu);
> + if (ret) {
> + dev_set_mtu(primary_dev, dev->mtu);
> + return ret;
> + }
> + }
> +
> + dev->mtu = new_mtu;
> + return 0;
> +}
> +
> +static void failover_set_rx_mode(struct net_device *dev)
> +{
> + struct failover_info *finfo = netdev_priv(dev);
> + struct net_device *slave_dev;
> +
> + rcu_read_lock();
> +
> + slave_dev = rcu_dereference(finfo->primary_dev);
> + if (slave_dev) {
> + dev_uc_sync_multiple(slave_dev, dev);
> + dev_mc_sync_multiple(slave_dev, dev);
> + }
> +
> + slave_dev = rcu_dereference(finfo->standby_dev);
> + if (slave_dev) {
> + dev_uc_sync_multiple(slave_dev, dev);
> + dev_mc_sync_multiple(slave_dev, dev);
> + }
> +
> + rcu_read_unlock();
> +}
> +
> +static const struct net_device_ops failover_dev_ops = {
> + .ndo_open = failover_open,
> + .ndo_stop = failover_close,
> + .ndo_start_xmit = failover_start_xmit,
> + .ndo_select_queue = failover_select_queue,
> + .ndo_get_stats64 = failover_get_stats,
> + .ndo_change_mtu = failover_change_mtu,
> + .ndo_set_rx_mode = failover_set_rx_mode,
> + .ndo_validate_addr = eth_validate_addr,
> + .ndo_features_check = passthru_features_check,
xdp support?
> +};
> +
> +#define FAILOVER_NAME "failover"
> +#define FAILOVER_VERSION "0.1"
> +
> +static void failover_ethtool_get_drvinfo(struct net_device *dev,
> + struct ethtool_drvinfo *drvinfo)
> +{
> + strlcpy(drvinfo->driver, FAILOVER_NAME, sizeof(drvinfo->driver));
> + strlcpy(drvinfo->version, FAILOVER_VERSION, sizeof(drvinfo->version));
> +}
> +
> +int failover_ethtool_get_link_ksettings(struct net_device *dev,
> + struct ethtool_link_ksettings *cmd)
> +{
> + struct failover_info *finfo = netdev_priv(dev);
> + struct net_device *slave_dev;
> +
> + slave_dev = rtnl_dereference(finfo->primary_dev);
> + if (!slave_dev || !failover_xmit_ready(slave_dev)) {
> + slave_dev = rtnl_dereference(finfo->standby_dev);
> + if (!slave_dev || !failover_xmit_ready(slave_dev)) {
> + cmd->base.duplex = DUPLEX_UNKNOWN;
> + cmd->base.port = PORT_OTHER;
> + cmd->base.speed = SPEED_UNKNOWN;
> +
> + return 0;
> + }
> + }
> +
> + return __ethtool_get_link_ksettings(slave_dev, cmd);
> +}
> +EXPORT_SYMBOL_GPL(failover_ethtool_get_link_ksettings);
> +
> +static const struct ethtool_ops failover_ethtool_ops = {
> + .get_drvinfo = failover_ethtool_get_drvinfo,
> + .get_link = ethtool_op_get_link,
> + .get_link_ksettings = failover_ethtool_get_link_ksettings,
> +};
> +
> +static void failover_register_existing_slave(struct net_device *failover_dev)
> +{
> + struct net *net = dev_net(failover_dev);
> + struct net_device *dev;
> +
> + rtnl_lock();
> + for_each_netdev(net, dev) {
> + if (dev == failover_dev)
> + continue;
> + if (!failover_validate_event_dev(dev))
> + continue;
> + if (ether_addr_equal(failover_dev->perm_addr, dev->perm_addr))
> + failover_slave_register(dev);
> + }
> + rtnl_unlock();
> +}
> +
> +int failover_register(struct net_device *dev, struct failover_ops *ops,
> + struct failover **pfailover)
> +{
> + struct failover *failover;
> +
> + failover = kzalloc(sizeof(*failover), GFP_KERNEL);
> + if (!failover)
> + return -ENOMEM;
> +
> + rcu_assign_pointer(failover->ops, ops);
> + dev_hold(dev);
> + dev->priv_flags |= IFF_FAILOVER;
> + rcu_assign_pointer(failover->failover_dev, dev);
> +
> + spin_lock(&failover_lock);
> + list_add_tail(&failover->list, &failover_list);
> + spin_unlock(&failover_lock);
> +
> + failover_register_existing_slave(dev);
> +
> + *pfailover = failover;
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(failover_register);
> +
> +void failover_unregister(struct failover *failover)
> +{
> + struct net_device *failover_dev;
> +
> + failover_dev = rcu_dereference(failover->failover_dev);
> +
> + failover_dev->priv_flags &= ~IFF_FAILOVER;
> + dev_put(failover_dev);
> +
> + spin_lock(&failover_lock);
> + list_del(&failover->list);
> + spin_unlock(&failover_lock);
> +
> + kfree(failover);
> +}
> +EXPORT_SYMBOL_GPL(failover_unregister);
> +
> +int failover_create(struct net_device *standby_dev, struct failover **pfailover)
> +{
> + struct device *dev = standby_dev->dev.parent;
> + struct net_device *failover_dev;
> + int err;
> +
> + /* Alloc at least 2 queues, for now we are going with 16 assuming
> + * that most devices being bonded won't have too many queues.
> + */
> + failover_dev = alloc_etherdev_mq(sizeof(struct failover_info), 16);
> + if (!failover_dev) {
> + dev_err(dev, "Unable to allocate failover_netdev!\n");
> + return -ENOMEM;
> + }
> +
> + dev_net_set(failover_dev, dev_net(standby_dev));
> + SET_NETDEV_DEV(failover_dev, dev);
> +
> + failover_dev->netdev_ops = &failover_dev_ops;
> + failover_dev->ethtool_ops = &failover_ethtool_ops;
> +
> + /* Initialize the device options */
> + failover_dev->priv_flags |= IFF_UNICAST_FLT | IFF_NO_QUEUE;
> + failover_dev->priv_flags &= ~(IFF_XMIT_DST_RELEASE |
> + IFF_TX_SKB_SHARING);
> +
> + /* don't acquire failover netdev's netif_tx_lock when transmitting */
> + failover_dev->features |= NETIF_F_LLTX;
> +
> + /* Don't allow failover devices to change network namespaces. */
> + failover_dev->features |= NETIF_F_NETNS_LOCAL;
> +
> + failover_dev->hw_features = NETIF_F_HW_CSUM | NETIF_F_SG |
> + NETIF_F_FRAGLIST | NETIF_F_ALL_TSO |
> + NETIF_F_HIGHDMA | NETIF_F_LRO;
OK but then you must make sure your primary and standby both
support these features.
> +
> + failover_dev->hw_features |= NETIF_F_GSO_ENCAP_ALL;
> + failover_dev->features |= failover_dev->hw_features;
> +
> + memcpy(failover_dev->dev_addr, standby_dev->dev_addr,
> + failover_dev->addr_len);
> +
> + failover_dev->min_mtu = standby_dev->min_mtu;
> + failover_dev->max_mtu = standby_dev->max_mtu;
OK MTU is copied, fine. But is this always enough?
How about e.g. hard_header_len? min_header_len? needed_headroom?
needed_tailroom? I'd worry that even if you cover existing ones more
might be added with time. A function copying config between devices
probably belongs in some central place IMHO.
> +
> + err = register_netdev(failover_dev);
> + if (err < 0) {
> + dev_err(dev, "Unable to register failover_dev!\n");
> + goto err_register_netdev;
> + }
> +
> + netif_carrier_off(failover_dev);
> +
> + err = failover_register(failover_dev, NULL, pfailover);
> + if (err < 0)
> + goto err_failover;
> +
> + return 0;
> +
> +err_failover:
> + unregister_netdev(failover_dev);
> +err_register_netdev:
> + free_netdev(failover_dev);
> +
> + return err;
> +}
> +EXPORT_SYMBOL_GPL(failover_create);
> +
> +void failover_destroy(struct failover *failover)
> +{
> + struct net_device *failover_dev;
> + struct net_device *slave_dev;
> + struct failover_info *finfo;
> +
> + if (!failover)
> + return;
> +
> + failover_dev = rcu_dereference(failover->failover_dev);
> + finfo = netdev_priv(failover_dev);
> +
> + netif_device_detach(failover_dev);
> +
> + rtnl_lock();
> +
> + slave_dev = rtnl_dereference(finfo->primary_dev);
> + if (slave_dev)
> + failover_slave_unregister(slave_dev);
> +
> + slave_dev = rtnl_dereference(finfo->standby_dev);
> + if (slave_dev)
> + failover_slave_unregister(slave_dev);
> +
> + failover_unregister(failover);
> +
> + unregister_netdevice(failover_dev);
> +
> + rtnl_unlock();
> +
> + free_netdev(failover_dev);
> +}
> +EXPORT_SYMBOL_GPL(failover_destroy);
> +
> +static __init int
> +failover_init(void)
> +{
> + register_netdevice_notifier(&failover_notifier);
> +
> + return 0;
> +}
> +module_init(failover_init);
> +
> +static __exit
> +void failover_exit(void)
> +{
> + unregister_netdevice_notifier(&failover_notifier);
> +}
> +module_exit(failover_exit);
> +
> +MODULE_DESCRIPTION("Failover infrastructure/interface for Paravirtual drivers");
> +MODULE_LICENSE("GPL v2");
> --
> 2.14.3
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 net-next 3/4] virtio_net: Extend virtio to use VF datapath when available
2018-04-20 1:42 ` [virtio-dev] " Sridhar Samudrala
@ 2018-04-20 2:46 ` Michael S. Tsirkin
-1 siblings, 0 replies; 114+ messages in thread
From: Michael S. Tsirkin @ 2018-04-20 2:46 UTC (permalink / raw)
To: Sridhar Samudrala
Cc: stephen, davem, netdev, virtualization, virtio-dev,
jesse.brandeburg, alexander.h.duyck, kubakici, jasowang,
loseweigh, jiri
On Thu, Apr 19, 2018 at 06:42:03PM -0700, Sridhar Samudrala wrote:
> @@ -3010,6 +3043,7 @@ static __init int virtio_net_driver_init(void)
> ret = register_virtio_driver(&virtio_net_driver);
> if (ret)
> goto err_virtio;
> +
> return 0;
> err_virtio:
> cpuhp_remove_multi_state(CPUHP_VIRT_NET_DEAD);
I'd rather you didn't let's not mix in whitespace changes.
> --
> 2.14.3
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 net-next 3/4] virtio_net: Extend virtio to use VF datapath when available
2018-04-20 1:42 ` [virtio-dev] " Sridhar Samudrala
(?)
(?)
@ 2018-04-20 2:46 ` Michael S. Tsirkin
-1 siblings, 0 replies; 114+ messages in thread
From: Michael S. Tsirkin @ 2018-04-20 2:46 UTC (permalink / raw)
To: Sridhar Samudrala
Cc: alexander.h.duyck, virtio-dev, jiri, kubakici, netdev,
virtualization, loseweigh, davem
On Thu, Apr 19, 2018 at 06:42:03PM -0700, Sridhar Samudrala wrote:
> @@ -3010,6 +3043,7 @@ static __init int virtio_net_driver_init(void)
> ret = register_virtio_driver(&virtio_net_driver);
> if (ret)
> goto err_virtio;
> +
> return 0;
> err_virtio:
> cpuhp_remove_multi_state(CPUHP_VIRT_NET_DEAD);
I'd rather you didn't let's not mix in whitespace changes.
> --
> 2.14.3
^ permalink raw reply [flat|nested] 114+ messages in thread
* [virtio-dev] Re: [PATCH v7 net-next 3/4] virtio_net: Extend virtio to use VF datapath when available
@ 2018-04-20 2:46 ` Michael S. Tsirkin
0 siblings, 0 replies; 114+ messages in thread
From: Michael S. Tsirkin @ 2018-04-20 2:46 UTC (permalink / raw)
To: Sridhar Samudrala
Cc: stephen, davem, netdev, virtualization, virtio-dev,
jesse.brandeburg, alexander.h.duyck, kubakici, jasowang,
loseweigh, jiri
On Thu, Apr 19, 2018 at 06:42:03PM -0700, Sridhar Samudrala wrote:
> @@ -3010,6 +3043,7 @@ static __init int virtio_net_driver_init(void)
> ret = register_virtio_driver(&virtio_net_driver);
> if (ret)
> goto err_virtio;
> +
> return 0;
> err_virtio:
> cpuhp_remove_multi_state(CPUHP_VIRT_NET_DEAD);
I'd rather you didn't let's not mix in whitespace changes.
> --
> 2.14.3
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 net-next 2/4] net: Introduce generic failover module
2018-04-20 1:42 ` [virtio-dev] " Sridhar Samudrala
@ 2018-04-20 3:34 ` Michael S. Tsirkin
-1 siblings, 0 replies; 114+ messages in thread
From: Michael S. Tsirkin @ 2018-04-20 3:34 UTC (permalink / raw)
To: Sridhar Samudrala
Cc: stephen, davem, netdev, virtualization, virtio-dev,
jesse.brandeburg, alexander.h.duyck, kubakici, jasowang,
loseweigh, jiri
On Thu, Apr 19, 2018 at 06:42:02PM -0700, Sridhar Samudrala wrote:
> +static struct net_device *failover_get_bymac(u8 *mac, struct failover_ops **ops)
> +{
> + struct net_device *failover_dev;
> + struct failover *failover;
> +
> + spin_lock(&failover_lock);
> + list_for_each_entry(failover, &failover_list, list) {
> + failover_dev = rtnl_dereference(failover->failover_dev);
> + if (ether_addr_equal(failover_dev->perm_addr, mac)) {
> + *ops = rtnl_dereference(failover->ops);
> + spin_unlock(&failover_lock);
> + return failover_dev;
> + }
> + }
> + spin_unlock(&failover_lock);
> + return NULL;
> +}
So it bothers me that this ties to just any device at all.
I thought hard about it, and I see a nice solution.
Here goes:
QEMU has a pci-bridge-seat device. It is used currently to
group e.g. input devices for multiseat support.
Now if you squint at it hard enough, you can see we are also
in a grouping problem. So how about the following:
1. allocate a virtio pci bridge device failover grouping id (reserve through virtio TC).
2. only group two devices in a failover configuration if both
are under the same bridge with this id (in addition to a mac check).
In particular a bridged configuration makes it easier to
make sure the standby is enumerated before the primary.
In fact we could fail init of failover if we see
appear standby *after* primary.
And this allows many devices with the same ethernet address
without any issues - just under separate bridges.
Further if we ever want to enumerate in parallel this can
be supported by adding a driver for the bridge.
In fact, I see how down the road such a device could
be the beginning of the more ambitious plan to
expose a powerful switchdev interface for
more advanced
So far so good, but I see a couple of issues:
- it is PCI specific
Not a big deal: we limit ourselves to PCI anyway ATM.
- does not work across PCI domains - which are helpful for NUMA
(e.g. we want to be able to move to primary
which is on a different numa
node without losing connectivity).
Idea: add a "group ID" register to each of these pci bridge
devices (e.g. in device specific config space).
Match two bridges if they have the same group ID.
- all these extra bridges slow enumeration down somewhat
Idea: as a fallback if no bridge is found,
just assume all devices match, which will result
in falling back on the "match by mac" logic like in
this patchset. Will be fine for simple setups.
Thoughts?
--
MST
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 net-next 2/4] net: Introduce generic failover module
2018-04-20 1:42 ` [virtio-dev] " Sridhar Samudrala
` (3 preceding siblings ...)
(?)
@ 2018-04-20 3:34 ` Michael S. Tsirkin
-1 siblings, 0 replies; 114+ messages in thread
From: Michael S. Tsirkin @ 2018-04-20 3:34 UTC (permalink / raw)
To: Sridhar Samudrala
Cc: alexander.h.duyck, virtio-dev, jiri, kubakici, netdev,
virtualization, loseweigh, davem
On Thu, Apr 19, 2018 at 06:42:02PM -0700, Sridhar Samudrala wrote:
> +static struct net_device *failover_get_bymac(u8 *mac, struct failover_ops **ops)
> +{
> + struct net_device *failover_dev;
> + struct failover *failover;
> +
> + spin_lock(&failover_lock);
> + list_for_each_entry(failover, &failover_list, list) {
> + failover_dev = rtnl_dereference(failover->failover_dev);
> + if (ether_addr_equal(failover_dev->perm_addr, mac)) {
> + *ops = rtnl_dereference(failover->ops);
> + spin_unlock(&failover_lock);
> + return failover_dev;
> + }
> + }
> + spin_unlock(&failover_lock);
> + return NULL;
> +}
So it bothers me that this ties to just any device at all.
I thought hard about it, and I see a nice solution.
Here goes:
QEMU has a pci-bridge-seat device. It is used currently to
group e.g. input devices for multiseat support.
Now if you squint at it hard enough, you can see we are also
in a grouping problem. So how about the following:
1. allocate a virtio pci bridge device failover grouping id (reserve through virtio TC).
2. only group two devices in a failover configuration if both
are under the same bridge with this id (in addition to a mac check).
In particular a bridged configuration makes it easier to
make sure the standby is enumerated before the primary.
In fact we could fail init of failover if we see
appear standby *after* primary.
And this allows many devices with the same ethernet address
without any issues - just under separate bridges.
Further if we ever want to enumerate in parallel this can
be supported by adding a driver for the bridge.
In fact, I see how down the road such a device could
be the beginning of the more ambitious plan to
expose a powerful switchdev interface for
more advanced
So far so good, but I see a couple of issues:
- it is PCI specific
Not a big deal: we limit ourselves to PCI anyway ATM.
- does not work across PCI domains - which are helpful for NUMA
(e.g. we want to be able to move to primary
which is on a different numa
node without losing connectivity).
Idea: add a "group ID" register to each of these pci bridge
devices (e.g. in device specific config space).
Match two bridges if they have the same group ID.
- all these extra bridges slow enumeration down somewhat
Idea: as a fallback if no bridge is found,
just assume all devices match, which will result
in falling back on the "match by mac" logic like in
this patchset. Will be fine for simple setups.
Thoughts?
--
MST
^ permalink raw reply [flat|nested] 114+ messages in thread
* [virtio-dev] Re: [PATCH v7 net-next 2/4] net: Introduce generic failover module
@ 2018-04-20 3:34 ` Michael S. Tsirkin
0 siblings, 0 replies; 114+ messages in thread
From: Michael S. Tsirkin @ 2018-04-20 3:34 UTC (permalink / raw)
To: Sridhar Samudrala
Cc: stephen, davem, netdev, virtualization, virtio-dev,
jesse.brandeburg, alexander.h.duyck, kubakici, jasowang,
loseweigh, jiri
On Thu, Apr 19, 2018 at 06:42:02PM -0700, Sridhar Samudrala wrote:
> +static struct net_device *failover_get_bymac(u8 *mac, struct failover_ops **ops)
> +{
> + struct net_device *failover_dev;
> + struct failover *failover;
> +
> + spin_lock(&failover_lock);
> + list_for_each_entry(failover, &failover_list, list) {
> + failover_dev = rtnl_dereference(failover->failover_dev);
> + if (ether_addr_equal(failover_dev->perm_addr, mac)) {
> + *ops = rtnl_dereference(failover->ops);
> + spin_unlock(&failover_lock);
> + return failover_dev;
> + }
> + }
> + spin_unlock(&failover_lock);
> + return NULL;
> +}
So it bothers me that this ties to just any device at all.
I thought hard about it, and I see a nice solution.
Here goes:
QEMU has a pci-bridge-seat device. It is used currently to
group e.g. input devices for multiseat support.
Now if you squint at it hard enough, you can see we are also
in a grouping problem. So how about the following:
1. allocate a virtio pci bridge device failover grouping id (reserve through virtio TC).
2. only group two devices in a failover configuration if both
are under the same bridge with this id (in addition to a mac check).
In particular a bridged configuration makes it easier to
make sure the standby is enumerated before the primary.
In fact we could fail init of failover if we see
appear standby *after* primary.
And this allows many devices with the same ethernet address
without any issues - just under separate bridges.
Further if we ever want to enumerate in parallel this can
be supported by adding a driver for the bridge.
In fact, I see how down the road such a device could
be the beginning of the more ambitious plan to
expose a powerful switchdev interface for
more advanced
So far so good, but I see a couple of issues:
- it is PCI specific
Not a big deal: we limit ourselves to PCI anyway ATM.
- does not work across PCI domains - which are helpful for NUMA
(e.g. we want to be able to move to primary
which is on a different numa
node without losing connectivity).
Idea: add a "group ID" register to each of these pci bridge
devices (e.g. in device specific config space).
Match two bridges if they have the same group ID.
- all these extra bridges slow enumeration down somewhat
Idea: as a fallback if no bridge is found,
just assume all devices match, which will result
in falling back on the "match by mac" logic like in
this patchset. Will be fine for simple setups.
Thoughts?
--
MST
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 net-next 2/4] net: Introduce generic failover module
2018-04-20 2:44 ` [virtio-dev] " Michael S. Tsirkin
@ 2018-04-20 15:21 ` Samudrala, Sridhar
-1 siblings, 0 replies; 114+ messages in thread
From: Samudrala, Sridhar @ 2018-04-20 15:21 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: stephen, davem, netdev, virtualization, virtio-dev,
jesse.brandeburg, alexander.h.duyck, kubakici, jasowang,
loseweigh, jiri
On 4/19/2018 7:44 PM, Michael S. Tsirkin wrote:
> On Thu, Apr 19, 2018 at 06:42:02PM -0700, Sridhar Samudrala wrote:
>> This provides a generic interface for paravirtual drivers to listen
>> for netdev register/unregister/link change events from pci ethernet
>> devices with the same MAC and takeover their datapath. The notifier and
>> event handling code is based on the existing netvsc implementation.
>>
>> It exposes 2 sets of interfaces to the paravirtual drivers.
>> 1. existing netvsc driver that uses 2 netdev model. In this model, no
>> master netdev is created. The paravirtual driver registers each instance
>> of netvsc as a 'failover' instance along with a set of ops to manage the
>> slave events.
>> failover_register()
>> failover_unregister()
>> 2. new virtio_net based solution that uses 3 netdev model. In this model,
>> the failover module provides interfaces to create/destroy additional master
>> netdev and all the slave events are managed internally.
>> failover_create()
>> failover_destroy()
>> These functions call failover_register()/failover_unregister() with the
>> master netdev created by the failover module.
>>
>> Signed-off-by: Sridhar Samudrala <sridhar.samudrala@intel.com>
> I like this patch. Yes something to improve (see below)
>
>> ---
>> include/linux/netdevice.h | 16 +
>> include/net/failover.h | 96 ++++++
>> net/Kconfig | 18 +
>> net/core/Makefile | 1 +
>> net/core/failover.c | 844 ++++++++++++++++++++++++++++++++++++++++++++++
>> 5 files changed, 975 insertions(+)
>> create mode 100644 include/net/failover.h
>> create mode 100644 net/core/failover.c
>>
>> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
>> index cf44503ea81a..ed535b6724e1 100644
>> --- a/include/linux/netdevice.h
>> +++ b/include/linux/netdevice.h
>> @@ -1401,6 +1401,8 @@ struct net_device_ops {
>> * entity (i.e. the master device for bridged veth)
>> * @IFF_MACSEC: device is a MACsec device
>> * @IFF_NO_RX_HANDLER: device doesn't support the rx_handler hook
>> + * @IFF_FAILOVER: device is a failover master device
>> + * @IFF_FAILOVER_SLAVE: device is lower dev of a failover master device
>> */
>> enum netdev_priv_flags {
>> IFF_802_1Q_VLAN = 1<<0,
>> @@ -1430,6 +1432,8 @@ enum netdev_priv_flags {
>> IFF_PHONY_HEADROOM = 1<<24,
>> IFF_MACSEC = 1<<25,
>> IFF_NO_RX_HANDLER = 1<<26,
>> + IFF_FAILOVER = 1<<27,
>> + IFF_FAILOVER_SLAVE = 1<<28,
>> };
>>
>> #define IFF_802_1Q_VLAN IFF_802_1Q_VLAN
>> @@ -1458,6 +1462,8 @@ enum netdev_priv_flags {
>> #define IFF_RXFH_CONFIGURED IFF_RXFH_CONFIGURED
>> #define IFF_MACSEC IFF_MACSEC
>> #define IFF_NO_RX_HANDLER IFF_NO_RX_HANDLER
>> +#define IFF_FAILOVER IFF_FAILOVER
>> +#define IFF_FAILOVER_SLAVE IFF_FAILOVER_SLAVE
>>
>> /**
>> * struct net_device - The DEVICE structure.
>> @@ -4308,6 +4314,16 @@ static inline bool netif_is_rxfh_configured(const struct net_device *dev)
>> return dev->priv_flags & IFF_RXFH_CONFIGURED;
>> }
>>
>> +static inline bool netif_is_failover(const struct net_device *dev)
>> +{
>> + return dev->priv_flags & IFF_FAILOVER;
>> +}
>> +
>> +static inline bool netif_is_failover_slave(const struct net_device *dev)
>> +{
>> + return dev->priv_flags & IFF_FAILOVER_SLAVE;
>> +}
>> +
>> /* This device needs to keep skb dst for qdisc enqueue or ndo_start_xmit() */
>> static inline void netif_keep_dst(struct net_device *dev)
>> {
>> diff --git a/include/net/failover.h b/include/net/failover.h
>> new file mode 100644
>> index 000000000000..0b8601043d90
>> --- /dev/null
>> +++ b/include/net/failover.h
>> @@ -0,0 +1,96 @@
>> +/* SPDX-License-Identifier: GPL-2.0 */
>> +/* Copyright (c) 2018, Intel Corporation. */
>> +
>> +#ifndef _NET_FAILOVER_H
>> +#define _NET_FAILOVER_H
>> +
>> +#include <linux/netdevice.h>
>> +
>> +struct failover_ops {
>> + int (*slave_pre_register)(struct net_device *slave_dev,
>> + struct net_device *failover_dev);
>> + int (*slave_join)(struct net_device *slave_dev,
>> + struct net_device *failover_dev);
>> + int (*slave_pre_unregister)(struct net_device *slave_dev,
>> + struct net_device *failover_dev);
>> + int (*slave_release)(struct net_device *slave_dev,
>> + struct net_device *failover_dev);
>> + int (*slave_link_change)(struct net_device *slave_dev,
>> + struct net_device *failover_dev);
>> + rx_handler_result_t (*handle_frame)(struct sk_buff **pskb);
>> +};
>> +
>> +struct failover {
>> + struct list_head list;
>> + struct net_device __rcu *failover_dev;
>> + struct failover_ops __rcu *ops;
>> +};
>> +
>> +/* failover state */
>> +struct failover_info {
>> + /* primary netdev with same MAC */
>> + struct net_device __rcu *primary_dev;
>> +
>> + /* standby netdev */
>> + struct net_device __rcu *standby_dev;
>> +
>> + /* primary netdev stats */
>> + struct rtnl_link_stats64 primary_stats;
>> +
>> + /* standby netdev stats */
>> + struct rtnl_link_stats64 standby_stats;
>> +
>> + /* aggregated stats */
>> + struct rtnl_link_stats64 failover_stats;
>> +
>> + /* spinlock while updating stats */
>> + spinlock_t stats_lock;
>> +};
>> +
>> +#if IS_ENABLED(CONFIG_NET_FAILOVER)
>> +
>> +int failover_create(struct net_device *standby_dev,
>> + struct failover **pfailover);
>> +void failover_destroy(struct failover *failover);
>> +
>> +int failover_register(struct net_device *standby_dev, struct failover_ops *ops,
>> + struct failover **pfailover);
>> +void failover_unregister(struct failover *failover);
>> +
>> +int failover_slave_unregister(struct net_device *slave_dev);
>> +
>> +#else
>> +
>> +static inline
>> +int failover_create(struct net_device *standby_dev,
>> + struct failover **pfailover);
>> +{
>> + return 0;
>> +}
>> +
>> +static inline
>> +void failover_destroy(struct failover *failover)
>> +{
>> +}
>> +
>> +static inline
>> +int failover_register(struct net_device *standby_dev, struct failover_ops *ops,
>> + struct pfailover **pfailover);
>> +{
>> + return 0;
>> +}
>> +
>> +static inline
>> +void failover_unregister(struct failover *failover)
>> +{
>> +}
>> +
>> +static inline
>> +int failover_slave_unregister(struct net_device *slave_dev)
>> +{
>> + return 0;
>> +}
>> +
>> +#endif
>> +
>> +#endif /* _NET_FAILOVER_H */
>> diff --git a/net/Kconfig b/net/Kconfig
>> index 0428f12c25c2..388b99dfee10 100644
>> --- a/net/Kconfig
>> +++ b/net/Kconfig
>> @@ -423,6 +423,24 @@ config MAY_USE_DEVLINK
>> on MAY_USE_DEVLINK to ensure they do not cause link errors when
>> devlink is a loadable module and the driver using it is built-in.
>>
>> +config NET_FAILOVER
>> + tristate "Failover interface"
>> + help
>> + This provides a generic interface for paravirtual drivers to listen
>> + for netdev register/unregister/link change events from pci ethernet
>> + devices with the same MAC and takeover their datapath. This also
>> + enables live migration of a VM with direct attached VF by failing
>> + over to the paravirtual datapath when the VF is unplugged.
>> +
>> +config MAY_USE_FAILOVER
>> + tristate
>> + default m if NET_FAILOVER=m
>> + default y if NET_FAILOVER=y || NET_FAILOVER=n
>> + help
>> + Drivers using the failover infrastructure should have a dependency
>> + on MAY_USE_FAILOVER to ensure they do not cause link errors when
>> + failover is a loadable module and the driver using it is built-in.
>> +
>> endif # if NET
>>
>> # Used by archs to tell that they support BPF JIT compiler plus which flavour.
>> diff --git a/net/core/Makefile b/net/core/Makefile
>> index 6dbbba8c57ae..cef17518bb7d 100644
>> --- a/net/core/Makefile
>> +++ b/net/core/Makefile
>> @@ -30,3 +30,4 @@ obj-$(CONFIG_DST_CACHE) += dst_cache.o
>> obj-$(CONFIG_HWBM) += hwbm.o
>> obj-$(CONFIG_NET_DEVLINK) += devlink.o
>> obj-$(CONFIG_GRO_CELLS) += gro_cells.o
>> +obj-$(CONFIG_NET_FAILOVER) += failover.o
>> diff --git a/net/core/failover.c b/net/core/failover.c
>> new file mode 100644
>> index 000000000000..7bee762cb737
>> --- /dev/null
>> +++ b/net/core/failover.c
>> @@ -0,0 +1,844 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/* Copyright (c) 2018, Intel Corporation. */
>
> I think you should copy the header from bond_main.c upon which
> some of the code seems to be based.
Yes. some of the code is based on bonding/team and netvsc. i added a reference
to netvsc in the comment, will also include bonding/team driver.
>
>> +
>> +/* A common module to handle registrations and notifications for paravirtual
>> + * drivers to enable accelerated datapath and support VF live migration.
>> + *
>> + * The notifier and event handling code is based on netvsc driver.
>> + */
>> +
>> +#include <linux/netdevice.h>
>> +#include <linux/etherdevice.h>
>> +#include <linux/ethtool.h>
>> +#include <linux/module.h>
>> +#include <linux/slab.h>
>> +#include <linux/netdevice.h>
>> +#include <linux/netpoll.h>
>> +#include <linux/rtnetlink.h>
>> +#include <linux/if_vlan.h>
>> +#include <linux/pci.h>
>> +#include <net/sch_generic.h>
>> +#include <uapi/linux/if_arp.h>
>> +#include <net/failover.h>
>> +
>> +static LIST_HEAD(failover_list);
>> +static DEFINE_SPINLOCK(failover_lock);
>> +
>> +static int failover_slave_pre_register(struct net_device *slave_dev,
>> + struct net_device *failover_dev,
>> + struct failover_ops *failover_ops)
>> +{
>> + struct failover_info *finfo;
>> + bool standby;
>> +
>> + if (failover_ops) {
>> + if (!failover_ops->slave_pre_register)
>> + return -EINVAL;
>> +
>> + return failover_ops->slave_pre_register(slave_dev,
>> + failover_dev);
>> + }
>> +
>> + finfo = netdev_priv(failover_dev);
>> + standby = (slave_dev->dev.parent == failover_dev->dev.parent);
>> + if (standby ? rtnl_dereference(finfo->standby_dev) :
>> + rtnl_dereference(finfo->primary_dev)) {
>> + netdev_err(failover_dev, "%s attempting to register as slave dev when %s already present\n",
>> + slave_dev->name, standby ? "standby" : "primary");
>> + return -EEXIST;
>> + }
>> +
>> + /* Avoid non pci devices as primary netdev */
> Why? Pls change this comment so it explains the motivation
> rather than just repeat what the code does.
OK.
>
>> + if (!standby && (!slave_dev->dev.parent ||
>> + !dev_is_pci(slave_dev->dev.parent)))
>> + return -EINVAL;
>> +
>> + return 0;
>> +}
>> +
>> +static int failover_slave_join(struct net_device *slave_dev,
>> + struct net_device *failover_dev,
>> + struct failover_ops *failover_ops)
>> +{
>> + struct failover_info *finfo;
>> + int err, orig_mtu;
>> + bool standby;
>> +
>> + if (failover_ops) {
>> + if (!failover_ops->slave_join)
>> + return -EINVAL;
>> +
>> + return failover_ops->slave_join(slave_dev, failover_dev);
>> + }
>> +
>> + if (netif_running(failover_dev)) {
>> + err = dev_open(slave_dev);
>> + if (err && (err != -EBUSY)) {
>> + netdev_err(failover_dev, "Opening slave %s failed err:%d\n",
>> + slave_dev->name, err);
>> + goto err_dev_open;
>> + }
>> + }
>> +
>> + /* Align MTU of slave with failover dev */
>> + orig_mtu = slave_dev->mtu;
> I suspect this was copied from bond. this variable is never
> used and I'm even surprised gcc did not warn about this.
Thanks for catching, I broke this when i moved the dev_open() and dev_set_mtu()
calls from register to join. I need to reset slave_dev mtu to orig_mtu on failure.
>
>
>> + err = dev_set_mtu(slave_dev, failover_dev->mtu);
> How do we know slave supports this MTU? same applies to
> failover_change_mtu.
The err check below should catch it and we will reset the mtu back and
fail the join/register.
>
>
>
>
>> + if (err) {
>> + netdev_err(failover_dev, "unable to change mtu of %s to %u register failed\n",
>> + slave_dev->name, failover_dev->mtu);
>> + goto err_set_mtu;
>> + }
>> +
>> + finfo = netdev_priv(failover_dev);
>> + standby = (slave_dev->dev.parent == failover_dev->dev.parent);
>> +
>> + dev_hold(slave_dev);
>> +
>> + if (standby) {
>> + rcu_assign_pointer(finfo->standby_dev, slave_dev);
>> + dev_get_stats(finfo->standby_dev, &finfo->standby_stats);
>> + } else {
>> + rcu_assign_pointer(finfo->primary_dev, slave_dev);
>> + dev_get_stats(finfo->primary_dev, &finfo->primary_stats);
>> + failover_dev->min_mtu = slave_dev->min_mtu;
>> + failover_dev->max_mtu = slave_dev->max_mtu;
>> + }
>> +
>> + netdev_info(failover_dev, "failover slave:%s joined\n",
>> + slave_dev->name);
>> +
>> + return 0;
>> +
>> +err_set_mtu:
>> + dev_close(slave_dev);
>> +err_dev_open:
>> + return err;
>> +}
>> +
>> +/* Called when slave dev is injecting data into network stack.
>> + * Change the associated network device from lower dev to virtio.
>> + * note: already called with rcu_read_lock
>> + */
>> +static rx_handler_result_t failover_handle_frame(struct sk_buff **pskb)
>> +{
>> + struct sk_buff *skb = *pskb;
>> + struct net_device *ndev = rcu_dereference(skb->dev->rx_handler_data);
>> +
>> + skb->dev = ndev;
>> +
>> + return RX_HANDLER_ANOTHER;
>> +}
>> +
>> +static struct net_device *failover_get_bymac(u8 *mac, struct failover_ops **ops)
>> +{
>> + struct net_device *failover_dev;
>> + struct failover *failover;
>> +
>> + spin_lock(&failover_lock);
>> + list_for_each_entry(failover, &failover_list, list) {
>> + failover_dev = rtnl_dereference(failover->failover_dev);
>> + if (ether_addr_equal(failover_dev->perm_addr, mac)) {
>> + *ops = rtnl_dereference(failover->ops);
>> + spin_unlock(&failover_lock);
>> + return failover_dev;
>> + }
>> + }
>> + spin_unlock(&failover_lock);
>> + return NULL;
>> +}
>> +
>> +static int failover_slave_register(struct net_device *slave_dev)
>> +{
>> + struct failover_ops *failover_ops;
>> + struct net_device *failover_dev;
>> + int ret;
>> +
>> + ASSERT_RTNL();
>> +
>> + failover_dev = failover_get_bymac(slave_dev->perm_addr, &failover_ops);
>> + if (!failover_dev)
>> + goto done;
>> +
>> + ret = failover_slave_pre_register(slave_dev, failover_dev,
>> + failover_ops);
>> + if (ret)
>> + goto done;
>> +
>> + ret = netdev_rx_handler_register(slave_dev, failover_ops ?
>> + failover_ops->handle_frame :
>> + failover_handle_frame, failover_dev);
>> + if (ret) {
>> + netdev_err(slave_dev, "can not register failover rx handler (err = %d)\n",
>> + ret);
>> + goto done;
>> + }
>> +
>> + ret = netdev_upper_dev_link(slave_dev, failover_dev, NULL);
>> + if (ret) {
>> + netdev_err(slave_dev, "can not set failover device %s (err = %d)\n",
>> + failover_dev->name, ret);
>> + goto upper_link_failed;
>> + }
>> +
>> + slave_dev->priv_flags |= IFF_FAILOVER_SLAVE;
>> +
>> + ret = failover_slave_join(slave_dev, failover_dev, failover_ops);
>> + if (ret)
>> + goto err_join;
>> +
>> + call_netdevice_notifiers(NETDEV_JOIN, slave_dev);
>> +
>> + netdev_info(failover_dev, "failover slave:%s registered\n",
>> + slave_dev->name);
>> +
>> + goto done;
>> +
>> +err_join:
>> + netdev_upper_dev_unlink(slave_dev, failover_dev);
>> + slave_dev->priv_flags &= ~IFF_FAILOVER_SLAVE;
>> +upper_link_failed:
>> + netdev_rx_handler_unregister(slave_dev);
>> +done:
>> + return NOTIFY_DONE;
>> +}
>> +
>> +static int failover_slave_pre_unregister(struct net_device *slave_dev,
>> + struct net_device *failover_dev,
>> + struct failover_ops *failover_ops)
>> +{
>> + struct net_device *standby_dev, *primary_dev;
>> + struct failover_info *finfo;
>> +
>> + if (failover_ops) {
>> + if (!failover_ops->slave_pre_unregister)
>> + return -EINVAL;
>> +
>> + return failover_ops->slave_pre_unregister(slave_dev,
>> + failover_dev);
>> + }
>> +
>> + finfo = netdev_priv(failover_dev);
>> + primary_dev = rtnl_dereference(finfo->primary_dev);
>> + standby_dev = rtnl_dereference(finfo->standby_dev);
>> +
>> + if (slave_dev != primary_dev && slave_dev != standby_dev)
>> + return -EINVAL;
>> +
>> + return 0;
>> +}
>> +
>> +static int failover_slave_release(struct net_device *slave_dev,
>> + struct net_device *failover_dev,
>> + struct failover_ops *failover_ops)
>> +{
>> + struct net_device *standby_dev, *primary_dev;
>> + struct failover_info *finfo;
>> +
>> + if (failover_ops) {
>> + if (!failover_ops->slave_release)
>> + return -EINVAL;
>> +
>> + return failover_ops->slave_release(slave_dev, failover_dev);
>> + }
>> +
>> + finfo = netdev_priv(failover_dev);
>> + primary_dev = rtnl_dereference(finfo->primary_dev);
>> + standby_dev = rtnl_dereference(finfo->standby_dev);
>> +
>> + if (slave_dev == standby_dev) {
>> + RCU_INIT_POINTER(finfo->standby_dev, NULL);
>> + } else {
>> + RCU_INIT_POINTER(finfo->primary_dev, NULL);
>> + if (standby_dev) {
>> + failover_dev->min_mtu = standby_dev->min_mtu;
>> + failover_dev->max_mtu = standby_dev->max_mtu;
>> + }
>> + }
>> +
>> + dev_put(slave_dev);
>> +
>> + netdev_info(failover_dev, "failover slave:%s released\n",
>> + slave_dev->name);
>> +
>> + return 0;
>> +}
>> +
>> +int failover_slave_unregister(struct net_device *slave_dev)
>> +{
>> + struct failover_ops *failover_ops;
>> + struct net_device *failover_dev;
>> + int ret;
>> +
>> + if (!netif_is_failover_slave(slave_dev))
>> + goto done;
>> +
>> + ASSERT_RTNL();
>> +
>> + failover_dev = failover_get_bymac(slave_dev->perm_addr, &failover_ops);
>> + if (!failover_dev)
>> + goto done;
>> +
>> + ret = failover_slave_pre_unregister(slave_dev, failover_dev,
>> + failover_ops);
>> + if (ret)
>> + goto done;
>> +
>> + netdev_rx_handler_unregister(slave_dev);
>> + netdev_upper_dev_unlink(slave_dev, failover_dev);
>> + slave_dev->priv_flags &= ~IFF_FAILOVER_SLAVE;
>> +
>> + failover_slave_release(slave_dev, failover_dev, failover_ops);
>
> Don't you need to get stats from it? This device is going away ...
Yes. we need to update the failover_stats before the slave goes away.
>
>> +
>> + netdev_info(failover_dev, "failover slave:%s unregistered\n",
>> + slave_dev->name);
>> +
>> +done:
>> + return NOTIFY_DONE;
>> +}
>> +EXPORT_SYMBOL_GPL(failover_slave_unregister);
>> +
>> +static bool failover_xmit_ready(struct net_device *dev)
>> +{
>> + return netif_running(dev) && netif_carrier_ok(dev);
>> +}
>> +
>> +static int failover_slave_link_change(struct net_device *slave_dev)
>> +{
>> + struct net_device *failover_dev, *primary_dev, *standby_dev;
>> + struct failover_ops *failover_ops;
>> + struct failover_info *finfo;
>> +
>> + if (!netif_is_failover_slave(slave_dev))
>> + goto done;
>> +
>> + ASSERT_RTNL();
>> +
>> + failover_dev = failover_get_bymac(slave_dev->perm_addr, &failover_ops);
>> + if (!failover_dev)
>> + goto done;
>> +
>> + if (failover_ops) {
>> + if (!failover_ops->slave_link_change)
>> + goto done;
>> +
>> + return failover_ops->slave_link_change(slave_dev, failover_dev);
>> + }
>> +
>> + if (!netif_running(failover_dev))
>> + return 0;
>> +
>> + finfo = netdev_priv(failover_dev);
>> +
>> + primary_dev = rtnl_dereference(finfo->primary_dev);
>> + standby_dev = rtnl_dereference(finfo->standby_dev);
>> +
>> + if (slave_dev != primary_dev && slave_dev != standby_dev)
>> + goto done;
>> +
>> + if ((primary_dev && failover_xmit_ready(primary_dev)) ||
>> + (standby_dev && failover_xmit_ready(standby_dev))) {
>> + netif_carrier_on(failover_dev);
>> + netif_tx_wake_all_queues(failover_dev);
>> + } else {
>> + netif_carrier_off(failover_dev);
>> + netif_tx_stop_all_queues(failover_dev);
> And I think it's a good idea to get stats from device here too.
Not sure why we need to get stats from lower devs here?
>
>
>> + }
>> +
>> +done:
>> + return NOTIFY_DONE;
>> +}
>> +
>> +static bool failover_validate_event_dev(struct net_device *dev)
>> +{
>> + /* Skip parent events */
>> + if (netif_is_failover(dev))
>> + return false;
>> +
>> + /* Avoid non-Ethernet type devices */
> ... for now. It would be possible easy to make this generic -
> just copy things like type and addr_len from slave.
ok. failover_create can copy these values from standby_dev and
we can validate that they match when primary_dev registers.
>
>> + if (dev->type != ARPHRD_ETHER)
>> + return false;
>> +
>> + return true;
>> +}
>> +
>> +static int
>> +failover_event(struct notifier_block *this, unsigned long event, void *ptr)
>> +{
>> + struct net_device *event_dev = netdev_notifier_info_to_dev(ptr);
>> +
>> + if (!failover_validate_event_dev(event_dev))
>> + return NOTIFY_DONE;
>> +
>> + switch (event) {
>> + case NETDEV_REGISTER:
>> + return failover_slave_register(event_dev);
>> + case NETDEV_UNREGISTER:
>> + return failover_slave_unregister(event_dev);
>> + case NETDEV_UP:
>> + case NETDEV_DOWN:
>> + case NETDEV_CHANGE:
>> + return failover_slave_link_change(event_dev);
>> + default:
>> + return NOTIFY_DONE;
>> + }
>> +}
>> +
>> +static struct notifier_block failover_notifier = {
>> + .notifier_call = failover_event,
>> +};
>> +
>> +static int failover_open(struct net_device *dev)
>> +{
>> + struct failover_info *finfo = netdev_priv(dev);
>> + struct net_device *primary_dev, *standby_dev;
>> + int err;
>> +
>> + netif_carrier_off(dev);
>> + netif_tx_wake_all_queues(dev);
>> +
>> + primary_dev = rtnl_dereference(finfo->primary_dev);
>> + if (primary_dev) {
>> + err = dev_open(primary_dev);
>> + if (err)
>> + goto err_primary_open;
>> + }
>> +
>> + standby_dev = rtnl_dereference(finfo->standby_dev);
>> + if (standby_dev) {
>> + err = dev_open(standby_dev);
>> + if (err)
>> + goto err_standby_open;
>> + }
>> +
>> + return 0;
>> +
>> +err_standby_open:
>> + dev_close(primary_dev);
>> +err_primary_open:
>> + netif_tx_disable(dev);
>> + return err;
>> +}
>> +
>> +static int failover_close(struct net_device *dev)
>> +{
>> + struct failover_info *finfo = netdev_priv(dev);
>> + struct net_device *slave_dev;
>> +
>> + netif_tx_disable(dev);
>> +
>> + slave_dev = rtnl_dereference(finfo->primary_dev);
>> + if (slave_dev)
>> + dev_close(slave_dev);
>> +
>> + slave_dev = rtnl_dereference(finfo->standby_dev);
>> + if (slave_dev)
>> + dev_close(slave_dev);
>> +
>> + return 0;
>> +}
>> +
>> +static netdev_tx_t failover_drop_xmit(struct sk_buff *skb,
>> + struct net_device *dev)
>> +{
>> + atomic_long_inc(&dev->tx_dropped);
>> + dev_kfree_skb_any(skb);
>> + return NETDEV_TX_OK;
>> +}
>> +
>> +static netdev_tx_t failover_start_xmit(struct sk_buff *skb,
>> + struct net_device *dev)
>> +{
>> + struct failover_info *finfo = netdev_priv(dev);
>> + struct net_device *xmit_dev;
>> +
>> + /* Try xmit via primary netdev followed by standby netdev */
>> + xmit_dev = rcu_dereference_bh(finfo->primary_dev);
>> + if (!xmit_dev || !failover_xmit_ready(xmit_dev)) {
>> + xmit_dev = rcu_dereference_bh(finfo->standby_dev);
>> + if (!xmit_dev || !failover_xmit_ready(xmit_dev))
>> + return failover_drop_xmit(skb, dev);
>> + }
>> +
>> + skb->dev = xmit_dev;
>> + skb->queue_mapping = qdisc_skb_cb(skb)->slave_dev_queue_mapping;
>> +
>> + return dev_queue_xmit(skb);
>> +}
> Is this going through qdisc twice? Won't this hurt performance
> measureably?
The failover dev has no queue (IFF_NO_QUEUE) , so doesn't go through qdisc twice.
>
>> +
>> +static u16 failover_select_queue(struct net_device *dev, struct sk_buff *skb,
>> + void *accel_priv,
>> + select_queue_fallback_t fallback)
>> +{
>> + struct failover_info *finfo = netdev_priv(dev);
>> + struct net_device *primary_dev;
>> + u16 txq;
>> +
>> + rcu_read_lock();
>> + primary_dev = rcu_dereference(finfo->primary_dev);
>> + if (primary_dev) {
>> + const struct net_device_ops *ops = primary_dev->netdev_ops;
>> +
>> + if (ops->ndo_select_queue)
>> + txq = ops->ndo_select_queue(primary_dev, skb,
>> + accel_priv, fallback);
>> + else
>> + txq = fallback(primary_dev, skb);
>> +
>> + qdisc_skb_cb(skb)->slave_dev_queue_mapping = skb->queue_mapping;
>> +
>> + return txq;
>> + }
>> +
>> + txq = skb_rx_queue_recorded(skb) ? skb_get_rx_queue(skb) : 0;
>> +
>> + /* Save the original txq to restore before passing to the driver */
>> + qdisc_skb_cb(skb)->slave_dev_queue_mapping = skb->queue_mapping;
>> +
>> + if (unlikely(txq >= dev->real_num_tx_queues)) {
>> + do {
>> + txq -= dev->real_num_tx_queues;
>> + } while (txq >= dev->real_num_tx_queues);
>> + }
>> +
>> + return txq;
>> +}
>> +
>> +/* fold stats, assuming all rtnl_link_stats64 fields are u64, but
>> + * that some drivers can provide 32finfot values only.
>> + */
>> +static void failover_fold_stats(struct rtnl_link_stats64 *_res,
>> + const struct rtnl_link_stats64 *_new,
>> + const struct rtnl_link_stats64 *_old)
>> +{
>> + const u64 *new = (const u64 *)_new;
>> + const u64 *old = (const u64 *)_old;
>> + u64 *res = (u64 *)_res;
>> + int i;
>> +
>> + for (i = 0; i < sizeof(*_res) / sizeof(u64); i++) {
>> + u64 nv = new[i];
>> + u64 ov = old[i];
>> + s64 delta = nv - ov;
>> +
>> + /* detects if this particular field is 32bit only */
>> + if (((nv | ov) >> 32) == 0)
>> + delta = (s64)(s32)((u32)nv - (u32)ov);
>> +
>> + /* filter anomalies, some drivers reset their stats
>> + * at down/up events.
>> + */
>> + if (delta > 0)
>> + res[i] += delta;
>> + }
>> +}
>> +
>> +static void failover_get_stats(struct net_device *dev,
>> + struct rtnl_link_stats64 *stats)
>> +{
>> + struct failover_info *finfo = netdev_priv(dev);
>> + const struct rtnl_link_stats64 *new;
>> + struct rtnl_link_stats64 temp;
>> + struct net_device *slave_dev;
>> +
>> + spin_lock(&finfo->stats_lock);
>> + memcpy(stats, &finfo->failover_stats, sizeof(*stats));
>> +
>> + rcu_read_lock();
>> +
>> + slave_dev = rcu_dereference(finfo->primary_dev);
>> + if (slave_dev) {
>> + new = dev_get_stats(slave_dev, &temp);
>> + failover_fold_stats(stats, new, &finfo->primary_stats);
>> + memcpy(&finfo->primary_stats, new, sizeof(*new));
>> + }
>> +
>> + slave_dev = rcu_dereference(finfo->standby_dev);
>> + if (slave_dev) {
>> + new = dev_get_stats(slave_dev, &temp);
>> + failover_fold_stats(stats, new, &finfo->standby_stats);
>> + memcpy(&finfo->standby_stats, new, sizeof(*new));
>> + }
>> +
>> + rcu_read_unlock();
>> +
>> + memcpy(&finfo->failover_stats, stats, sizeof(*stats));
>> + spin_unlock(&finfo->stats_lock);
>> +}
>> +
>> +static int failover_change_mtu(struct net_device *dev, int new_mtu)
>> +{
>> + struct failover_info *finfo = netdev_priv(dev);
>> + struct net_device *primary_dev, *standby_dev;
>> + int ret = 0;
>> +
>> + primary_dev = rcu_dereference(finfo->primary_dev);
>> + if (primary_dev) {
>> + ret = dev_set_mtu(primary_dev, new_mtu);
>> + if (ret)
>> + return ret;
>> + }
>> +
>> + standby_dev = rcu_dereference(finfo->standby_dev);
>> + if (standby_dev) {
>> + ret = dev_set_mtu(standby_dev, new_mtu);
>> + if (ret) {
>> + dev_set_mtu(primary_dev, dev->mtu);
>> + return ret;
>> + }
>> + }
>> +
>> + dev->mtu = new_mtu;
>> + return 0;
>> +}
>> +
>> +static void failover_set_rx_mode(struct net_device *dev)
>> +{
>> + struct failover_info *finfo = netdev_priv(dev);
>> + struct net_device *slave_dev;
>> +
>> + rcu_read_lock();
>> +
>> + slave_dev = rcu_dereference(finfo->primary_dev);
>> + if (slave_dev) {
>> + dev_uc_sync_multiple(slave_dev, dev);
>> + dev_mc_sync_multiple(slave_dev, dev);
>> + }
>> +
>> + slave_dev = rcu_dereference(finfo->standby_dev);
>> + if (slave_dev) {
>> + dev_uc_sync_multiple(slave_dev, dev);
>> + dev_mc_sync_multiple(slave_dev, dev);
>> + }
>> +
>> + rcu_read_unlock();
>> +}
>> +
>> +static const struct net_device_ops failover_dev_ops = {
>> + .ndo_open = failover_open,
>> + .ndo_stop = failover_close,
>> + .ndo_start_xmit = failover_start_xmit,
>> + .ndo_select_queue = failover_select_queue,
>> + .ndo_get_stats64 = failover_get_stats,
>> + .ndo_change_mtu = failover_change_mtu,
>> + .ndo_set_rx_mode = failover_set_rx_mode,
>> + .ndo_validate_addr = eth_validate_addr,
>> + .ndo_features_check = passthru_features_check,
> xdp support?
I think it should be possible to add it be calling the lower dev ndo_xdp routines
with proper checks. can we add this later?
>
>> +};
>> +
>> +#define FAILOVER_NAME "failover"
>> +#define FAILOVER_VERSION "0.1"
>> +
>> +static void failover_ethtool_get_drvinfo(struct net_device *dev,
>> + struct ethtool_drvinfo *drvinfo)
>> +{
>> + strlcpy(drvinfo->driver, FAILOVER_NAME, sizeof(drvinfo->driver));
>> + strlcpy(drvinfo->version, FAILOVER_VERSION, sizeof(drvinfo->version));
>> +}
>> +
>> +int failover_ethtool_get_link_ksettings(struct net_device *dev,
>> + struct ethtool_link_ksettings *cmd)
>> +{
>> + struct failover_info *finfo = netdev_priv(dev);
>> + struct net_device *slave_dev;
>> +
>> + slave_dev = rtnl_dereference(finfo->primary_dev);
>> + if (!slave_dev || !failover_xmit_ready(slave_dev)) {
>> + slave_dev = rtnl_dereference(finfo->standby_dev);
>> + if (!slave_dev || !failover_xmit_ready(slave_dev)) {
>> + cmd->base.duplex = DUPLEX_UNKNOWN;
>> + cmd->base.port = PORT_OTHER;
>> + cmd->base.speed = SPEED_UNKNOWN;
>> +
>> + return 0;
>> + }
>> + }
>> +
>> + return __ethtool_get_link_ksettings(slave_dev, cmd);
>> +}
>> +EXPORT_SYMBOL_GPL(failover_ethtool_get_link_ksettings);
>> +
>> +static const struct ethtool_ops failover_ethtool_ops = {
>> + .get_drvinfo = failover_ethtool_get_drvinfo,
>> + .get_link = ethtool_op_get_link,
>> + .get_link_ksettings = failover_ethtool_get_link_ksettings,
>> +};
>> +
>> +static void failover_register_existing_slave(struct net_device *failover_dev)
>> +{
>> + struct net *net = dev_net(failover_dev);
>> + struct net_device *dev;
>> +
>> + rtnl_lock();
>> + for_each_netdev(net, dev) {
>> + if (dev == failover_dev)
>> + continue;
>> + if (!failover_validate_event_dev(dev))
>> + continue;
>> + if (ether_addr_equal(failover_dev->perm_addr, dev->perm_addr))
>> + failover_slave_register(dev);
>> + }
>> + rtnl_unlock();
>> +}
>> +
>> +int failover_register(struct net_device *dev, struct failover_ops *ops,
>> + struct failover **pfailover)
>> +{
>> + struct failover *failover;
>> +
>> + failover = kzalloc(sizeof(*failover), GFP_KERNEL);
>> + if (!failover)
>> + return -ENOMEM;
>> +
>> + rcu_assign_pointer(failover->ops, ops);
>> + dev_hold(dev);
>> + dev->priv_flags |= IFF_FAILOVER;
>> + rcu_assign_pointer(failover->failover_dev, dev);
>> +
>> + spin_lock(&failover_lock);
>> + list_add_tail(&failover->list, &failover_list);
>> + spin_unlock(&failover_lock);
>> +
>> + failover_register_existing_slave(dev);
>> +
>> + *pfailover = failover;
>> + return 0;
>> +}
>> +EXPORT_SYMBOL_GPL(failover_register);
>> +
>> +void failover_unregister(struct failover *failover)
>> +{
>> + struct net_device *failover_dev;
>> +
>> + failover_dev = rcu_dereference(failover->failover_dev);
>> +
>> + failover_dev->priv_flags &= ~IFF_FAILOVER;
>> + dev_put(failover_dev);
>> +
>> + spin_lock(&failover_lock);
>> + list_del(&failover->list);
>> + spin_unlock(&failover_lock);
>> +
>> + kfree(failover);
>> +}
>> +EXPORT_SYMBOL_GPL(failover_unregister);
>> +
>> +int failover_create(struct net_device *standby_dev, struct failover **pfailover)
>> +{
>> + struct device *dev = standby_dev->dev.parent;
>> + struct net_device *failover_dev;
>> + int err;
>> +
>> + /* Alloc at least 2 queues, for now we are going with 16 assuming
>> + * that most devices being bonded won't have too many queues.
>> + */
>> + failover_dev = alloc_etherdev_mq(sizeof(struct failover_info), 16);
>> + if (!failover_dev) {
>> + dev_err(dev, "Unable to allocate failover_netdev!\n");
>> + return -ENOMEM;
>> + }
>> +
>> + dev_net_set(failover_dev, dev_net(standby_dev));
>> + SET_NETDEV_DEV(failover_dev, dev);
>> +
>> + failover_dev->netdev_ops = &failover_dev_ops;
>> + failover_dev->ethtool_ops = &failover_ethtool_ops;
>> +
>> + /* Initialize the device options */
>> + failover_dev->priv_flags |= IFF_UNICAST_FLT | IFF_NO_QUEUE;
>> + failover_dev->priv_flags &= ~(IFF_XMIT_DST_RELEASE |
>> + IFF_TX_SKB_SHARING);
>> +
>> + /* don't acquire failover netdev's netif_tx_lock when transmitting */
>> + failover_dev->features |= NETIF_F_LLTX;
>> +
>> + /* Don't allow failover devices to change network namespaces. */
>> + failover_dev->features |= NETIF_F_NETNS_LOCAL;
>> +
>> + failover_dev->hw_features = NETIF_F_HW_CSUM | NETIF_F_SG |
>> + NETIF_F_FRAGLIST | NETIF_F_ALL_TSO |
>> + NETIF_F_HIGHDMA | NETIF_F_LRO;
> OK but then you must make sure your primary and standby both
> support these features.
I guess i need to add something like bond_compute_features() to handle this.
>
>> +
>> + failover_dev->hw_features |= NETIF_F_GSO_ENCAP_ALL;
>> + failover_dev->features |= failover_dev->hw_features;
>> +
>> + memcpy(failover_dev->dev_addr, standby_dev->dev_addr,
>> + failover_dev->addr_len);
>> +
>> + failover_dev->min_mtu = standby_dev->min_mtu;
>> + failover_dev->max_mtu = standby_dev->max_mtu;
> OK MTU is copied, fine. But is this always enough?
>
> How about e.g. hard_header_len? min_header_len? needed_headroom?
> needed_tailroom? I'd worry that even if you cover existing ones more
> might be added with time. A function copying config between devices
> probably belongs in some central place IMHO.
ok. will add a function that handles these fields too.
>
>
>> +
>> + err = register_netdev(failover_dev);
>> + if (err < 0) {
>> + dev_err(dev, "Unable to register failover_dev!\n");
>> + goto err_register_netdev;
>> + }
>> +
>> + netif_carrier_off(failover_dev);
>> +
>> + err = failover_register(failover_dev, NULL, pfailover);
>> + if (err < 0)
>> + goto err_failover;
>> +
>> + return 0;
>> +
>> +err_failover:
>> + unregister_netdev(failover_dev);
>> +err_register_netdev:
>> + free_netdev(failover_dev);
>> +
>> + return err;
>> +}
>> +EXPORT_SYMBOL_GPL(failover_create);
>> +
>> +void failover_destroy(struct failover *failover)
>> +{
>> + struct net_device *failover_dev;
>> + struct net_device *slave_dev;
>> + struct failover_info *finfo;
>> +
>> + if (!failover)
>> + return;
>> +
>> + failover_dev = rcu_dereference(failover->failover_dev);
>> + finfo = netdev_priv(failover_dev);
>> +
>> + netif_device_detach(failover_dev);
>> +
>> + rtnl_lock();
>> +
>> + slave_dev = rtnl_dereference(finfo->primary_dev);
>> + if (slave_dev)
>> + failover_slave_unregister(slave_dev);
>> +
>> + slave_dev = rtnl_dereference(finfo->standby_dev);
>> + if (slave_dev)
>> + failover_slave_unregister(slave_dev);
>> +
>> + failover_unregister(failover);
>> +
>> + unregister_netdevice(failover_dev);
>> +
>> + rtnl_unlock();
>> +
>> + free_netdev(failover_dev);
>> +}
>> +EXPORT_SYMBOL_GPL(failover_destroy);
>> +
>> +static __init int
>> +failover_init(void)
>> +{
>> + register_netdevice_notifier(&failover_notifier);
>> +
>> + return 0;
>> +}
>> +module_init(failover_init);
>> +
>> +static __exit
>> +void failover_exit(void)
>> +{
>> + unregister_netdevice_notifier(&failover_notifier);
>> +}
>> +module_exit(failover_exit);
>> +
>> +MODULE_DESCRIPTION("Failover infrastructure/interface for Paravirtual drivers");
>> +MODULE_LICENSE("GPL v2");
>> --
>> 2.14.3
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 net-next 2/4] net: Introduce generic failover module
2018-04-20 2:44 ` [virtio-dev] " Michael S. Tsirkin
(?)
(?)
@ 2018-04-20 15:21 ` Samudrala, Sridhar
-1 siblings, 0 replies; 114+ messages in thread
From: Samudrala, Sridhar @ 2018-04-20 15:21 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: alexander.h.duyck, virtio-dev, jiri, kubakici, netdev,
virtualization, loseweigh, davem
On 4/19/2018 7:44 PM, Michael S. Tsirkin wrote:
> On Thu, Apr 19, 2018 at 06:42:02PM -0700, Sridhar Samudrala wrote:
>> This provides a generic interface for paravirtual drivers to listen
>> for netdev register/unregister/link change events from pci ethernet
>> devices with the same MAC and takeover their datapath. The notifier and
>> event handling code is based on the existing netvsc implementation.
>>
>> It exposes 2 sets of interfaces to the paravirtual drivers.
>> 1. existing netvsc driver that uses 2 netdev model. In this model, no
>> master netdev is created. The paravirtual driver registers each instance
>> of netvsc as a 'failover' instance along with a set of ops to manage the
>> slave events.
>> failover_register()
>> failover_unregister()
>> 2. new virtio_net based solution that uses 3 netdev model. In this model,
>> the failover module provides interfaces to create/destroy additional master
>> netdev and all the slave events are managed internally.
>> failover_create()
>> failover_destroy()
>> These functions call failover_register()/failover_unregister() with the
>> master netdev created by the failover module.
>>
>> Signed-off-by: Sridhar Samudrala <sridhar.samudrala@intel.com>
> I like this patch. Yes something to improve (see below)
>
>> ---
>> include/linux/netdevice.h | 16 +
>> include/net/failover.h | 96 ++++++
>> net/Kconfig | 18 +
>> net/core/Makefile | 1 +
>> net/core/failover.c | 844 ++++++++++++++++++++++++++++++++++++++++++++++
>> 5 files changed, 975 insertions(+)
>> create mode 100644 include/net/failover.h
>> create mode 100644 net/core/failover.c
>>
>> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
>> index cf44503ea81a..ed535b6724e1 100644
>> --- a/include/linux/netdevice.h
>> +++ b/include/linux/netdevice.h
>> @@ -1401,6 +1401,8 @@ struct net_device_ops {
>> * entity (i.e. the master device for bridged veth)
>> * @IFF_MACSEC: device is a MACsec device
>> * @IFF_NO_RX_HANDLER: device doesn't support the rx_handler hook
>> + * @IFF_FAILOVER: device is a failover master device
>> + * @IFF_FAILOVER_SLAVE: device is lower dev of a failover master device
>> */
>> enum netdev_priv_flags {
>> IFF_802_1Q_VLAN = 1<<0,
>> @@ -1430,6 +1432,8 @@ enum netdev_priv_flags {
>> IFF_PHONY_HEADROOM = 1<<24,
>> IFF_MACSEC = 1<<25,
>> IFF_NO_RX_HANDLER = 1<<26,
>> + IFF_FAILOVER = 1<<27,
>> + IFF_FAILOVER_SLAVE = 1<<28,
>> };
>>
>> #define IFF_802_1Q_VLAN IFF_802_1Q_VLAN
>> @@ -1458,6 +1462,8 @@ enum netdev_priv_flags {
>> #define IFF_RXFH_CONFIGURED IFF_RXFH_CONFIGURED
>> #define IFF_MACSEC IFF_MACSEC
>> #define IFF_NO_RX_HANDLER IFF_NO_RX_HANDLER
>> +#define IFF_FAILOVER IFF_FAILOVER
>> +#define IFF_FAILOVER_SLAVE IFF_FAILOVER_SLAVE
>>
>> /**
>> * struct net_device - The DEVICE structure.
>> @@ -4308,6 +4314,16 @@ static inline bool netif_is_rxfh_configured(const struct net_device *dev)
>> return dev->priv_flags & IFF_RXFH_CONFIGURED;
>> }
>>
>> +static inline bool netif_is_failover(const struct net_device *dev)
>> +{
>> + return dev->priv_flags & IFF_FAILOVER;
>> +}
>> +
>> +static inline bool netif_is_failover_slave(const struct net_device *dev)
>> +{
>> + return dev->priv_flags & IFF_FAILOVER_SLAVE;
>> +}
>> +
>> /* This device needs to keep skb dst for qdisc enqueue or ndo_start_xmit() */
>> static inline void netif_keep_dst(struct net_device *dev)
>> {
>> diff --git a/include/net/failover.h b/include/net/failover.h
>> new file mode 100644
>> index 000000000000..0b8601043d90
>> --- /dev/null
>> +++ b/include/net/failover.h
>> @@ -0,0 +1,96 @@
>> +/* SPDX-License-Identifier: GPL-2.0 */
>> +/* Copyright (c) 2018, Intel Corporation. */
>> +
>> +#ifndef _NET_FAILOVER_H
>> +#define _NET_FAILOVER_H
>> +
>> +#include <linux/netdevice.h>
>> +
>> +struct failover_ops {
>> + int (*slave_pre_register)(struct net_device *slave_dev,
>> + struct net_device *failover_dev);
>> + int (*slave_join)(struct net_device *slave_dev,
>> + struct net_device *failover_dev);
>> + int (*slave_pre_unregister)(struct net_device *slave_dev,
>> + struct net_device *failover_dev);
>> + int (*slave_release)(struct net_device *slave_dev,
>> + struct net_device *failover_dev);
>> + int (*slave_link_change)(struct net_device *slave_dev,
>> + struct net_device *failover_dev);
>> + rx_handler_result_t (*handle_frame)(struct sk_buff **pskb);
>> +};
>> +
>> +struct failover {
>> + struct list_head list;
>> + struct net_device __rcu *failover_dev;
>> + struct failover_ops __rcu *ops;
>> +};
>> +
>> +/* failover state */
>> +struct failover_info {
>> + /* primary netdev with same MAC */
>> + struct net_device __rcu *primary_dev;
>> +
>> + /* standby netdev */
>> + struct net_device __rcu *standby_dev;
>> +
>> + /* primary netdev stats */
>> + struct rtnl_link_stats64 primary_stats;
>> +
>> + /* standby netdev stats */
>> + struct rtnl_link_stats64 standby_stats;
>> +
>> + /* aggregated stats */
>> + struct rtnl_link_stats64 failover_stats;
>> +
>> + /* spinlock while updating stats */
>> + spinlock_t stats_lock;
>> +};
>> +
>> +#if IS_ENABLED(CONFIG_NET_FAILOVER)
>> +
>> +int failover_create(struct net_device *standby_dev,
>> + struct failover **pfailover);
>> +void failover_destroy(struct failover *failover);
>> +
>> +int failover_register(struct net_device *standby_dev, struct failover_ops *ops,
>> + struct failover **pfailover);
>> +void failover_unregister(struct failover *failover);
>> +
>> +int failover_slave_unregister(struct net_device *slave_dev);
>> +
>> +#else
>> +
>> +static inline
>> +int failover_create(struct net_device *standby_dev,
>> + struct failover **pfailover);
>> +{
>> + return 0;
>> +}
>> +
>> +static inline
>> +void failover_destroy(struct failover *failover)
>> +{
>> +}
>> +
>> +static inline
>> +int failover_register(struct net_device *standby_dev, struct failover_ops *ops,
>> + struct pfailover **pfailover);
>> +{
>> + return 0;
>> +}
>> +
>> +static inline
>> +void failover_unregister(struct failover *failover)
>> +{
>> +}
>> +
>> +static inline
>> +int failover_slave_unregister(struct net_device *slave_dev)
>> +{
>> + return 0;
>> +}
>> +
>> +#endif
>> +
>> +#endif /* _NET_FAILOVER_H */
>> diff --git a/net/Kconfig b/net/Kconfig
>> index 0428f12c25c2..388b99dfee10 100644
>> --- a/net/Kconfig
>> +++ b/net/Kconfig
>> @@ -423,6 +423,24 @@ config MAY_USE_DEVLINK
>> on MAY_USE_DEVLINK to ensure they do not cause link errors when
>> devlink is a loadable module and the driver using it is built-in.
>>
>> +config NET_FAILOVER
>> + tristate "Failover interface"
>> + help
>> + This provides a generic interface for paravirtual drivers to listen
>> + for netdev register/unregister/link change events from pci ethernet
>> + devices with the same MAC and takeover their datapath. This also
>> + enables live migration of a VM with direct attached VF by failing
>> + over to the paravirtual datapath when the VF is unplugged.
>> +
>> +config MAY_USE_FAILOVER
>> + tristate
>> + default m if NET_FAILOVER=m
>> + default y if NET_FAILOVER=y || NET_FAILOVER=n
>> + help
>> + Drivers using the failover infrastructure should have a dependency
>> + on MAY_USE_FAILOVER to ensure they do not cause link errors when
>> + failover is a loadable module and the driver using it is built-in.
>> +
>> endif # if NET
>>
>> # Used by archs to tell that they support BPF JIT compiler plus which flavour.
>> diff --git a/net/core/Makefile b/net/core/Makefile
>> index 6dbbba8c57ae..cef17518bb7d 100644
>> --- a/net/core/Makefile
>> +++ b/net/core/Makefile
>> @@ -30,3 +30,4 @@ obj-$(CONFIG_DST_CACHE) += dst_cache.o
>> obj-$(CONFIG_HWBM) += hwbm.o
>> obj-$(CONFIG_NET_DEVLINK) += devlink.o
>> obj-$(CONFIG_GRO_CELLS) += gro_cells.o
>> +obj-$(CONFIG_NET_FAILOVER) += failover.o
>> diff --git a/net/core/failover.c b/net/core/failover.c
>> new file mode 100644
>> index 000000000000..7bee762cb737
>> --- /dev/null
>> +++ b/net/core/failover.c
>> @@ -0,0 +1,844 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/* Copyright (c) 2018, Intel Corporation. */
>
> I think you should copy the header from bond_main.c upon which
> some of the code seems to be based.
Yes. some of the code is based on bonding/team and netvsc. i added a reference
to netvsc in the comment, will also include bonding/team driver.
>
>> +
>> +/* A common module to handle registrations and notifications for paravirtual
>> + * drivers to enable accelerated datapath and support VF live migration.
>> + *
>> + * The notifier and event handling code is based on netvsc driver.
>> + */
>> +
>> +#include <linux/netdevice.h>
>> +#include <linux/etherdevice.h>
>> +#include <linux/ethtool.h>
>> +#include <linux/module.h>
>> +#include <linux/slab.h>
>> +#include <linux/netdevice.h>
>> +#include <linux/netpoll.h>
>> +#include <linux/rtnetlink.h>
>> +#include <linux/if_vlan.h>
>> +#include <linux/pci.h>
>> +#include <net/sch_generic.h>
>> +#include <uapi/linux/if_arp.h>
>> +#include <net/failover.h>
>> +
>> +static LIST_HEAD(failover_list);
>> +static DEFINE_SPINLOCK(failover_lock);
>> +
>> +static int failover_slave_pre_register(struct net_device *slave_dev,
>> + struct net_device *failover_dev,
>> + struct failover_ops *failover_ops)
>> +{
>> + struct failover_info *finfo;
>> + bool standby;
>> +
>> + if (failover_ops) {
>> + if (!failover_ops->slave_pre_register)
>> + return -EINVAL;
>> +
>> + return failover_ops->slave_pre_register(slave_dev,
>> + failover_dev);
>> + }
>> +
>> + finfo = netdev_priv(failover_dev);
>> + standby = (slave_dev->dev.parent == failover_dev->dev.parent);
>> + if (standby ? rtnl_dereference(finfo->standby_dev) :
>> + rtnl_dereference(finfo->primary_dev)) {
>> + netdev_err(failover_dev, "%s attempting to register as slave dev when %s already present\n",
>> + slave_dev->name, standby ? "standby" : "primary");
>> + return -EEXIST;
>> + }
>> +
>> + /* Avoid non pci devices as primary netdev */
> Why? Pls change this comment so it explains the motivation
> rather than just repeat what the code does.
OK.
>
>> + if (!standby && (!slave_dev->dev.parent ||
>> + !dev_is_pci(slave_dev->dev.parent)))
>> + return -EINVAL;
>> +
>> + return 0;
>> +}
>> +
>> +static int failover_slave_join(struct net_device *slave_dev,
>> + struct net_device *failover_dev,
>> + struct failover_ops *failover_ops)
>> +{
>> + struct failover_info *finfo;
>> + int err, orig_mtu;
>> + bool standby;
>> +
>> + if (failover_ops) {
>> + if (!failover_ops->slave_join)
>> + return -EINVAL;
>> +
>> + return failover_ops->slave_join(slave_dev, failover_dev);
>> + }
>> +
>> + if (netif_running(failover_dev)) {
>> + err = dev_open(slave_dev);
>> + if (err && (err != -EBUSY)) {
>> + netdev_err(failover_dev, "Opening slave %s failed err:%d\n",
>> + slave_dev->name, err);
>> + goto err_dev_open;
>> + }
>> + }
>> +
>> + /* Align MTU of slave with failover dev */
>> + orig_mtu = slave_dev->mtu;
> I suspect this was copied from bond. this variable is never
> used and I'm even surprised gcc did not warn about this.
Thanks for catching, I broke this when i moved the dev_open() and dev_set_mtu()
calls from register to join. I need to reset slave_dev mtu to orig_mtu on failure.
>
>
>> + err = dev_set_mtu(slave_dev, failover_dev->mtu);
> How do we know slave supports this MTU? same applies to
> failover_change_mtu.
The err check below should catch it and we will reset the mtu back and
fail the join/register.
>
>
>
>
>> + if (err) {
>> + netdev_err(failover_dev, "unable to change mtu of %s to %u register failed\n",
>> + slave_dev->name, failover_dev->mtu);
>> + goto err_set_mtu;
>> + }
>> +
>> + finfo = netdev_priv(failover_dev);
>> + standby = (slave_dev->dev.parent == failover_dev->dev.parent);
>> +
>> + dev_hold(slave_dev);
>> +
>> + if (standby) {
>> + rcu_assign_pointer(finfo->standby_dev, slave_dev);
>> + dev_get_stats(finfo->standby_dev, &finfo->standby_stats);
>> + } else {
>> + rcu_assign_pointer(finfo->primary_dev, slave_dev);
>> + dev_get_stats(finfo->primary_dev, &finfo->primary_stats);
>> + failover_dev->min_mtu = slave_dev->min_mtu;
>> + failover_dev->max_mtu = slave_dev->max_mtu;
>> + }
>> +
>> + netdev_info(failover_dev, "failover slave:%s joined\n",
>> + slave_dev->name);
>> +
>> + return 0;
>> +
>> +err_set_mtu:
>> + dev_close(slave_dev);
>> +err_dev_open:
>> + return err;
>> +}
>> +
>> +/* Called when slave dev is injecting data into network stack.
>> + * Change the associated network device from lower dev to virtio.
>> + * note: already called with rcu_read_lock
>> + */
>> +static rx_handler_result_t failover_handle_frame(struct sk_buff **pskb)
>> +{
>> + struct sk_buff *skb = *pskb;
>> + struct net_device *ndev = rcu_dereference(skb->dev->rx_handler_data);
>> +
>> + skb->dev = ndev;
>> +
>> + return RX_HANDLER_ANOTHER;
>> +}
>> +
>> +static struct net_device *failover_get_bymac(u8 *mac, struct failover_ops **ops)
>> +{
>> + struct net_device *failover_dev;
>> + struct failover *failover;
>> +
>> + spin_lock(&failover_lock);
>> + list_for_each_entry(failover, &failover_list, list) {
>> + failover_dev = rtnl_dereference(failover->failover_dev);
>> + if (ether_addr_equal(failover_dev->perm_addr, mac)) {
>> + *ops = rtnl_dereference(failover->ops);
>> + spin_unlock(&failover_lock);
>> + return failover_dev;
>> + }
>> + }
>> + spin_unlock(&failover_lock);
>> + return NULL;
>> +}
>> +
>> +static int failover_slave_register(struct net_device *slave_dev)
>> +{
>> + struct failover_ops *failover_ops;
>> + struct net_device *failover_dev;
>> + int ret;
>> +
>> + ASSERT_RTNL();
>> +
>> + failover_dev = failover_get_bymac(slave_dev->perm_addr, &failover_ops);
>> + if (!failover_dev)
>> + goto done;
>> +
>> + ret = failover_slave_pre_register(slave_dev, failover_dev,
>> + failover_ops);
>> + if (ret)
>> + goto done;
>> +
>> + ret = netdev_rx_handler_register(slave_dev, failover_ops ?
>> + failover_ops->handle_frame :
>> + failover_handle_frame, failover_dev);
>> + if (ret) {
>> + netdev_err(slave_dev, "can not register failover rx handler (err = %d)\n",
>> + ret);
>> + goto done;
>> + }
>> +
>> + ret = netdev_upper_dev_link(slave_dev, failover_dev, NULL);
>> + if (ret) {
>> + netdev_err(slave_dev, "can not set failover device %s (err = %d)\n",
>> + failover_dev->name, ret);
>> + goto upper_link_failed;
>> + }
>> +
>> + slave_dev->priv_flags |= IFF_FAILOVER_SLAVE;
>> +
>> + ret = failover_slave_join(slave_dev, failover_dev, failover_ops);
>> + if (ret)
>> + goto err_join;
>> +
>> + call_netdevice_notifiers(NETDEV_JOIN, slave_dev);
>> +
>> + netdev_info(failover_dev, "failover slave:%s registered\n",
>> + slave_dev->name);
>> +
>> + goto done;
>> +
>> +err_join:
>> + netdev_upper_dev_unlink(slave_dev, failover_dev);
>> + slave_dev->priv_flags &= ~IFF_FAILOVER_SLAVE;
>> +upper_link_failed:
>> + netdev_rx_handler_unregister(slave_dev);
>> +done:
>> + return NOTIFY_DONE;
>> +}
>> +
>> +static int failover_slave_pre_unregister(struct net_device *slave_dev,
>> + struct net_device *failover_dev,
>> + struct failover_ops *failover_ops)
>> +{
>> + struct net_device *standby_dev, *primary_dev;
>> + struct failover_info *finfo;
>> +
>> + if (failover_ops) {
>> + if (!failover_ops->slave_pre_unregister)
>> + return -EINVAL;
>> +
>> + return failover_ops->slave_pre_unregister(slave_dev,
>> + failover_dev);
>> + }
>> +
>> + finfo = netdev_priv(failover_dev);
>> + primary_dev = rtnl_dereference(finfo->primary_dev);
>> + standby_dev = rtnl_dereference(finfo->standby_dev);
>> +
>> + if (slave_dev != primary_dev && slave_dev != standby_dev)
>> + return -EINVAL;
>> +
>> + return 0;
>> +}
>> +
>> +static int failover_slave_release(struct net_device *slave_dev,
>> + struct net_device *failover_dev,
>> + struct failover_ops *failover_ops)
>> +{
>> + struct net_device *standby_dev, *primary_dev;
>> + struct failover_info *finfo;
>> +
>> + if (failover_ops) {
>> + if (!failover_ops->slave_release)
>> + return -EINVAL;
>> +
>> + return failover_ops->slave_release(slave_dev, failover_dev);
>> + }
>> +
>> + finfo = netdev_priv(failover_dev);
>> + primary_dev = rtnl_dereference(finfo->primary_dev);
>> + standby_dev = rtnl_dereference(finfo->standby_dev);
>> +
>> + if (slave_dev == standby_dev) {
>> + RCU_INIT_POINTER(finfo->standby_dev, NULL);
>> + } else {
>> + RCU_INIT_POINTER(finfo->primary_dev, NULL);
>> + if (standby_dev) {
>> + failover_dev->min_mtu = standby_dev->min_mtu;
>> + failover_dev->max_mtu = standby_dev->max_mtu;
>> + }
>> + }
>> +
>> + dev_put(slave_dev);
>> +
>> + netdev_info(failover_dev, "failover slave:%s released\n",
>> + slave_dev->name);
>> +
>> + return 0;
>> +}
>> +
>> +int failover_slave_unregister(struct net_device *slave_dev)
>> +{
>> + struct failover_ops *failover_ops;
>> + struct net_device *failover_dev;
>> + int ret;
>> +
>> + if (!netif_is_failover_slave(slave_dev))
>> + goto done;
>> +
>> + ASSERT_RTNL();
>> +
>> + failover_dev = failover_get_bymac(slave_dev->perm_addr, &failover_ops);
>> + if (!failover_dev)
>> + goto done;
>> +
>> + ret = failover_slave_pre_unregister(slave_dev, failover_dev,
>> + failover_ops);
>> + if (ret)
>> + goto done;
>> +
>> + netdev_rx_handler_unregister(slave_dev);
>> + netdev_upper_dev_unlink(slave_dev, failover_dev);
>> + slave_dev->priv_flags &= ~IFF_FAILOVER_SLAVE;
>> +
>> + failover_slave_release(slave_dev, failover_dev, failover_ops);
>
> Don't you need to get stats from it? This device is going away ...
Yes. we need to update the failover_stats before the slave goes away.
>
>> +
>> + netdev_info(failover_dev, "failover slave:%s unregistered\n",
>> + slave_dev->name);
>> +
>> +done:
>> + return NOTIFY_DONE;
>> +}
>> +EXPORT_SYMBOL_GPL(failover_slave_unregister);
>> +
>> +static bool failover_xmit_ready(struct net_device *dev)
>> +{
>> + return netif_running(dev) && netif_carrier_ok(dev);
>> +}
>> +
>> +static int failover_slave_link_change(struct net_device *slave_dev)
>> +{
>> + struct net_device *failover_dev, *primary_dev, *standby_dev;
>> + struct failover_ops *failover_ops;
>> + struct failover_info *finfo;
>> +
>> + if (!netif_is_failover_slave(slave_dev))
>> + goto done;
>> +
>> + ASSERT_RTNL();
>> +
>> + failover_dev = failover_get_bymac(slave_dev->perm_addr, &failover_ops);
>> + if (!failover_dev)
>> + goto done;
>> +
>> + if (failover_ops) {
>> + if (!failover_ops->slave_link_change)
>> + goto done;
>> +
>> + return failover_ops->slave_link_change(slave_dev, failover_dev);
>> + }
>> +
>> + if (!netif_running(failover_dev))
>> + return 0;
>> +
>> + finfo = netdev_priv(failover_dev);
>> +
>> + primary_dev = rtnl_dereference(finfo->primary_dev);
>> + standby_dev = rtnl_dereference(finfo->standby_dev);
>> +
>> + if (slave_dev != primary_dev && slave_dev != standby_dev)
>> + goto done;
>> +
>> + if ((primary_dev && failover_xmit_ready(primary_dev)) ||
>> + (standby_dev && failover_xmit_ready(standby_dev))) {
>> + netif_carrier_on(failover_dev);
>> + netif_tx_wake_all_queues(failover_dev);
>> + } else {
>> + netif_carrier_off(failover_dev);
>> + netif_tx_stop_all_queues(failover_dev);
> And I think it's a good idea to get stats from device here too.
Not sure why we need to get stats from lower devs here?
>
>
>> + }
>> +
>> +done:
>> + return NOTIFY_DONE;
>> +}
>> +
>> +static bool failover_validate_event_dev(struct net_device *dev)
>> +{
>> + /* Skip parent events */
>> + if (netif_is_failover(dev))
>> + return false;
>> +
>> + /* Avoid non-Ethernet type devices */
> ... for now. It would be possible easy to make this generic -
> just copy things like type and addr_len from slave.
ok. failover_create can copy these values from standby_dev and
we can validate that they match when primary_dev registers.
>
>> + if (dev->type != ARPHRD_ETHER)
>> + return false;
>> +
>> + return true;
>> +}
>> +
>> +static int
>> +failover_event(struct notifier_block *this, unsigned long event, void *ptr)
>> +{
>> + struct net_device *event_dev = netdev_notifier_info_to_dev(ptr);
>> +
>> + if (!failover_validate_event_dev(event_dev))
>> + return NOTIFY_DONE;
>> +
>> + switch (event) {
>> + case NETDEV_REGISTER:
>> + return failover_slave_register(event_dev);
>> + case NETDEV_UNREGISTER:
>> + return failover_slave_unregister(event_dev);
>> + case NETDEV_UP:
>> + case NETDEV_DOWN:
>> + case NETDEV_CHANGE:
>> + return failover_slave_link_change(event_dev);
>> + default:
>> + return NOTIFY_DONE;
>> + }
>> +}
>> +
>> +static struct notifier_block failover_notifier = {
>> + .notifier_call = failover_event,
>> +};
>> +
>> +static int failover_open(struct net_device *dev)
>> +{
>> + struct failover_info *finfo = netdev_priv(dev);
>> + struct net_device *primary_dev, *standby_dev;
>> + int err;
>> +
>> + netif_carrier_off(dev);
>> + netif_tx_wake_all_queues(dev);
>> +
>> + primary_dev = rtnl_dereference(finfo->primary_dev);
>> + if (primary_dev) {
>> + err = dev_open(primary_dev);
>> + if (err)
>> + goto err_primary_open;
>> + }
>> +
>> + standby_dev = rtnl_dereference(finfo->standby_dev);
>> + if (standby_dev) {
>> + err = dev_open(standby_dev);
>> + if (err)
>> + goto err_standby_open;
>> + }
>> +
>> + return 0;
>> +
>> +err_standby_open:
>> + dev_close(primary_dev);
>> +err_primary_open:
>> + netif_tx_disable(dev);
>> + return err;
>> +}
>> +
>> +static int failover_close(struct net_device *dev)
>> +{
>> + struct failover_info *finfo = netdev_priv(dev);
>> + struct net_device *slave_dev;
>> +
>> + netif_tx_disable(dev);
>> +
>> + slave_dev = rtnl_dereference(finfo->primary_dev);
>> + if (slave_dev)
>> + dev_close(slave_dev);
>> +
>> + slave_dev = rtnl_dereference(finfo->standby_dev);
>> + if (slave_dev)
>> + dev_close(slave_dev);
>> +
>> + return 0;
>> +}
>> +
>> +static netdev_tx_t failover_drop_xmit(struct sk_buff *skb,
>> + struct net_device *dev)
>> +{
>> + atomic_long_inc(&dev->tx_dropped);
>> + dev_kfree_skb_any(skb);
>> + return NETDEV_TX_OK;
>> +}
>> +
>> +static netdev_tx_t failover_start_xmit(struct sk_buff *skb,
>> + struct net_device *dev)
>> +{
>> + struct failover_info *finfo = netdev_priv(dev);
>> + struct net_device *xmit_dev;
>> +
>> + /* Try xmit via primary netdev followed by standby netdev */
>> + xmit_dev = rcu_dereference_bh(finfo->primary_dev);
>> + if (!xmit_dev || !failover_xmit_ready(xmit_dev)) {
>> + xmit_dev = rcu_dereference_bh(finfo->standby_dev);
>> + if (!xmit_dev || !failover_xmit_ready(xmit_dev))
>> + return failover_drop_xmit(skb, dev);
>> + }
>> +
>> + skb->dev = xmit_dev;
>> + skb->queue_mapping = qdisc_skb_cb(skb)->slave_dev_queue_mapping;
>> +
>> + return dev_queue_xmit(skb);
>> +}
> Is this going through qdisc twice? Won't this hurt performance
> measureably?
The failover dev has no queue (IFF_NO_QUEUE) , so doesn't go through qdisc twice.
>
>> +
>> +static u16 failover_select_queue(struct net_device *dev, struct sk_buff *skb,
>> + void *accel_priv,
>> + select_queue_fallback_t fallback)
>> +{
>> + struct failover_info *finfo = netdev_priv(dev);
>> + struct net_device *primary_dev;
>> + u16 txq;
>> +
>> + rcu_read_lock();
>> + primary_dev = rcu_dereference(finfo->primary_dev);
>> + if (primary_dev) {
>> + const struct net_device_ops *ops = primary_dev->netdev_ops;
>> +
>> + if (ops->ndo_select_queue)
>> + txq = ops->ndo_select_queue(primary_dev, skb,
>> + accel_priv, fallback);
>> + else
>> + txq = fallback(primary_dev, skb);
>> +
>> + qdisc_skb_cb(skb)->slave_dev_queue_mapping = skb->queue_mapping;
>> +
>> + return txq;
>> + }
>> +
>> + txq = skb_rx_queue_recorded(skb) ? skb_get_rx_queue(skb) : 0;
>> +
>> + /* Save the original txq to restore before passing to the driver */
>> + qdisc_skb_cb(skb)->slave_dev_queue_mapping = skb->queue_mapping;
>> +
>> + if (unlikely(txq >= dev->real_num_tx_queues)) {
>> + do {
>> + txq -= dev->real_num_tx_queues;
>> + } while (txq >= dev->real_num_tx_queues);
>> + }
>> +
>> + return txq;
>> +}
>> +
>> +/* fold stats, assuming all rtnl_link_stats64 fields are u64, but
>> + * that some drivers can provide 32finfot values only.
>> + */
>> +static void failover_fold_stats(struct rtnl_link_stats64 *_res,
>> + const struct rtnl_link_stats64 *_new,
>> + const struct rtnl_link_stats64 *_old)
>> +{
>> + const u64 *new = (const u64 *)_new;
>> + const u64 *old = (const u64 *)_old;
>> + u64 *res = (u64 *)_res;
>> + int i;
>> +
>> + for (i = 0; i < sizeof(*_res) / sizeof(u64); i++) {
>> + u64 nv = new[i];
>> + u64 ov = old[i];
>> + s64 delta = nv - ov;
>> +
>> + /* detects if this particular field is 32bit only */
>> + if (((nv | ov) >> 32) == 0)
>> + delta = (s64)(s32)((u32)nv - (u32)ov);
>> +
>> + /* filter anomalies, some drivers reset their stats
>> + * at down/up events.
>> + */
>> + if (delta > 0)
>> + res[i] += delta;
>> + }
>> +}
>> +
>> +static void failover_get_stats(struct net_device *dev,
>> + struct rtnl_link_stats64 *stats)
>> +{
>> + struct failover_info *finfo = netdev_priv(dev);
>> + const struct rtnl_link_stats64 *new;
>> + struct rtnl_link_stats64 temp;
>> + struct net_device *slave_dev;
>> +
>> + spin_lock(&finfo->stats_lock);
>> + memcpy(stats, &finfo->failover_stats, sizeof(*stats));
>> +
>> + rcu_read_lock();
>> +
>> + slave_dev = rcu_dereference(finfo->primary_dev);
>> + if (slave_dev) {
>> + new = dev_get_stats(slave_dev, &temp);
>> + failover_fold_stats(stats, new, &finfo->primary_stats);
>> + memcpy(&finfo->primary_stats, new, sizeof(*new));
>> + }
>> +
>> + slave_dev = rcu_dereference(finfo->standby_dev);
>> + if (slave_dev) {
>> + new = dev_get_stats(slave_dev, &temp);
>> + failover_fold_stats(stats, new, &finfo->standby_stats);
>> + memcpy(&finfo->standby_stats, new, sizeof(*new));
>> + }
>> +
>> + rcu_read_unlock();
>> +
>> + memcpy(&finfo->failover_stats, stats, sizeof(*stats));
>> + spin_unlock(&finfo->stats_lock);
>> +}
>> +
>> +static int failover_change_mtu(struct net_device *dev, int new_mtu)
>> +{
>> + struct failover_info *finfo = netdev_priv(dev);
>> + struct net_device *primary_dev, *standby_dev;
>> + int ret = 0;
>> +
>> + primary_dev = rcu_dereference(finfo->primary_dev);
>> + if (primary_dev) {
>> + ret = dev_set_mtu(primary_dev, new_mtu);
>> + if (ret)
>> + return ret;
>> + }
>> +
>> + standby_dev = rcu_dereference(finfo->standby_dev);
>> + if (standby_dev) {
>> + ret = dev_set_mtu(standby_dev, new_mtu);
>> + if (ret) {
>> + dev_set_mtu(primary_dev, dev->mtu);
>> + return ret;
>> + }
>> + }
>> +
>> + dev->mtu = new_mtu;
>> + return 0;
>> +}
>> +
>> +static void failover_set_rx_mode(struct net_device *dev)
>> +{
>> + struct failover_info *finfo = netdev_priv(dev);
>> + struct net_device *slave_dev;
>> +
>> + rcu_read_lock();
>> +
>> + slave_dev = rcu_dereference(finfo->primary_dev);
>> + if (slave_dev) {
>> + dev_uc_sync_multiple(slave_dev, dev);
>> + dev_mc_sync_multiple(slave_dev, dev);
>> + }
>> +
>> + slave_dev = rcu_dereference(finfo->standby_dev);
>> + if (slave_dev) {
>> + dev_uc_sync_multiple(slave_dev, dev);
>> + dev_mc_sync_multiple(slave_dev, dev);
>> + }
>> +
>> + rcu_read_unlock();
>> +}
>> +
>> +static const struct net_device_ops failover_dev_ops = {
>> + .ndo_open = failover_open,
>> + .ndo_stop = failover_close,
>> + .ndo_start_xmit = failover_start_xmit,
>> + .ndo_select_queue = failover_select_queue,
>> + .ndo_get_stats64 = failover_get_stats,
>> + .ndo_change_mtu = failover_change_mtu,
>> + .ndo_set_rx_mode = failover_set_rx_mode,
>> + .ndo_validate_addr = eth_validate_addr,
>> + .ndo_features_check = passthru_features_check,
> xdp support?
I think it should be possible to add it be calling the lower dev ndo_xdp routines
with proper checks. can we add this later?
>
>> +};
>> +
>> +#define FAILOVER_NAME "failover"
>> +#define FAILOVER_VERSION "0.1"
>> +
>> +static void failover_ethtool_get_drvinfo(struct net_device *dev,
>> + struct ethtool_drvinfo *drvinfo)
>> +{
>> + strlcpy(drvinfo->driver, FAILOVER_NAME, sizeof(drvinfo->driver));
>> + strlcpy(drvinfo->version, FAILOVER_VERSION, sizeof(drvinfo->version));
>> +}
>> +
>> +int failover_ethtool_get_link_ksettings(struct net_device *dev,
>> + struct ethtool_link_ksettings *cmd)
>> +{
>> + struct failover_info *finfo = netdev_priv(dev);
>> + struct net_device *slave_dev;
>> +
>> + slave_dev = rtnl_dereference(finfo->primary_dev);
>> + if (!slave_dev || !failover_xmit_ready(slave_dev)) {
>> + slave_dev = rtnl_dereference(finfo->standby_dev);
>> + if (!slave_dev || !failover_xmit_ready(slave_dev)) {
>> + cmd->base.duplex = DUPLEX_UNKNOWN;
>> + cmd->base.port = PORT_OTHER;
>> + cmd->base.speed = SPEED_UNKNOWN;
>> +
>> + return 0;
>> + }
>> + }
>> +
>> + return __ethtool_get_link_ksettings(slave_dev, cmd);
>> +}
>> +EXPORT_SYMBOL_GPL(failover_ethtool_get_link_ksettings);
>> +
>> +static const struct ethtool_ops failover_ethtool_ops = {
>> + .get_drvinfo = failover_ethtool_get_drvinfo,
>> + .get_link = ethtool_op_get_link,
>> + .get_link_ksettings = failover_ethtool_get_link_ksettings,
>> +};
>> +
>> +static void failover_register_existing_slave(struct net_device *failover_dev)
>> +{
>> + struct net *net = dev_net(failover_dev);
>> + struct net_device *dev;
>> +
>> + rtnl_lock();
>> + for_each_netdev(net, dev) {
>> + if (dev == failover_dev)
>> + continue;
>> + if (!failover_validate_event_dev(dev))
>> + continue;
>> + if (ether_addr_equal(failover_dev->perm_addr, dev->perm_addr))
>> + failover_slave_register(dev);
>> + }
>> + rtnl_unlock();
>> +}
>> +
>> +int failover_register(struct net_device *dev, struct failover_ops *ops,
>> + struct failover **pfailover)
>> +{
>> + struct failover *failover;
>> +
>> + failover = kzalloc(sizeof(*failover), GFP_KERNEL);
>> + if (!failover)
>> + return -ENOMEM;
>> +
>> + rcu_assign_pointer(failover->ops, ops);
>> + dev_hold(dev);
>> + dev->priv_flags |= IFF_FAILOVER;
>> + rcu_assign_pointer(failover->failover_dev, dev);
>> +
>> + spin_lock(&failover_lock);
>> + list_add_tail(&failover->list, &failover_list);
>> + spin_unlock(&failover_lock);
>> +
>> + failover_register_existing_slave(dev);
>> +
>> + *pfailover = failover;
>> + return 0;
>> +}
>> +EXPORT_SYMBOL_GPL(failover_register);
>> +
>> +void failover_unregister(struct failover *failover)
>> +{
>> + struct net_device *failover_dev;
>> +
>> + failover_dev = rcu_dereference(failover->failover_dev);
>> +
>> + failover_dev->priv_flags &= ~IFF_FAILOVER;
>> + dev_put(failover_dev);
>> +
>> + spin_lock(&failover_lock);
>> + list_del(&failover->list);
>> + spin_unlock(&failover_lock);
>> +
>> + kfree(failover);
>> +}
>> +EXPORT_SYMBOL_GPL(failover_unregister);
>> +
>> +int failover_create(struct net_device *standby_dev, struct failover **pfailover)
>> +{
>> + struct device *dev = standby_dev->dev.parent;
>> + struct net_device *failover_dev;
>> + int err;
>> +
>> + /* Alloc at least 2 queues, for now we are going with 16 assuming
>> + * that most devices being bonded won't have too many queues.
>> + */
>> + failover_dev = alloc_etherdev_mq(sizeof(struct failover_info), 16);
>> + if (!failover_dev) {
>> + dev_err(dev, "Unable to allocate failover_netdev!\n");
>> + return -ENOMEM;
>> + }
>> +
>> + dev_net_set(failover_dev, dev_net(standby_dev));
>> + SET_NETDEV_DEV(failover_dev, dev);
>> +
>> + failover_dev->netdev_ops = &failover_dev_ops;
>> + failover_dev->ethtool_ops = &failover_ethtool_ops;
>> +
>> + /* Initialize the device options */
>> + failover_dev->priv_flags |= IFF_UNICAST_FLT | IFF_NO_QUEUE;
>> + failover_dev->priv_flags &= ~(IFF_XMIT_DST_RELEASE |
>> + IFF_TX_SKB_SHARING);
>> +
>> + /* don't acquire failover netdev's netif_tx_lock when transmitting */
>> + failover_dev->features |= NETIF_F_LLTX;
>> +
>> + /* Don't allow failover devices to change network namespaces. */
>> + failover_dev->features |= NETIF_F_NETNS_LOCAL;
>> +
>> + failover_dev->hw_features = NETIF_F_HW_CSUM | NETIF_F_SG |
>> + NETIF_F_FRAGLIST | NETIF_F_ALL_TSO |
>> + NETIF_F_HIGHDMA | NETIF_F_LRO;
> OK but then you must make sure your primary and standby both
> support these features.
I guess i need to add something like bond_compute_features() to handle this.
>
>> +
>> + failover_dev->hw_features |= NETIF_F_GSO_ENCAP_ALL;
>> + failover_dev->features |= failover_dev->hw_features;
>> +
>> + memcpy(failover_dev->dev_addr, standby_dev->dev_addr,
>> + failover_dev->addr_len);
>> +
>> + failover_dev->min_mtu = standby_dev->min_mtu;
>> + failover_dev->max_mtu = standby_dev->max_mtu;
> OK MTU is copied, fine. But is this always enough?
>
> How about e.g. hard_header_len? min_header_len? needed_headroom?
> needed_tailroom? I'd worry that even if you cover existing ones more
> might be added with time. A function copying config between devices
> probably belongs in some central place IMHO.
ok. will add a function that handles these fields too.
>
>
>> +
>> + err = register_netdev(failover_dev);
>> + if (err < 0) {
>> + dev_err(dev, "Unable to register failover_dev!\n");
>> + goto err_register_netdev;
>> + }
>> +
>> + netif_carrier_off(failover_dev);
>> +
>> + err = failover_register(failover_dev, NULL, pfailover);
>> + if (err < 0)
>> + goto err_failover;
>> +
>> + return 0;
>> +
>> +err_failover:
>> + unregister_netdev(failover_dev);
>> +err_register_netdev:
>> + free_netdev(failover_dev);
>> +
>> + return err;
>> +}
>> +EXPORT_SYMBOL_GPL(failover_create);
>> +
>> +void failover_destroy(struct failover *failover)
>> +{
>> + struct net_device *failover_dev;
>> + struct net_device *slave_dev;
>> + struct failover_info *finfo;
>> +
>> + if (!failover)
>> + return;
>> +
>> + failover_dev = rcu_dereference(failover->failover_dev);
>> + finfo = netdev_priv(failover_dev);
>> +
>> + netif_device_detach(failover_dev);
>> +
>> + rtnl_lock();
>> +
>> + slave_dev = rtnl_dereference(finfo->primary_dev);
>> + if (slave_dev)
>> + failover_slave_unregister(slave_dev);
>> +
>> + slave_dev = rtnl_dereference(finfo->standby_dev);
>> + if (slave_dev)
>> + failover_slave_unregister(slave_dev);
>> +
>> + failover_unregister(failover);
>> +
>> + unregister_netdevice(failover_dev);
>> +
>> + rtnl_unlock();
>> +
>> + free_netdev(failover_dev);
>> +}
>> +EXPORT_SYMBOL_GPL(failover_destroy);
>> +
>> +static __init int
>> +failover_init(void)
>> +{
>> + register_netdevice_notifier(&failover_notifier);
>> +
>> + return 0;
>> +}
>> +module_init(failover_init);
>> +
>> +static __exit
>> +void failover_exit(void)
>> +{
>> + unregister_netdevice_notifier(&failover_notifier);
>> +}
>> +module_exit(failover_exit);
>> +
>> +MODULE_DESCRIPTION("Failover infrastructure/interface for Paravirtual drivers");
>> +MODULE_LICENSE("GPL v2");
>> --
>> 2.14.3
^ permalink raw reply [flat|nested] 114+ messages in thread
* [virtio-dev] Re: [PATCH v7 net-next 2/4] net: Introduce generic failover module
@ 2018-04-20 15:21 ` Samudrala, Sridhar
0 siblings, 0 replies; 114+ messages in thread
From: Samudrala, Sridhar @ 2018-04-20 15:21 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: stephen, davem, netdev, virtualization, virtio-dev,
jesse.brandeburg, alexander.h.duyck, kubakici, jasowang,
loseweigh, jiri
On 4/19/2018 7:44 PM, Michael S. Tsirkin wrote:
> On Thu, Apr 19, 2018 at 06:42:02PM -0700, Sridhar Samudrala wrote:
>> This provides a generic interface for paravirtual drivers to listen
>> for netdev register/unregister/link change events from pci ethernet
>> devices with the same MAC and takeover their datapath. The notifier and
>> event handling code is based on the existing netvsc implementation.
>>
>> It exposes 2 sets of interfaces to the paravirtual drivers.
>> 1. existing netvsc driver that uses 2 netdev model. In this model, no
>> master netdev is created. The paravirtual driver registers each instance
>> of netvsc as a 'failover' instance along with a set of ops to manage the
>> slave events.
>> failover_register()
>> failover_unregister()
>> 2. new virtio_net based solution that uses 3 netdev model. In this model,
>> the failover module provides interfaces to create/destroy additional master
>> netdev and all the slave events are managed internally.
>> failover_create()
>> failover_destroy()
>> These functions call failover_register()/failover_unregister() with the
>> master netdev created by the failover module.
>>
>> Signed-off-by: Sridhar Samudrala <sridhar.samudrala@intel.com>
> I like this patch. Yes something to improve (see below)
>
>> ---
>> include/linux/netdevice.h | 16 +
>> include/net/failover.h | 96 ++++++
>> net/Kconfig | 18 +
>> net/core/Makefile | 1 +
>> net/core/failover.c | 844 ++++++++++++++++++++++++++++++++++++++++++++++
>> 5 files changed, 975 insertions(+)
>> create mode 100644 include/net/failover.h
>> create mode 100644 net/core/failover.c
>>
>> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
>> index cf44503ea81a..ed535b6724e1 100644
>> --- a/include/linux/netdevice.h
>> +++ b/include/linux/netdevice.h
>> @@ -1401,6 +1401,8 @@ struct net_device_ops {
>> * entity (i.e. the master device for bridged veth)
>> * @IFF_MACSEC: device is a MACsec device
>> * @IFF_NO_RX_HANDLER: device doesn't support the rx_handler hook
>> + * @IFF_FAILOVER: device is a failover master device
>> + * @IFF_FAILOVER_SLAVE: device is lower dev of a failover master device
>> */
>> enum netdev_priv_flags {
>> IFF_802_1Q_VLAN = 1<<0,
>> @@ -1430,6 +1432,8 @@ enum netdev_priv_flags {
>> IFF_PHONY_HEADROOM = 1<<24,
>> IFF_MACSEC = 1<<25,
>> IFF_NO_RX_HANDLER = 1<<26,
>> + IFF_FAILOVER = 1<<27,
>> + IFF_FAILOVER_SLAVE = 1<<28,
>> };
>>
>> #define IFF_802_1Q_VLAN IFF_802_1Q_VLAN
>> @@ -1458,6 +1462,8 @@ enum netdev_priv_flags {
>> #define IFF_RXFH_CONFIGURED IFF_RXFH_CONFIGURED
>> #define IFF_MACSEC IFF_MACSEC
>> #define IFF_NO_RX_HANDLER IFF_NO_RX_HANDLER
>> +#define IFF_FAILOVER IFF_FAILOVER
>> +#define IFF_FAILOVER_SLAVE IFF_FAILOVER_SLAVE
>>
>> /**
>> * struct net_device - The DEVICE structure.
>> @@ -4308,6 +4314,16 @@ static inline bool netif_is_rxfh_configured(const struct net_device *dev)
>> return dev->priv_flags & IFF_RXFH_CONFIGURED;
>> }
>>
>> +static inline bool netif_is_failover(const struct net_device *dev)
>> +{
>> + return dev->priv_flags & IFF_FAILOVER;
>> +}
>> +
>> +static inline bool netif_is_failover_slave(const struct net_device *dev)
>> +{
>> + return dev->priv_flags & IFF_FAILOVER_SLAVE;
>> +}
>> +
>> /* This device needs to keep skb dst for qdisc enqueue or ndo_start_xmit() */
>> static inline void netif_keep_dst(struct net_device *dev)
>> {
>> diff --git a/include/net/failover.h b/include/net/failover.h
>> new file mode 100644
>> index 000000000000..0b8601043d90
>> --- /dev/null
>> +++ b/include/net/failover.h
>> @@ -0,0 +1,96 @@
>> +/* SPDX-License-Identifier: GPL-2.0 */
>> +/* Copyright (c) 2018, Intel Corporation. */
>> +
>> +#ifndef _NET_FAILOVER_H
>> +#define _NET_FAILOVER_H
>> +
>> +#include <linux/netdevice.h>
>> +
>> +struct failover_ops {
>> + int (*slave_pre_register)(struct net_device *slave_dev,
>> + struct net_device *failover_dev);
>> + int (*slave_join)(struct net_device *slave_dev,
>> + struct net_device *failover_dev);
>> + int (*slave_pre_unregister)(struct net_device *slave_dev,
>> + struct net_device *failover_dev);
>> + int (*slave_release)(struct net_device *slave_dev,
>> + struct net_device *failover_dev);
>> + int (*slave_link_change)(struct net_device *slave_dev,
>> + struct net_device *failover_dev);
>> + rx_handler_result_t (*handle_frame)(struct sk_buff **pskb);
>> +};
>> +
>> +struct failover {
>> + struct list_head list;
>> + struct net_device __rcu *failover_dev;
>> + struct failover_ops __rcu *ops;
>> +};
>> +
>> +/* failover state */
>> +struct failover_info {
>> + /* primary netdev with same MAC */
>> + struct net_device __rcu *primary_dev;
>> +
>> + /* standby netdev */
>> + struct net_device __rcu *standby_dev;
>> +
>> + /* primary netdev stats */
>> + struct rtnl_link_stats64 primary_stats;
>> +
>> + /* standby netdev stats */
>> + struct rtnl_link_stats64 standby_stats;
>> +
>> + /* aggregated stats */
>> + struct rtnl_link_stats64 failover_stats;
>> +
>> + /* spinlock while updating stats */
>> + spinlock_t stats_lock;
>> +};
>> +
>> +#if IS_ENABLED(CONFIG_NET_FAILOVER)
>> +
>> +int failover_create(struct net_device *standby_dev,
>> + struct failover **pfailover);
>> +void failover_destroy(struct failover *failover);
>> +
>> +int failover_register(struct net_device *standby_dev, struct failover_ops *ops,
>> + struct failover **pfailover);
>> +void failover_unregister(struct failover *failover);
>> +
>> +int failover_slave_unregister(struct net_device *slave_dev);
>> +
>> +#else
>> +
>> +static inline
>> +int failover_create(struct net_device *standby_dev,
>> + struct failover **pfailover);
>> +{
>> + return 0;
>> +}
>> +
>> +static inline
>> +void failover_destroy(struct failover *failover)
>> +{
>> +}
>> +
>> +static inline
>> +int failover_register(struct net_device *standby_dev, struct failover_ops *ops,
>> + struct pfailover **pfailover);
>> +{
>> + return 0;
>> +}
>> +
>> +static inline
>> +void failover_unregister(struct failover *failover)
>> +{
>> +}
>> +
>> +static inline
>> +int failover_slave_unregister(struct net_device *slave_dev)
>> +{
>> + return 0;
>> +}
>> +
>> +#endif
>> +
>> +#endif /* _NET_FAILOVER_H */
>> diff --git a/net/Kconfig b/net/Kconfig
>> index 0428f12c25c2..388b99dfee10 100644
>> --- a/net/Kconfig
>> +++ b/net/Kconfig
>> @@ -423,6 +423,24 @@ config MAY_USE_DEVLINK
>> on MAY_USE_DEVLINK to ensure they do not cause link errors when
>> devlink is a loadable module and the driver using it is built-in.
>>
>> +config NET_FAILOVER
>> + tristate "Failover interface"
>> + help
>> + This provides a generic interface for paravirtual drivers to listen
>> + for netdev register/unregister/link change events from pci ethernet
>> + devices with the same MAC and takeover their datapath. This also
>> + enables live migration of a VM with direct attached VF by failing
>> + over to the paravirtual datapath when the VF is unplugged.
>> +
>> +config MAY_USE_FAILOVER
>> + tristate
>> + default m if NET_FAILOVER=m
>> + default y if NET_FAILOVER=y || NET_FAILOVER=n
>> + help
>> + Drivers using the failover infrastructure should have a dependency
>> + on MAY_USE_FAILOVER to ensure they do not cause link errors when
>> + failover is a loadable module and the driver using it is built-in.
>> +
>> endif # if NET
>>
>> # Used by archs to tell that they support BPF JIT compiler plus which flavour.
>> diff --git a/net/core/Makefile b/net/core/Makefile
>> index 6dbbba8c57ae..cef17518bb7d 100644
>> --- a/net/core/Makefile
>> +++ b/net/core/Makefile
>> @@ -30,3 +30,4 @@ obj-$(CONFIG_DST_CACHE) += dst_cache.o
>> obj-$(CONFIG_HWBM) += hwbm.o
>> obj-$(CONFIG_NET_DEVLINK) += devlink.o
>> obj-$(CONFIG_GRO_CELLS) += gro_cells.o
>> +obj-$(CONFIG_NET_FAILOVER) += failover.o
>> diff --git a/net/core/failover.c b/net/core/failover.c
>> new file mode 100644
>> index 000000000000..7bee762cb737
>> --- /dev/null
>> +++ b/net/core/failover.c
>> @@ -0,0 +1,844 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/* Copyright (c) 2018, Intel Corporation. */
>
> I think you should copy the header from bond_main.c upon which
> some of the code seems to be based.
Yes. some of the code is based on bonding/team and netvsc. i added a reference
to netvsc in the comment, will also include bonding/team driver.
>
>> +
>> +/* A common module to handle registrations and notifications for paravirtual
>> + * drivers to enable accelerated datapath and support VF live migration.
>> + *
>> + * The notifier and event handling code is based on netvsc driver.
>> + */
>> +
>> +#include <linux/netdevice.h>
>> +#include <linux/etherdevice.h>
>> +#include <linux/ethtool.h>
>> +#include <linux/module.h>
>> +#include <linux/slab.h>
>> +#include <linux/netdevice.h>
>> +#include <linux/netpoll.h>
>> +#include <linux/rtnetlink.h>
>> +#include <linux/if_vlan.h>
>> +#include <linux/pci.h>
>> +#include <net/sch_generic.h>
>> +#include <uapi/linux/if_arp.h>
>> +#include <net/failover.h>
>> +
>> +static LIST_HEAD(failover_list);
>> +static DEFINE_SPINLOCK(failover_lock);
>> +
>> +static int failover_slave_pre_register(struct net_device *slave_dev,
>> + struct net_device *failover_dev,
>> + struct failover_ops *failover_ops)
>> +{
>> + struct failover_info *finfo;
>> + bool standby;
>> +
>> + if (failover_ops) {
>> + if (!failover_ops->slave_pre_register)
>> + return -EINVAL;
>> +
>> + return failover_ops->slave_pre_register(slave_dev,
>> + failover_dev);
>> + }
>> +
>> + finfo = netdev_priv(failover_dev);
>> + standby = (slave_dev->dev.parent == failover_dev->dev.parent);
>> + if (standby ? rtnl_dereference(finfo->standby_dev) :
>> + rtnl_dereference(finfo->primary_dev)) {
>> + netdev_err(failover_dev, "%s attempting to register as slave dev when %s already present\n",
>> + slave_dev->name, standby ? "standby" : "primary");
>> + return -EEXIST;
>> + }
>> +
>> + /* Avoid non pci devices as primary netdev */
> Why? Pls change this comment so it explains the motivation
> rather than just repeat what the code does.
OK.
>
>> + if (!standby && (!slave_dev->dev.parent ||
>> + !dev_is_pci(slave_dev->dev.parent)))
>> + return -EINVAL;
>> +
>> + return 0;
>> +}
>> +
>> +static int failover_slave_join(struct net_device *slave_dev,
>> + struct net_device *failover_dev,
>> + struct failover_ops *failover_ops)
>> +{
>> + struct failover_info *finfo;
>> + int err, orig_mtu;
>> + bool standby;
>> +
>> + if (failover_ops) {
>> + if (!failover_ops->slave_join)
>> + return -EINVAL;
>> +
>> + return failover_ops->slave_join(slave_dev, failover_dev);
>> + }
>> +
>> + if (netif_running(failover_dev)) {
>> + err = dev_open(slave_dev);
>> + if (err && (err != -EBUSY)) {
>> + netdev_err(failover_dev, "Opening slave %s failed err:%d\n",
>> + slave_dev->name, err);
>> + goto err_dev_open;
>> + }
>> + }
>> +
>> + /* Align MTU of slave with failover dev */
>> + orig_mtu = slave_dev->mtu;
> I suspect this was copied from bond. this variable is never
> used and I'm even surprised gcc did not warn about this.
Thanks for catching, I broke this when i moved the dev_open() and dev_set_mtu()
calls from register to join. I need to reset slave_dev mtu to orig_mtu on failure.
>
>
>> + err = dev_set_mtu(slave_dev, failover_dev->mtu);
> How do we know slave supports this MTU? same applies to
> failover_change_mtu.
The err check below should catch it and we will reset the mtu back and
fail the join/register.
>
>
>
>
>> + if (err) {
>> + netdev_err(failover_dev, "unable to change mtu of %s to %u register failed\n",
>> + slave_dev->name, failover_dev->mtu);
>> + goto err_set_mtu;
>> + }
>> +
>> + finfo = netdev_priv(failover_dev);
>> + standby = (slave_dev->dev.parent == failover_dev->dev.parent);
>> +
>> + dev_hold(slave_dev);
>> +
>> + if (standby) {
>> + rcu_assign_pointer(finfo->standby_dev, slave_dev);
>> + dev_get_stats(finfo->standby_dev, &finfo->standby_stats);
>> + } else {
>> + rcu_assign_pointer(finfo->primary_dev, slave_dev);
>> + dev_get_stats(finfo->primary_dev, &finfo->primary_stats);
>> + failover_dev->min_mtu = slave_dev->min_mtu;
>> + failover_dev->max_mtu = slave_dev->max_mtu;
>> + }
>> +
>> + netdev_info(failover_dev, "failover slave:%s joined\n",
>> + slave_dev->name);
>> +
>> + return 0;
>> +
>> +err_set_mtu:
>> + dev_close(slave_dev);
>> +err_dev_open:
>> + return err;
>> +}
>> +
>> +/* Called when slave dev is injecting data into network stack.
>> + * Change the associated network device from lower dev to virtio.
>> + * note: already called with rcu_read_lock
>> + */
>> +static rx_handler_result_t failover_handle_frame(struct sk_buff **pskb)
>> +{
>> + struct sk_buff *skb = *pskb;
>> + struct net_device *ndev = rcu_dereference(skb->dev->rx_handler_data);
>> +
>> + skb->dev = ndev;
>> +
>> + return RX_HANDLER_ANOTHER;
>> +}
>> +
>> +static struct net_device *failover_get_bymac(u8 *mac, struct failover_ops **ops)
>> +{
>> + struct net_device *failover_dev;
>> + struct failover *failover;
>> +
>> + spin_lock(&failover_lock);
>> + list_for_each_entry(failover, &failover_list, list) {
>> + failover_dev = rtnl_dereference(failover->failover_dev);
>> + if (ether_addr_equal(failover_dev->perm_addr, mac)) {
>> + *ops = rtnl_dereference(failover->ops);
>> + spin_unlock(&failover_lock);
>> + return failover_dev;
>> + }
>> + }
>> + spin_unlock(&failover_lock);
>> + return NULL;
>> +}
>> +
>> +static int failover_slave_register(struct net_device *slave_dev)
>> +{
>> + struct failover_ops *failover_ops;
>> + struct net_device *failover_dev;
>> + int ret;
>> +
>> + ASSERT_RTNL();
>> +
>> + failover_dev = failover_get_bymac(slave_dev->perm_addr, &failover_ops);
>> + if (!failover_dev)
>> + goto done;
>> +
>> + ret = failover_slave_pre_register(slave_dev, failover_dev,
>> + failover_ops);
>> + if (ret)
>> + goto done;
>> +
>> + ret = netdev_rx_handler_register(slave_dev, failover_ops ?
>> + failover_ops->handle_frame :
>> + failover_handle_frame, failover_dev);
>> + if (ret) {
>> + netdev_err(slave_dev, "can not register failover rx handler (err = %d)\n",
>> + ret);
>> + goto done;
>> + }
>> +
>> + ret = netdev_upper_dev_link(slave_dev, failover_dev, NULL);
>> + if (ret) {
>> + netdev_err(slave_dev, "can not set failover device %s (err = %d)\n",
>> + failover_dev->name, ret);
>> + goto upper_link_failed;
>> + }
>> +
>> + slave_dev->priv_flags |= IFF_FAILOVER_SLAVE;
>> +
>> + ret = failover_slave_join(slave_dev, failover_dev, failover_ops);
>> + if (ret)
>> + goto err_join;
>> +
>> + call_netdevice_notifiers(NETDEV_JOIN, slave_dev);
>> +
>> + netdev_info(failover_dev, "failover slave:%s registered\n",
>> + slave_dev->name);
>> +
>> + goto done;
>> +
>> +err_join:
>> + netdev_upper_dev_unlink(slave_dev, failover_dev);
>> + slave_dev->priv_flags &= ~IFF_FAILOVER_SLAVE;
>> +upper_link_failed:
>> + netdev_rx_handler_unregister(slave_dev);
>> +done:
>> + return NOTIFY_DONE;
>> +}
>> +
>> +static int failover_slave_pre_unregister(struct net_device *slave_dev,
>> + struct net_device *failover_dev,
>> + struct failover_ops *failover_ops)
>> +{
>> + struct net_device *standby_dev, *primary_dev;
>> + struct failover_info *finfo;
>> +
>> + if (failover_ops) {
>> + if (!failover_ops->slave_pre_unregister)
>> + return -EINVAL;
>> +
>> + return failover_ops->slave_pre_unregister(slave_dev,
>> + failover_dev);
>> + }
>> +
>> + finfo = netdev_priv(failover_dev);
>> + primary_dev = rtnl_dereference(finfo->primary_dev);
>> + standby_dev = rtnl_dereference(finfo->standby_dev);
>> +
>> + if (slave_dev != primary_dev && slave_dev != standby_dev)
>> + return -EINVAL;
>> +
>> + return 0;
>> +}
>> +
>> +static int failover_slave_release(struct net_device *slave_dev,
>> + struct net_device *failover_dev,
>> + struct failover_ops *failover_ops)
>> +{
>> + struct net_device *standby_dev, *primary_dev;
>> + struct failover_info *finfo;
>> +
>> + if (failover_ops) {
>> + if (!failover_ops->slave_release)
>> + return -EINVAL;
>> +
>> + return failover_ops->slave_release(slave_dev, failover_dev);
>> + }
>> +
>> + finfo = netdev_priv(failover_dev);
>> + primary_dev = rtnl_dereference(finfo->primary_dev);
>> + standby_dev = rtnl_dereference(finfo->standby_dev);
>> +
>> + if (slave_dev == standby_dev) {
>> + RCU_INIT_POINTER(finfo->standby_dev, NULL);
>> + } else {
>> + RCU_INIT_POINTER(finfo->primary_dev, NULL);
>> + if (standby_dev) {
>> + failover_dev->min_mtu = standby_dev->min_mtu;
>> + failover_dev->max_mtu = standby_dev->max_mtu;
>> + }
>> + }
>> +
>> + dev_put(slave_dev);
>> +
>> + netdev_info(failover_dev, "failover slave:%s released\n",
>> + slave_dev->name);
>> +
>> + return 0;
>> +}
>> +
>> +int failover_slave_unregister(struct net_device *slave_dev)
>> +{
>> + struct failover_ops *failover_ops;
>> + struct net_device *failover_dev;
>> + int ret;
>> +
>> + if (!netif_is_failover_slave(slave_dev))
>> + goto done;
>> +
>> + ASSERT_RTNL();
>> +
>> + failover_dev = failover_get_bymac(slave_dev->perm_addr, &failover_ops);
>> + if (!failover_dev)
>> + goto done;
>> +
>> + ret = failover_slave_pre_unregister(slave_dev, failover_dev,
>> + failover_ops);
>> + if (ret)
>> + goto done;
>> +
>> + netdev_rx_handler_unregister(slave_dev);
>> + netdev_upper_dev_unlink(slave_dev, failover_dev);
>> + slave_dev->priv_flags &= ~IFF_FAILOVER_SLAVE;
>> +
>> + failover_slave_release(slave_dev, failover_dev, failover_ops);
>
> Don't you need to get stats from it? This device is going away ...
Yes. we need to update the failover_stats before the slave goes away.
>
>> +
>> + netdev_info(failover_dev, "failover slave:%s unregistered\n",
>> + slave_dev->name);
>> +
>> +done:
>> + return NOTIFY_DONE;
>> +}
>> +EXPORT_SYMBOL_GPL(failover_slave_unregister);
>> +
>> +static bool failover_xmit_ready(struct net_device *dev)
>> +{
>> + return netif_running(dev) && netif_carrier_ok(dev);
>> +}
>> +
>> +static int failover_slave_link_change(struct net_device *slave_dev)
>> +{
>> + struct net_device *failover_dev, *primary_dev, *standby_dev;
>> + struct failover_ops *failover_ops;
>> + struct failover_info *finfo;
>> +
>> + if (!netif_is_failover_slave(slave_dev))
>> + goto done;
>> +
>> + ASSERT_RTNL();
>> +
>> + failover_dev = failover_get_bymac(slave_dev->perm_addr, &failover_ops);
>> + if (!failover_dev)
>> + goto done;
>> +
>> + if (failover_ops) {
>> + if (!failover_ops->slave_link_change)
>> + goto done;
>> +
>> + return failover_ops->slave_link_change(slave_dev, failover_dev);
>> + }
>> +
>> + if (!netif_running(failover_dev))
>> + return 0;
>> +
>> + finfo = netdev_priv(failover_dev);
>> +
>> + primary_dev = rtnl_dereference(finfo->primary_dev);
>> + standby_dev = rtnl_dereference(finfo->standby_dev);
>> +
>> + if (slave_dev != primary_dev && slave_dev != standby_dev)
>> + goto done;
>> +
>> + if ((primary_dev && failover_xmit_ready(primary_dev)) ||
>> + (standby_dev && failover_xmit_ready(standby_dev))) {
>> + netif_carrier_on(failover_dev);
>> + netif_tx_wake_all_queues(failover_dev);
>> + } else {
>> + netif_carrier_off(failover_dev);
>> + netif_tx_stop_all_queues(failover_dev);
> And I think it's a good idea to get stats from device here too.
Not sure why we need to get stats from lower devs here?
>
>
>> + }
>> +
>> +done:
>> + return NOTIFY_DONE;
>> +}
>> +
>> +static bool failover_validate_event_dev(struct net_device *dev)
>> +{
>> + /* Skip parent events */
>> + if (netif_is_failover(dev))
>> + return false;
>> +
>> + /* Avoid non-Ethernet type devices */
> ... for now. It would be possible easy to make this generic -
> just copy things like type and addr_len from slave.
ok. failover_create can copy these values from standby_dev and
we can validate that they match when primary_dev registers.
>
>> + if (dev->type != ARPHRD_ETHER)
>> + return false;
>> +
>> + return true;
>> +}
>> +
>> +static int
>> +failover_event(struct notifier_block *this, unsigned long event, void *ptr)
>> +{
>> + struct net_device *event_dev = netdev_notifier_info_to_dev(ptr);
>> +
>> + if (!failover_validate_event_dev(event_dev))
>> + return NOTIFY_DONE;
>> +
>> + switch (event) {
>> + case NETDEV_REGISTER:
>> + return failover_slave_register(event_dev);
>> + case NETDEV_UNREGISTER:
>> + return failover_slave_unregister(event_dev);
>> + case NETDEV_UP:
>> + case NETDEV_DOWN:
>> + case NETDEV_CHANGE:
>> + return failover_slave_link_change(event_dev);
>> + default:
>> + return NOTIFY_DONE;
>> + }
>> +}
>> +
>> +static struct notifier_block failover_notifier = {
>> + .notifier_call = failover_event,
>> +};
>> +
>> +static int failover_open(struct net_device *dev)
>> +{
>> + struct failover_info *finfo = netdev_priv(dev);
>> + struct net_device *primary_dev, *standby_dev;
>> + int err;
>> +
>> + netif_carrier_off(dev);
>> + netif_tx_wake_all_queues(dev);
>> +
>> + primary_dev = rtnl_dereference(finfo->primary_dev);
>> + if (primary_dev) {
>> + err = dev_open(primary_dev);
>> + if (err)
>> + goto err_primary_open;
>> + }
>> +
>> + standby_dev = rtnl_dereference(finfo->standby_dev);
>> + if (standby_dev) {
>> + err = dev_open(standby_dev);
>> + if (err)
>> + goto err_standby_open;
>> + }
>> +
>> + return 0;
>> +
>> +err_standby_open:
>> + dev_close(primary_dev);
>> +err_primary_open:
>> + netif_tx_disable(dev);
>> + return err;
>> +}
>> +
>> +static int failover_close(struct net_device *dev)
>> +{
>> + struct failover_info *finfo = netdev_priv(dev);
>> + struct net_device *slave_dev;
>> +
>> + netif_tx_disable(dev);
>> +
>> + slave_dev = rtnl_dereference(finfo->primary_dev);
>> + if (slave_dev)
>> + dev_close(slave_dev);
>> +
>> + slave_dev = rtnl_dereference(finfo->standby_dev);
>> + if (slave_dev)
>> + dev_close(slave_dev);
>> +
>> + return 0;
>> +}
>> +
>> +static netdev_tx_t failover_drop_xmit(struct sk_buff *skb,
>> + struct net_device *dev)
>> +{
>> + atomic_long_inc(&dev->tx_dropped);
>> + dev_kfree_skb_any(skb);
>> + return NETDEV_TX_OK;
>> +}
>> +
>> +static netdev_tx_t failover_start_xmit(struct sk_buff *skb,
>> + struct net_device *dev)
>> +{
>> + struct failover_info *finfo = netdev_priv(dev);
>> + struct net_device *xmit_dev;
>> +
>> + /* Try xmit via primary netdev followed by standby netdev */
>> + xmit_dev = rcu_dereference_bh(finfo->primary_dev);
>> + if (!xmit_dev || !failover_xmit_ready(xmit_dev)) {
>> + xmit_dev = rcu_dereference_bh(finfo->standby_dev);
>> + if (!xmit_dev || !failover_xmit_ready(xmit_dev))
>> + return failover_drop_xmit(skb, dev);
>> + }
>> +
>> + skb->dev = xmit_dev;
>> + skb->queue_mapping = qdisc_skb_cb(skb)->slave_dev_queue_mapping;
>> +
>> + return dev_queue_xmit(skb);
>> +}
> Is this going through qdisc twice? Won't this hurt performance
> measureably?
The failover dev has no queue (IFF_NO_QUEUE) , so doesn't go through qdisc twice.
>
>> +
>> +static u16 failover_select_queue(struct net_device *dev, struct sk_buff *skb,
>> + void *accel_priv,
>> + select_queue_fallback_t fallback)
>> +{
>> + struct failover_info *finfo = netdev_priv(dev);
>> + struct net_device *primary_dev;
>> + u16 txq;
>> +
>> + rcu_read_lock();
>> + primary_dev = rcu_dereference(finfo->primary_dev);
>> + if (primary_dev) {
>> + const struct net_device_ops *ops = primary_dev->netdev_ops;
>> +
>> + if (ops->ndo_select_queue)
>> + txq = ops->ndo_select_queue(primary_dev, skb,
>> + accel_priv, fallback);
>> + else
>> + txq = fallback(primary_dev, skb);
>> +
>> + qdisc_skb_cb(skb)->slave_dev_queue_mapping = skb->queue_mapping;
>> +
>> + return txq;
>> + }
>> +
>> + txq = skb_rx_queue_recorded(skb) ? skb_get_rx_queue(skb) : 0;
>> +
>> + /* Save the original txq to restore before passing to the driver */
>> + qdisc_skb_cb(skb)->slave_dev_queue_mapping = skb->queue_mapping;
>> +
>> + if (unlikely(txq >= dev->real_num_tx_queues)) {
>> + do {
>> + txq -= dev->real_num_tx_queues;
>> + } while (txq >= dev->real_num_tx_queues);
>> + }
>> +
>> + return txq;
>> +}
>> +
>> +/* fold stats, assuming all rtnl_link_stats64 fields are u64, but
>> + * that some drivers can provide 32finfot values only.
>> + */
>> +static void failover_fold_stats(struct rtnl_link_stats64 *_res,
>> + const struct rtnl_link_stats64 *_new,
>> + const struct rtnl_link_stats64 *_old)
>> +{
>> + const u64 *new = (const u64 *)_new;
>> + const u64 *old = (const u64 *)_old;
>> + u64 *res = (u64 *)_res;
>> + int i;
>> +
>> + for (i = 0; i < sizeof(*_res) / sizeof(u64); i++) {
>> + u64 nv = new[i];
>> + u64 ov = old[i];
>> + s64 delta = nv - ov;
>> +
>> + /* detects if this particular field is 32bit only */
>> + if (((nv | ov) >> 32) == 0)
>> + delta = (s64)(s32)((u32)nv - (u32)ov);
>> +
>> + /* filter anomalies, some drivers reset their stats
>> + * at down/up events.
>> + */
>> + if (delta > 0)
>> + res[i] += delta;
>> + }
>> +}
>> +
>> +static void failover_get_stats(struct net_device *dev,
>> + struct rtnl_link_stats64 *stats)
>> +{
>> + struct failover_info *finfo = netdev_priv(dev);
>> + const struct rtnl_link_stats64 *new;
>> + struct rtnl_link_stats64 temp;
>> + struct net_device *slave_dev;
>> +
>> + spin_lock(&finfo->stats_lock);
>> + memcpy(stats, &finfo->failover_stats, sizeof(*stats));
>> +
>> + rcu_read_lock();
>> +
>> + slave_dev = rcu_dereference(finfo->primary_dev);
>> + if (slave_dev) {
>> + new = dev_get_stats(slave_dev, &temp);
>> + failover_fold_stats(stats, new, &finfo->primary_stats);
>> + memcpy(&finfo->primary_stats, new, sizeof(*new));
>> + }
>> +
>> + slave_dev = rcu_dereference(finfo->standby_dev);
>> + if (slave_dev) {
>> + new = dev_get_stats(slave_dev, &temp);
>> + failover_fold_stats(stats, new, &finfo->standby_stats);
>> + memcpy(&finfo->standby_stats, new, sizeof(*new));
>> + }
>> +
>> + rcu_read_unlock();
>> +
>> + memcpy(&finfo->failover_stats, stats, sizeof(*stats));
>> + spin_unlock(&finfo->stats_lock);
>> +}
>> +
>> +static int failover_change_mtu(struct net_device *dev, int new_mtu)
>> +{
>> + struct failover_info *finfo = netdev_priv(dev);
>> + struct net_device *primary_dev, *standby_dev;
>> + int ret = 0;
>> +
>> + primary_dev = rcu_dereference(finfo->primary_dev);
>> + if (primary_dev) {
>> + ret = dev_set_mtu(primary_dev, new_mtu);
>> + if (ret)
>> + return ret;
>> + }
>> +
>> + standby_dev = rcu_dereference(finfo->standby_dev);
>> + if (standby_dev) {
>> + ret = dev_set_mtu(standby_dev, new_mtu);
>> + if (ret) {
>> + dev_set_mtu(primary_dev, dev->mtu);
>> + return ret;
>> + }
>> + }
>> +
>> + dev->mtu = new_mtu;
>> + return 0;
>> +}
>> +
>> +static void failover_set_rx_mode(struct net_device *dev)
>> +{
>> + struct failover_info *finfo = netdev_priv(dev);
>> + struct net_device *slave_dev;
>> +
>> + rcu_read_lock();
>> +
>> + slave_dev = rcu_dereference(finfo->primary_dev);
>> + if (slave_dev) {
>> + dev_uc_sync_multiple(slave_dev, dev);
>> + dev_mc_sync_multiple(slave_dev, dev);
>> + }
>> +
>> + slave_dev = rcu_dereference(finfo->standby_dev);
>> + if (slave_dev) {
>> + dev_uc_sync_multiple(slave_dev, dev);
>> + dev_mc_sync_multiple(slave_dev, dev);
>> + }
>> +
>> + rcu_read_unlock();
>> +}
>> +
>> +static const struct net_device_ops failover_dev_ops = {
>> + .ndo_open = failover_open,
>> + .ndo_stop = failover_close,
>> + .ndo_start_xmit = failover_start_xmit,
>> + .ndo_select_queue = failover_select_queue,
>> + .ndo_get_stats64 = failover_get_stats,
>> + .ndo_change_mtu = failover_change_mtu,
>> + .ndo_set_rx_mode = failover_set_rx_mode,
>> + .ndo_validate_addr = eth_validate_addr,
>> + .ndo_features_check = passthru_features_check,
> xdp support?
I think it should be possible to add it be calling the lower dev ndo_xdp routines
with proper checks. can we add this later?
>
>> +};
>> +
>> +#define FAILOVER_NAME "failover"
>> +#define FAILOVER_VERSION "0.1"
>> +
>> +static void failover_ethtool_get_drvinfo(struct net_device *dev,
>> + struct ethtool_drvinfo *drvinfo)
>> +{
>> + strlcpy(drvinfo->driver, FAILOVER_NAME, sizeof(drvinfo->driver));
>> + strlcpy(drvinfo->version, FAILOVER_VERSION, sizeof(drvinfo->version));
>> +}
>> +
>> +int failover_ethtool_get_link_ksettings(struct net_device *dev,
>> + struct ethtool_link_ksettings *cmd)
>> +{
>> + struct failover_info *finfo = netdev_priv(dev);
>> + struct net_device *slave_dev;
>> +
>> + slave_dev = rtnl_dereference(finfo->primary_dev);
>> + if (!slave_dev || !failover_xmit_ready(slave_dev)) {
>> + slave_dev = rtnl_dereference(finfo->standby_dev);
>> + if (!slave_dev || !failover_xmit_ready(slave_dev)) {
>> + cmd->base.duplex = DUPLEX_UNKNOWN;
>> + cmd->base.port = PORT_OTHER;
>> + cmd->base.speed = SPEED_UNKNOWN;
>> +
>> + return 0;
>> + }
>> + }
>> +
>> + return __ethtool_get_link_ksettings(slave_dev, cmd);
>> +}
>> +EXPORT_SYMBOL_GPL(failover_ethtool_get_link_ksettings);
>> +
>> +static const struct ethtool_ops failover_ethtool_ops = {
>> + .get_drvinfo = failover_ethtool_get_drvinfo,
>> + .get_link = ethtool_op_get_link,
>> + .get_link_ksettings = failover_ethtool_get_link_ksettings,
>> +};
>> +
>> +static void failover_register_existing_slave(struct net_device *failover_dev)
>> +{
>> + struct net *net = dev_net(failover_dev);
>> + struct net_device *dev;
>> +
>> + rtnl_lock();
>> + for_each_netdev(net, dev) {
>> + if (dev == failover_dev)
>> + continue;
>> + if (!failover_validate_event_dev(dev))
>> + continue;
>> + if (ether_addr_equal(failover_dev->perm_addr, dev->perm_addr))
>> + failover_slave_register(dev);
>> + }
>> + rtnl_unlock();
>> +}
>> +
>> +int failover_register(struct net_device *dev, struct failover_ops *ops,
>> + struct failover **pfailover)
>> +{
>> + struct failover *failover;
>> +
>> + failover = kzalloc(sizeof(*failover), GFP_KERNEL);
>> + if (!failover)
>> + return -ENOMEM;
>> +
>> + rcu_assign_pointer(failover->ops, ops);
>> + dev_hold(dev);
>> + dev->priv_flags |= IFF_FAILOVER;
>> + rcu_assign_pointer(failover->failover_dev, dev);
>> +
>> + spin_lock(&failover_lock);
>> + list_add_tail(&failover->list, &failover_list);
>> + spin_unlock(&failover_lock);
>> +
>> + failover_register_existing_slave(dev);
>> +
>> + *pfailover = failover;
>> + return 0;
>> +}
>> +EXPORT_SYMBOL_GPL(failover_register);
>> +
>> +void failover_unregister(struct failover *failover)
>> +{
>> + struct net_device *failover_dev;
>> +
>> + failover_dev = rcu_dereference(failover->failover_dev);
>> +
>> + failover_dev->priv_flags &= ~IFF_FAILOVER;
>> + dev_put(failover_dev);
>> +
>> + spin_lock(&failover_lock);
>> + list_del(&failover->list);
>> + spin_unlock(&failover_lock);
>> +
>> + kfree(failover);
>> +}
>> +EXPORT_SYMBOL_GPL(failover_unregister);
>> +
>> +int failover_create(struct net_device *standby_dev, struct failover **pfailover)
>> +{
>> + struct device *dev = standby_dev->dev.parent;
>> + struct net_device *failover_dev;
>> + int err;
>> +
>> + /* Alloc at least 2 queues, for now we are going with 16 assuming
>> + * that most devices being bonded won't have too many queues.
>> + */
>> + failover_dev = alloc_etherdev_mq(sizeof(struct failover_info), 16);
>> + if (!failover_dev) {
>> + dev_err(dev, "Unable to allocate failover_netdev!\n");
>> + return -ENOMEM;
>> + }
>> +
>> + dev_net_set(failover_dev, dev_net(standby_dev));
>> + SET_NETDEV_DEV(failover_dev, dev);
>> +
>> + failover_dev->netdev_ops = &failover_dev_ops;
>> + failover_dev->ethtool_ops = &failover_ethtool_ops;
>> +
>> + /* Initialize the device options */
>> + failover_dev->priv_flags |= IFF_UNICAST_FLT | IFF_NO_QUEUE;
>> + failover_dev->priv_flags &= ~(IFF_XMIT_DST_RELEASE |
>> + IFF_TX_SKB_SHARING);
>> +
>> + /* don't acquire failover netdev's netif_tx_lock when transmitting */
>> + failover_dev->features |= NETIF_F_LLTX;
>> +
>> + /* Don't allow failover devices to change network namespaces. */
>> + failover_dev->features |= NETIF_F_NETNS_LOCAL;
>> +
>> + failover_dev->hw_features = NETIF_F_HW_CSUM | NETIF_F_SG |
>> + NETIF_F_FRAGLIST | NETIF_F_ALL_TSO |
>> + NETIF_F_HIGHDMA | NETIF_F_LRO;
> OK but then you must make sure your primary and standby both
> support these features.
I guess i need to add something like bond_compute_features() to handle this.
>
>> +
>> + failover_dev->hw_features |= NETIF_F_GSO_ENCAP_ALL;
>> + failover_dev->features |= failover_dev->hw_features;
>> +
>> + memcpy(failover_dev->dev_addr, standby_dev->dev_addr,
>> + failover_dev->addr_len);
>> +
>> + failover_dev->min_mtu = standby_dev->min_mtu;
>> + failover_dev->max_mtu = standby_dev->max_mtu;
> OK MTU is copied, fine. But is this always enough?
>
> How about e.g. hard_header_len? min_header_len? needed_headroom?
> needed_tailroom? I'd worry that even if you cover existing ones more
> might be added with time. A function copying config between devices
> probably belongs in some central place IMHO.
ok. will add a function that handles these fields too.
>
>
>> +
>> + err = register_netdev(failover_dev);
>> + if (err < 0) {
>> + dev_err(dev, "Unable to register failover_dev!\n");
>> + goto err_register_netdev;
>> + }
>> +
>> + netif_carrier_off(failover_dev);
>> +
>> + err = failover_register(failover_dev, NULL, pfailover);
>> + if (err < 0)
>> + goto err_failover;
>> +
>> + return 0;
>> +
>> +err_failover:
>> + unregister_netdev(failover_dev);
>> +err_register_netdev:
>> + free_netdev(failover_dev);
>> +
>> + return err;
>> +}
>> +EXPORT_SYMBOL_GPL(failover_create);
>> +
>> +void failover_destroy(struct failover *failover)
>> +{
>> + struct net_device *failover_dev;
>> + struct net_device *slave_dev;
>> + struct failover_info *finfo;
>> +
>> + if (!failover)
>> + return;
>> +
>> + failover_dev = rcu_dereference(failover->failover_dev);
>> + finfo = netdev_priv(failover_dev);
>> +
>> + netif_device_detach(failover_dev);
>> +
>> + rtnl_lock();
>> +
>> + slave_dev = rtnl_dereference(finfo->primary_dev);
>> + if (slave_dev)
>> + failover_slave_unregister(slave_dev);
>> +
>> + slave_dev = rtnl_dereference(finfo->standby_dev);
>> + if (slave_dev)
>> + failover_slave_unregister(slave_dev);
>> +
>> + failover_unregister(failover);
>> +
>> + unregister_netdevice(failover_dev);
>> +
>> + rtnl_unlock();
>> +
>> + free_netdev(failover_dev);
>> +}
>> +EXPORT_SYMBOL_GPL(failover_destroy);
>> +
>> +static __init int
>> +failover_init(void)
>> +{
>> + register_netdevice_notifier(&failover_notifier);
>> +
>> + return 0;
>> +}
>> +module_init(failover_init);
>> +
>> +static __exit
>> +void failover_exit(void)
>> +{
>> + unregister_netdevice_notifier(&failover_notifier);
>> +}
>> +module_exit(failover_exit);
>> +
>> +MODULE_DESCRIPTION("Failover infrastructure/interface for Paravirtual drivers");
>> +MODULE_LICENSE("GPL v2");
>> --
>> 2.14.3
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 net-next 4/4] netvsc: refactor notifier/event handling code to use the failover framework
2018-04-20 1:42 ` [virtio-dev] " Sridhar Samudrala
(?)
@ 2018-04-20 15:28 ` Stephen Hemminger
2018-04-20 15:43 ` Michael S. Tsirkin
` (7 more replies)
-1 siblings, 8 replies; 114+ messages in thread
From: Stephen Hemminger @ 2018-04-20 15:28 UTC (permalink / raw)
To: Sridhar Samudrala
Cc: mst, davem, netdev, virtualization, virtio-dev, jesse.brandeburg,
alexander.h.duyck, kubakici, jasowang, loseweigh, jiri
On Thu, 19 Apr 2018 18:42:04 -0700
Sridhar Samudrala <sridhar.samudrala@intel.com> wrote:
> Use the registration/notification framework supported by the generic
> failover infrastructure.
>
> Signed-off-by: Sridhar Samudrala <sridhar.samudrala@intel.com>
Do what you want to other devices but leave netvsc alone.
Adding these failover ops does not reduce the code size, and really is
no benefit. The netvsc device driver needs to be backported to several
other distributions and doing this makes that harder.
I will NAK patches to change to common code for netvsc especially the
three device model. MS worked hard with distro vendors to support transparent
mode, ans we really can't have a new model; or do backport.
Plus, DPDK is now dependent on existing model.
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 net-next 4/4] netvsc: refactor notifier/event handling code to use the failover framework
2018-04-20 1:42 ` [virtio-dev] " Sridhar Samudrala
(?)
(?)
@ 2018-04-20 15:28 ` Stephen Hemminger
-1 siblings, 0 replies; 114+ messages in thread
From: Stephen Hemminger @ 2018-04-20 15:28 UTC (permalink / raw)
To: Sridhar Samudrala
Cc: alexander.h.duyck, virtio-dev, jiri, mst, kubakici, netdev,
virtualization, loseweigh, davem
On Thu, 19 Apr 2018 18:42:04 -0700
Sridhar Samudrala <sridhar.samudrala@intel.com> wrote:
> Use the registration/notification framework supported by the generic
> failover infrastructure.
>
> Signed-off-by: Sridhar Samudrala <sridhar.samudrala@intel.com>
Do what you want to other devices but leave netvsc alone.
Adding these failover ops does not reduce the code size, and really is
no benefit. The netvsc device driver needs to be backported to several
other distributions and doing this makes that harder.
I will NAK patches to change to common code for netvsc especially the
three device model. MS worked hard with distro vendors to support transparent
mode, ans we really can't have a new model; or do backport.
Plus, DPDK is now dependent on existing model.
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 net-next 2/4] net: Introduce generic failover module
2018-04-20 15:21 ` [virtio-dev] " Samudrala, Sridhar
@ 2018-04-20 15:34 ` Michael S. Tsirkin
-1 siblings, 0 replies; 114+ messages in thread
From: Michael S. Tsirkin @ 2018-04-20 15:34 UTC (permalink / raw)
To: Samudrala, Sridhar
Cc: stephen, davem, netdev, virtualization, virtio-dev,
jesse.brandeburg, alexander.h.duyck, kubakici, jasowang,
loseweigh, jiri
On Fri, Apr 20, 2018 at 08:21:00AM -0700, Samudrala, Sridhar wrote:
> > > + finfo = netdev_priv(failover_dev);
> > > +
> > > + primary_dev = rtnl_dereference(finfo->primary_dev);
> > > + standby_dev = rtnl_dereference(finfo->standby_dev);
> > > +
> > > + if (slave_dev != primary_dev && slave_dev != standby_dev)
> > > + goto done;
> > > +
> > > + if ((primary_dev && failover_xmit_ready(primary_dev)) ||
> > > + (standby_dev && failover_xmit_ready(standby_dev))) {
> > > + netif_carrier_on(failover_dev);
> > > + netif_tx_wake_all_queues(failover_dev);
> > > + } else {
> > > + netif_carrier_off(failover_dev);
> > > + netif_tx_stop_all_queues(failover_dev);
> > And I think it's a good idea to get stats from device here too.
>
> Not sure why we need to get stats from lower devs here?
link down is often indication of a hardware problem.
lower dev might stop responding down the road.
> > > +static const struct net_device_ops failover_dev_ops = {
> > > + .ndo_open = failover_open,
> > > + .ndo_stop = failover_close,
> > > + .ndo_start_xmit = failover_start_xmit,
> > > + .ndo_select_queue = failover_select_queue,
> > > + .ndo_get_stats64 = failover_get_stats,
> > > + .ndo_change_mtu = failover_change_mtu,
> > > + .ndo_set_rx_mode = failover_set_rx_mode,
> > > + .ndo_validate_addr = eth_validate_addr,
> > > + .ndo_features_check = passthru_features_check,
> > xdp support?
>
> I think it should be possible to add it be calling the lower dev ndo_xdp routines
> with proper checks. can we add this later?
I'd be concerned that if you don't xdp userspace will keep poking
at lower devs. Then it will stop working if you add this later.
--
MST
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 net-next 2/4] net: Introduce generic failover module
2018-04-20 15:21 ` [virtio-dev] " Samudrala, Sridhar
(?)
@ 2018-04-20 15:34 ` Michael S. Tsirkin
-1 siblings, 0 replies; 114+ messages in thread
From: Michael S. Tsirkin @ 2018-04-20 15:34 UTC (permalink / raw)
To: Samudrala, Sridhar
Cc: alexander.h.duyck, virtio-dev, jiri, kubakici, netdev,
virtualization, loseweigh, davem
On Fri, Apr 20, 2018 at 08:21:00AM -0700, Samudrala, Sridhar wrote:
> > > + finfo = netdev_priv(failover_dev);
> > > +
> > > + primary_dev = rtnl_dereference(finfo->primary_dev);
> > > + standby_dev = rtnl_dereference(finfo->standby_dev);
> > > +
> > > + if (slave_dev != primary_dev && slave_dev != standby_dev)
> > > + goto done;
> > > +
> > > + if ((primary_dev && failover_xmit_ready(primary_dev)) ||
> > > + (standby_dev && failover_xmit_ready(standby_dev))) {
> > > + netif_carrier_on(failover_dev);
> > > + netif_tx_wake_all_queues(failover_dev);
> > > + } else {
> > > + netif_carrier_off(failover_dev);
> > > + netif_tx_stop_all_queues(failover_dev);
> > And I think it's a good idea to get stats from device here too.
>
> Not sure why we need to get stats from lower devs here?
link down is often indication of a hardware problem.
lower dev might stop responding down the road.
> > > +static const struct net_device_ops failover_dev_ops = {
> > > + .ndo_open = failover_open,
> > > + .ndo_stop = failover_close,
> > > + .ndo_start_xmit = failover_start_xmit,
> > > + .ndo_select_queue = failover_select_queue,
> > > + .ndo_get_stats64 = failover_get_stats,
> > > + .ndo_change_mtu = failover_change_mtu,
> > > + .ndo_set_rx_mode = failover_set_rx_mode,
> > > + .ndo_validate_addr = eth_validate_addr,
> > > + .ndo_features_check = passthru_features_check,
> > xdp support?
>
> I think it should be possible to add it be calling the lower dev ndo_xdp routines
> with proper checks. can we add this later?
I'd be concerned that if you don't xdp userspace will keep poking
at lower devs. Then it will stop working if you add this later.
--
MST
^ permalink raw reply [flat|nested] 114+ messages in thread
* [virtio-dev] Re: [PATCH v7 net-next 2/4] net: Introduce generic failover module
@ 2018-04-20 15:34 ` Michael S. Tsirkin
0 siblings, 0 replies; 114+ messages in thread
From: Michael S. Tsirkin @ 2018-04-20 15:34 UTC (permalink / raw)
To: Samudrala, Sridhar
Cc: stephen, davem, netdev, virtualization, virtio-dev,
jesse.brandeburg, alexander.h.duyck, kubakici, jasowang,
loseweigh, jiri
On Fri, Apr 20, 2018 at 08:21:00AM -0700, Samudrala, Sridhar wrote:
> > > + finfo = netdev_priv(failover_dev);
> > > +
> > > + primary_dev = rtnl_dereference(finfo->primary_dev);
> > > + standby_dev = rtnl_dereference(finfo->standby_dev);
> > > +
> > > + if (slave_dev != primary_dev && slave_dev != standby_dev)
> > > + goto done;
> > > +
> > > + if ((primary_dev && failover_xmit_ready(primary_dev)) ||
> > > + (standby_dev && failover_xmit_ready(standby_dev))) {
> > > + netif_carrier_on(failover_dev);
> > > + netif_tx_wake_all_queues(failover_dev);
> > > + } else {
> > > + netif_carrier_off(failover_dev);
> > > + netif_tx_stop_all_queues(failover_dev);
> > And I think it's a good idea to get stats from device here too.
>
> Not sure why we need to get stats from lower devs here?
link down is often indication of a hardware problem.
lower dev might stop responding down the road.
> > > +static const struct net_device_ops failover_dev_ops = {
> > > + .ndo_open = failover_open,
> > > + .ndo_stop = failover_close,
> > > + .ndo_start_xmit = failover_start_xmit,
> > > + .ndo_select_queue = failover_select_queue,
> > > + .ndo_get_stats64 = failover_get_stats,
> > > + .ndo_change_mtu = failover_change_mtu,
> > > + .ndo_set_rx_mode = failover_set_rx_mode,
> > > + .ndo_validate_addr = eth_validate_addr,
> > > + .ndo_features_check = passthru_features_check,
> > xdp support?
>
> I think it should be possible to add it be calling the lower dev ndo_xdp routines
> with proper checks. can we add this later?
I'd be concerned that if you don't xdp userspace will keep poking
at lower devs. Then it will stop working if you add this later.
--
MST
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 net-next 4/4] netvsc: refactor notifier/event handling code to use the failover framework
2018-04-20 15:28 ` Stephen Hemminger
@ 2018-04-20 15:43 ` Michael S. Tsirkin
2018-04-20 15:43 ` [virtio-dev] " Michael S. Tsirkin
` (6 subsequent siblings)
7 siblings, 0 replies; 114+ messages in thread
From: Michael S. Tsirkin @ 2018-04-20 15:43 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Sridhar Samudrala, davem, netdev, virtualization, virtio-dev,
jesse.brandeburg, alexander.h.duyck, kubakici, jasowang,
loseweigh, jiri
On Fri, Apr 20, 2018 at 08:28:02AM -0700, Stephen Hemminger wrote:
> On Thu, 19 Apr 2018 18:42:04 -0700
> Sridhar Samudrala <sridhar.samudrala@intel.com> wrote:
>
> > Use the registration/notification framework supported by the generic
> > failover infrastructure.
> >
> > Signed-off-by: Sridhar Samudrala <sridhar.samudrala@intel.com>
>
> Do what you want to other devices but leave netvsc alone.
> Adding these failover ops does not reduce the code size,
drivers/net/hyperv/Kconfig | 1 +
drivers/net/hyperv/hyperv_net.h | 2 +
drivers/net/hyperv/netvsc_drv.c | 208 ++++++++++------------------------------
3 files changed, 55 insertions(+), 156 deletions(-)
100 lines gone.
> and really is
> no benefit. The netvsc device driver needs to be backported to several
> other distributions and doing this makes that harder.
>
> I will NAK patches to change to common code for netvsc
Wow.
> especially the
> three device model.
AFAIK these patches do not change netvsc to a three device model.
> MS worked hard with distro vendors to support transparent
> mode, ans we really can't have a new model;
That's why Sridhar worked hard to preserve a 2 device model for netvsc.
> or do backport.
>
> Plus, DPDK is now dependent on existing model.
DPDK does the kernel bypass thing, doesn't it? Why does the kernel care?
--
MST
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 net-next 4/4] netvsc: refactor notifier/event handling code to use the failover framework
2018-04-20 15:28 ` Stephen Hemminger
@ 2018-04-20 15:43 ` Michael S. Tsirkin
2018-04-20 15:43 ` [virtio-dev] " Michael S. Tsirkin
` (6 subsequent siblings)
7 siblings, 0 replies; 114+ messages in thread
From: Michael S. Tsirkin @ 2018-04-20 15:43 UTC (permalink / raw)
To: Stephen Hemminger
Cc: alexander.h.duyck, virtio-dev, jiri, kubakici, Sridhar Samudrala,
virtualization, loseweigh, netdev, davem
On Fri, Apr 20, 2018 at 08:28:02AM -0700, Stephen Hemminger wrote:
> On Thu, 19 Apr 2018 18:42:04 -0700
> Sridhar Samudrala <sridhar.samudrala@intel.com> wrote:
>
> > Use the registration/notification framework supported by the generic
> > failover infrastructure.
> >
> > Signed-off-by: Sridhar Samudrala <sridhar.samudrala@intel.com>
>
> Do what you want to other devices but leave netvsc alone.
> Adding these failover ops does not reduce the code size,
drivers/net/hyperv/Kconfig | 1 +
drivers/net/hyperv/hyperv_net.h | 2 +
drivers/net/hyperv/netvsc_drv.c | 208 ++++++++++------------------------------
3 files changed, 55 insertions(+), 156 deletions(-)
100 lines gone.
> and really is
> no benefit. The netvsc device driver needs to be backported to several
> other distributions and doing this makes that harder.
>
> I will NAK patches to change to common code for netvsc
Wow.
> especially the
> three device model.
AFAIK these patches do not change netvsc to a three device model.
> MS worked hard with distro vendors to support transparent
> mode, ans we really can't have a new model;
That's why Sridhar worked hard to preserve a 2 device model for netvsc.
> or do backport.
>
> Plus, DPDK is now dependent on existing model.
DPDK does the kernel bypass thing, doesn't it? Why does the kernel care?
--
MST
^ permalink raw reply [flat|nested] 114+ messages in thread
* [virtio-dev] Re: [PATCH v7 net-next 4/4] netvsc: refactor notifier/event handling code to use the failover framework
@ 2018-04-20 15:43 ` Michael S. Tsirkin
0 siblings, 0 replies; 114+ messages in thread
From: Michael S. Tsirkin @ 2018-04-20 15:43 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Sridhar Samudrala, davem, netdev, virtualization, virtio-dev,
jesse.brandeburg, alexander.h.duyck, kubakici, jasowang,
loseweigh, jiri
On Fri, Apr 20, 2018 at 08:28:02AM -0700, Stephen Hemminger wrote:
> On Thu, 19 Apr 2018 18:42:04 -0700
> Sridhar Samudrala <sridhar.samudrala@intel.com> wrote:
>
> > Use the registration/notification framework supported by the generic
> > failover infrastructure.
> >
> > Signed-off-by: Sridhar Samudrala <sridhar.samudrala@intel.com>
>
> Do what you want to other devices but leave netvsc alone.
> Adding these failover ops does not reduce the code size,
drivers/net/hyperv/Kconfig | 1 +
drivers/net/hyperv/hyperv_net.h | 2 +
drivers/net/hyperv/netvsc_drv.c | 208 ++++++++++------------------------------
3 files changed, 55 insertions(+), 156 deletions(-)
100 lines gone.
> and really is
> no benefit. The netvsc device driver needs to be backported to several
> other distributions and doing this makes that harder.
>
> I will NAK patches to change to common code for netvsc
Wow.
> especially the
> three device model.
AFAIK these patches do not change netvsc to a three device model.
> MS worked hard with distro vendors to support transparent
> mode, ans we really can't have a new model;
That's why Sridhar worked hard to preserve a 2 device model for netvsc.
> or do backport.
>
> Plus, DPDK is now dependent on existing model.
DPDK does the kernel bypass thing, doesn't it? Why does the kernel care?
--
MST
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 net-next 4/4] netvsc: refactor notifier/event handling code to use the failover framework
2018-04-20 15:28 ` Stephen Hemminger
2018-04-20 15:43 ` Michael S. Tsirkin
2018-04-20 15:43 ` [virtio-dev] " Michael S. Tsirkin
@ 2018-04-20 15:46 ` David Miller
2018-04-20 15:46 ` David Miller
` (4 subsequent siblings)
7 siblings, 0 replies; 114+ messages in thread
From: David Miller @ 2018-04-20 15:46 UTC (permalink / raw)
To: stephen
Cc: sridhar.samudrala, mst, netdev, virtualization, virtio-dev,
jesse.brandeburg, alexander.h.duyck, kubakici, jasowang,
loseweigh, jiri
From: Stephen Hemminger <stephen@networkplumber.org>
Date: Fri, 20 Apr 2018 08:28:02 -0700
> On Thu, 19 Apr 2018 18:42:04 -0700
> Sridhar Samudrala <sridhar.samudrala@intel.com> wrote:
>
>> Use the registration/notification framework supported by the generic
>> failover infrastructure.
>>
>> Signed-off-by: Sridhar Samudrala <sridhar.samudrala@intel.com>
>
> Do what you want to other devices but leave netvsc alone.
> Adding these failover ops does not reduce the code size, and really is
> no benefit. The netvsc device driver needs to be backported to several
> other distributions and doing this makes that harder.
>
> I will NAK patches to change to common code for netvsc especially the
> three device model. MS worked hard with distro vendors to support transparent
> mode, ans we really can't have a new model; or do backport.
>
> Plus, DPDK is now dependent on existing model.
Stephen, I understand your situation.
But the result we have now is undesirable and it happened because MS
worked with distro vendors on this rather than the upstream community
and entities with other device with similar needs.
Please next time do the latter rather than the former.
Thank you.
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 net-next 4/4] netvsc: refactor notifier/event handling code to use the failover framework
2018-04-20 15:28 ` Stephen Hemminger
` (2 preceding siblings ...)
2018-04-20 15:46 ` David Miller
@ 2018-04-20 15:46 ` David Miller
2018-04-20 15:46 ` Samudrala, Sridhar
` (3 subsequent siblings)
7 siblings, 0 replies; 114+ messages in thread
From: David Miller @ 2018-04-20 15:46 UTC (permalink / raw)
To: stephen
Cc: alexander.h.duyck, virtio-dev, jiri, mst, kubakici,
sridhar.samudrala, virtualization, loseweigh, netdev
From: Stephen Hemminger <stephen@networkplumber.org>
Date: Fri, 20 Apr 2018 08:28:02 -0700
> On Thu, 19 Apr 2018 18:42:04 -0700
> Sridhar Samudrala <sridhar.samudrala@intel.com> wrote:
>
>> Use the registration/notification framework supported by the generic
>> failover infrastructure.
>>
>> Signed-off-by: Sridhar Samudrala <sridhar.samudrala@intel.com>
>
> Do what you want to other devices but leave netvsc alone.
> Adding these failover ops does not reduce the code size, and really is
> no benefit. The netvsc device driver needs to be backported to several
> other distributions and doing this makes that harder.
>
> I will NAK patches to change to common code for netvsc especially the
> three device model. MS worked hard with distro vendors to support transparent
> mode, ans we really can't have a new model; or do backport.
>
> Plus, DPDK is now dependent on existing model.
Stephen, I understand your situation.
But the result we have now is undesirable and it happened because MS
worked with distro vendors on this rather than the upstream community
and entities with other device with similar needs.
Please next time do the latter rather than the former.
Thank you.
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 net-next 4/4] netvsc: refactor notifier/event handling code to use the failover framework
2018-04-20 15:28 ` Stephen Hemminger
@ 2018-04-20 15:46 ` Samudrala, Sridhar
2018-04-20 15:43 ` [virtio-dev] " Michael S. Tsirkin
` (6 subsequent siblings)
7 siblings, 0 replies; 114+ messages in thread
From: Samudrala, Sridhar @ 2018-04-20 15:46 UTC (permalink / raw)
To: Stephen Hemminger
Cc: mst, davem, netdev, virtualization, virtio-dev, jesse.brandeburg,
alexander.h.duyck, kubakici, jasowang, loseweigh, jiri
On 4/20/2018 8:28 AM, Stephen Hemminger wrote:
> On Thu, 19 Apr 2018 18:42:04 -0700
> Sridhar Samudrala <sridhar.samudrala@intel.com> wrote:
>
>> Use the registration/notification framework supported by the generic
>> failover infrastructure.
>>
>> Signed-off-by: Sridhar Samudrala <sridhar.samudrala@intel.com>
> Do what you want to other devices but leave netvsc alone.
> Adding these failover ops does not reduce the code size, and really is
> no benefit. The netvsc device driver needs to be backported to several
> other distributions and doing this makes that harder.
>
> I will NAK patches to change to common code for netvsc especially the
> three device model. MS worked hard with distro vendors to support transparent
> mode, ans we really can't have a new model; or do backport.
failover_ops are specifically added to support both 2-netdev and 3-netdev models
This patch doesn't change netvsc model. It still keeps its 2-netdev model. From
netvsc, point of view it is just moving some code from netvsc to the failover module
and also i think the eventhandling and getbymac routines are more optimal.
> Plus, DPDK is now dependent on existing model.
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 net-next 4/4] netvsc: refactor notifier/event handling code to use the failover framework
2018-04-20 15:28 ` Stephen Hemminger
` (3 preceding siblings ...)
2018-04-20 15:46 ` David Miller
@ 2018-04-20 15:46 ` Samudrala, Sridhar
2018-04-20 15:46 ` [virtio-dev] " Samudrala, Sridhar
` (2 subsequent siblings)
7 siblings, 0 replies; 114+ messages in thread
From: Samudrala, Sridhar @ 2018-04-20 15:46 UTC (permalink / raw)
To: Stephen Hemminger
Cc: alexander.h.duyck, virtio-dev, jiri, mst, kubakici, netdev,
virtualization, loseweigh, davem
On 4/20/2018 8:28 AM, Stephen Hemminger wrote:
> On Thu, 19 Apr 2018 18:42:04 -0700
> Sridhar Samudrala <sridhar.samudrala@intel.com> wrote:
>
>> Use the registration/notification framework supported by the generic
>> failover infrastructure.
>>
>> Signed-off-by: Sridhar Samudrala <sridhar.samudrala@intel.com>
> Do what you want to other devices but leave netvsc alone.
> Adding these failover ops does not reduce the code size, and really is
> no benefit. The netvsc device driver needs to be backported to several
> other distributions and doing this makes that harder.
>
> I will NAK patches to change to common code for netvsc especially the
> three device model. MS worked hard with distro vendors to support transparent
> mode, ans we really can't have a new model; or do backport.
failover_ops are specifically added to support both 2-netdev and 3-netdev models
This patch doesn't change netvsc model. It still keeps its 2-netdev model. From
netvsc, point of view it is just moving some code from netvsc to the failover module
and also i think the eventhandling and getbymac routines are more optimal.
> Plus, DPDK is now dependent on existing model.
^ permalink raw reply [flat|nested] 114+ messages in thread
* [virtio-dev] Re: [PATCH v7 net-next 4/4] netvsc: refactor notifier/event handling code to use the failover framework
@ 2018-04-20 15:46 ` Samudrala, Sridhar
0 siblings, 0 replies; 114+ messages in thread
From: Samudrala, Sridhar @ 2018-04-20 15:46 UTC (permalink / raw)
To: Stephen Hemminger
Cc: mst, davem, netdev, virtualization, virtio-dev, jesse.brandeburg,
alexander.h.duyck, kubakici, jasowang, loseweigh, jiri
On 4/20/2018 8:28 AM, Stephen Hemminger wrote:
> On Thu, 19 Apr 2018 18:42:04 -0700
> Sridhar Samudrala <sridhar.samudrala@intel.com> wrote:
>
>> Use the registration/notification framework supported by the generic
>> failover infrastructure.
>>
>> Signed-off-by: Sridhar Samudrala <sridhar.samudrala@intel.com>
> Do what you want to other devices but leave netvsc alone.
> Adding these failover ops does not reduce the code size, and really is
> no benefit. The netvsc device driver needs to be backported to several
> other distributions and doing this makes that harder.
>
> I will NAK patches to change to common code for netvsc especially the
> three device model. MS worked hard with distro vendors to support transparent
> mode, ans we really can't have a new model; or do backport.
failover_ops are specifically added to support both 2-netdev and 3-netdev models
This patch doesn't change netvsc model. It still keeps its 2-netdev model. From
netvsc, point of view it is just moving some code from netvsc to the failover module
and also i think the eventhandling and getbymac routines are more optimal.
> Plus, DPDK is now dependent on existing model.
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 net-next 4/4] netvsc: refactor notifier/event handling code to use the failover framework
2018-04-20 15:43 ` [virtio-dev] " Michael S. Tsirkin
(?)
(?)
@ 2018-04-20 15:47 ` David Miller
-1 siblings, 0 replies; 114+ messages in thread
From: David Miller @ 2018-04-20 15:47 UTC (permalink / raw)
To: mst
Cc: stephen, sridhar.samudrala, netdev, virtualization, virtio-dev,
jesse.brandeburg, alexander.h.duyck, kubakici, jasowang,
loseweigh, jiri
From: "Michael S. Tsirkin" <mst@redhat.com>
Date: Fri, 20 Apr 2018 18:43:54 +0300
> On Fri, Apr 20, 2018 at 08:28:02AM -0700, Stephen Hemminger wrote:
>> Plus, DPDK is now dependent on existing model.
>
> DPDK does the kernel bypass thing, doesn't it? Why does the kernel care?
+1
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 net-next 4/4] netvsc: refactor notifier/event handling code to use the failover framework
2018-04-20 15:43 ` [virtio-dev] " Michael S. Tsirkin
(?)
@ 2018-04-20 15:47 ` David Miller
-1 siblings, 0 replies; 114+ messages in thread
From: David Miller @ 2018-04-20 15:47 UTC (permalink / raw)
To: mst
Cc: alexander.h.duyck, virtio-dev, jiri, kubakici, sridhar.samudrala,
virtualization, loseweigh, netdev
From: "Michael S. Tsirkin" <mst@redhat.com>
Date: Fri, 20 Apr 2018 18:43:54 +0300
> On Fri, Apr 20, 2018 at 08:28:02AM -0700, Stephen Hemminger wrote:
>> Plus, DPDK is now dependent on existing model.
>
> DPDK does the kernel bypass thing, doesn't it? Why does the kernel care?
+1
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [virtio-dev] Re: [PATCH v7 net-next 2/4] net: Introduce generic failover module
2018-04-20 15:34 ` [virtio-dev] " Michael S. Tsirkin
@ 2018-04-20 15:56 ` Alexander Duyck
-1 siblings, 0 replies; 114+ messages in thread
From: Alexander Duyck @ 2018-04-20 15:56 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Samudrala, Sridhar, Stephen Hemminger, David Miller, Netdev,
virtualization, virtio-dev, Brandeburg, Jesse, Duyck,
Alexander H, Jakub Kicinski, Jason Wang, Siwei Liu, Jiri Pirko
On Fri, Apr 20, 2018 at 8:34 AM, Michael S. Tsirkin <mst@redhat.com> wrote:
> On Fri, Apr 20, 2018 at 08:21:00AM -0700, Samudrala, Sridhar wrote:
>> > > + finfo = netdev_priv(failover_dev);
>> > > +
>> > > + primary_dev = rtnl_dereference(finfo->primary_dev);
>> > > + standby_dev = rtnl_dereference(finfo->standby_dev);
>> > > +
>> > > + if (slave_dev != primary_dev && slave_dev != standby_dev)
>> > > + goto done;
>> > > +
>> > > + if ((primary_dev && failover_xmit_ready(primary_dev)) ||
>> > > + (standby_dev && failover_xmit_ready(standby_dev))) {
>> > > + netif_carrier_on(failover_dev);
>> > > + netif_tx_wake_all_queues(failover_dev);
>> > > + } else {
>> > > + netif_carrier_off(failover_dev);
>> > > + netif_tx_stop_all_queues(failover_dev);
>> > And I think it's a good idea to get stats from device here too.
>>
>> Not sure why we need to get stats from lower devs here?
>
> link down is often indication of a hardware problem.
> lower dev might stop responding down the road.
>
>> > > +static const struct net_device_ops failover_dev_ops = {
>> > > + .ndo_open = failover_open,
>> > > + .ndo_stop = failover_close,
>> > > + .ndo_start_xmit = failover_start_xmit,
>> > > + .ndo_select_queue = failover_select_queue,
>> > > + .ndo_get_stats64 = failover_get_stats,
>> > > + .ndo_change_mtu = failover_change_mtu,
>> > > + .ndo_set_rx_mode = failover_set_rx_mode,
>> > > + .ndo_validate_addr = eth_validate_addr,
>> > > + .ndo_features_check = passthru_features_check,
>> > xdp support?
>>
>> I think it should be possible to add it be calling the lower dev ndo_xdp routines
>> with proper checks. can we add this later?
>
> I'd be concerned that if you don't xdp userspace will keep poking
> at lower devs. Then it will stop working if you add this later.
The failover device is better off not providing in-driver XDP since
there are already skbs allocated by the time that we see the packet
here anyway. As such generic XDP is the preferred way to handle this
since it will work regardless of what lower devices are present.
The only advantage of having XDP down at the virtio or VF level would
be that it performs better, but at the cost of complexity since we
would need to rebind the eBPF program any time a device is hotplugged
out and then back in. For now the current approach is in keeping with
how bonding and other similar drivers are currently handling this.
Thanks.
- Alex
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [virtio-dev] Re: [PATCH v7 net-next 2/4] net: Introduce generic failover module
2018-04-20 15:34 ` [virtio-dev] " Michael S. Tsirkin
(?)
(?)
@ 2018-04-20 15:56 ` Alexander Duyck
-1 siblings, 0 replies; 114+ messages in thread
From: Alexander Duyck @ 2018-04-20 15:56 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Duyck, Alexander H, virtio-dev, Jiri Pirko, Jakub Kicinski,
Samudrala, Sridhar, virtualization, Siwei Liu, Netdev,
David Miller
On Fri, Apr 20, 2018 at 8:34 AM, Michael S. Tsirkin <mst@redhat.com> wrote:
> On Fri, Apr 20, 2018 at 08:21:00AM -0700, Samudrala, Sridhar wrote:
>> > > + finfo = netdev_priv(failover_dev);
>> > > +
>> > > + primary_dev = rtnl_dereference(finfo->primary_dev);
>> > > + standby_dev = rtnl_dereference(finfo->standby_dev);
>> > > +
>> > > + if (slave_dev != primary_dev && slave_dev != standby_dev)
>> > > + goto done;
>> > > +
>> > > + if ((primary_dev && failover_xmit_ready(primary_dev)) ||
>> > > + (standby_dev && failover_xmit_ready(standby_dev))) {
>> > > + netif_carrier_on(failover_dev);
>> > > + netif_tx_wake_all_queues(failover_dev);
>> > > + } else {
>> > > + netif_carrier_off(failover_dev);
>> > > + netif_tx_stop_all_queues(failover_dev);
>> > And I think it's a good idea to get stats from device here too.
>>
>> Not sure why we need to get stats from lower devs here?
>
> link down is often indication of a hardware problem.
> lower dev might stop responding down the road.
>
>> > > +static const struct net_device_ops failover_dev_ops = {
>> > > + .ndo_open = failover_open,
>> > > + .ndo_stop = failover_close,
>> > > + .ndo_start_xmit = failover_start_xmit,
>> > > + .ndo_select_queue = failover_select_queue,
>> > > + .ndo_get_stats64 = failover_get_stats,
>> > > + .ndo_change_mtu = failover_change_mtu,
>> > > + .ndo_set_rx_mode = failover_set_rx_mode,
>> > > + .ndo_validate_addr = eth_validate_addr,
>> > > + .ndo_features_check = passthru_features_check,
>> > xdp support?
>>
>> I think it should be possible to add it be calling the lower dev ndo_xdp routines
>> with proper checks. can we add this later?
>
> I'd be concerned that if you don't xdp userspace will keep poking
> at lower devs. Then it will stop working if you add this later.
The failover device is better off not providing in-driver XDP since
there are already skbs allocated by the time that we see the packet
here anyway. As such generic XDP is the preferred way to handle this
since it will work regardless of what lower devices are present.
The only advantage of having XDP down at the virtio or VF level would
be that it performs better, but at the cost of complexity since we
would need to rebind the eBPF program any time a device is hotplugged
out and then back in. For now the current approach is in keeping with
how bonding and other similar drivers are currently handling this.
Thanks.
- Alex
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [virtio-dev] Re: [PATCH v7 net-next 2/4] net: Introduce generic failover module
@ 2018-04-20 15:56 ` Alexander Duyck
0 siblings, 0 replies; 114+ messages in thread
From: Alexander Duyck @ 2018-04-20 15:56 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Samudrala, Sridhar, Stephen Hemminger, David Miller, Netdev,
virtualization, virtio-dev, Brandeburg, Jesse, Duyck,
Alexander H, Jakub Kicinski, Jason Wang, Siwei Liu, Jiri Pirko
On Fri, Apr 20, 2018 at 8:34 AM, Michael S. Tsirkin <mst@redhat.com> wrote:
> On Fri, Apr 20, 2018 at 08:21:00AM -0700, Samudrala, Sridhar wrote:
>> > > + finfo = netdev_priv(failover_dev);
>> > > +
>> > > + primary_dev = rtnl_dereference(finfo->primary_dev);
>> > > + standby_dev = rtnl_dereference(finfo->standby_dev);
>> > > +
>> > > + if (slave_dev != primary_dev && slave_dev != standby_dev)
>> > > + goto done;
>> > > +
>> > > + if ((primary_dev && failover_xmit_ready(primary_dev)) ||
>> > > + (standby_dev && failover_xmit_ready(standby_dev))) {
>> > > + netif_carrier_on(failover_dev);
>> > > + netif_tx_wake_all_queues(failover_dev);
>> > > + } else {
>> > > + netif_carrier_off(failover_dev);
>> > > + netif_tx_stop_all_queues(failover_dev);
>> > And I think it's a good idea to get stats from device here too.
>>
>> Not sure why we need to get stats from lower devs here?
>
> link down is often indication of a hardware problem.
> lower dev might stop responding down the road.
>
>> > > +static const struct net_device_ops failover_dev_ops = {
>> > > + .ndo_open = failover_open,
>> > > + .ndo_stop = failover_close,
>> > > + .ndo_start_xmit = failover_start_xmit,
>> > > + .ndo_select_queue = failover_select_queue,
>> > > + .ndo_get_stats64 = failover_get_stats,
>> > > + .ndo_change_mtu = failover_change_mtu,
>> > > + .ndo_set_rx_mode = failover_set_rx_mode,
>> > > + .ndo_validate_addr = eth_validate_addr,
>> > > + .ndo_features_check = passthru_features_check,
>> > xdp support?
>>
>> I think it should be possible to add it be calling the lower dev ndo_xdp routines
>> with proper checks. can we add this later?
>
> I'd be concerned that if you don't xdp userspace will keep poking
> at lower devs. Then it will stop working if you add this later.
The failover device is better off not providing in-driver XDP since
there are already skbs allocated by the time that we see the packet
here anyway. As such generic XDP is the preferred way to handle this
since it will work regardless of what lower devices are present.
The only advantage of having XDP down at the virtio or VF level would
be that it performs better, but at the cost of complexity since we
would need to rebind the eBPF program any time a device is hotplugged
out and then back in. For now the current approach is in keeping with
how bonding and other similar drivers are currently handling this.
Thanks.
- Alex
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 net-next 4/4] netvsc: refactor notifier/event handling code to use the failover framework
2018-04-20 15:28 ` Stephen Hemminger
` (6 preceding siblings ...)
2018-04-20 16:00 ` Jiri Pirko
@ 2018-04-20 16:00 ` Jiri Pirko
2018-04-23 17:04 ` Stephen Hemminger
2018-04-23 17:04 ` Stephen Hemminger
7 siblings, 2 replies; 114+ messages in thread
From: Jiri Pirko @ 2018-04-20 16:00 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Sridhar Samudrala, mst, davem, netdev, virtualization,
virtio-dev, jesse.brandeburg, alexander.h.duyck, kubakici,
jasowang, loseweigh
Fri, Apr 20, 2018 at 05:28:02PM CEST, stephen@networkplumber.org wrote:
>On Thu, 19 Apr 2018 18:42:04 -0700
>Sridhar Samudrala <sridhar.samudrala@intel.com> wrote:
>
>> Use the registration/notification framework supported by the generic
>> failover infrastructure.
>>
>> Signed-off-by: Sridhar Samudrala <sridhar.samudrala@intel.com>
>
>Do what you want to other devices but leave netvsc alone.
>Adding these failover ops does not reduce the code size, and really is
>no benefit. The netvsc device driver needs to be backported to several
>other distributions and doing this makes that harder.
We should not care about the backport burden when we are trying to make
things right. And things are not right. The current netvsc approach is
just plain wrong shortcut. It should have been done in a generic way
from the very beginning. We are just trying to fix this situation.
Moreover, I believe that part of the fix is to convert netvsc to 3
netdev solution too. 2 netdev model is wrong.
>
>I will NAK patches to change to common code for netvsc especially the
>three device model. MS worked hard with distro vendors to support transparent
>mode, ans we really can't have a new model; or do backport.
>
>Plus, DPDK is now dependent on existing model.
Sorry, but nobody here cares about dpdk or other similar oddities.
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 net-next 4/4] netvsc: refactor notifier/event handling code to use the failover framework
2018-04-20 15:28 ` Stephen Hemminger
` (5 preceding siblings ...)
2018-04-20 15:46 ` [virtio-dev] " Samudrala, Sridhar
@ 2018-04-20 16:00 ` Jiri Pirko
2018-04-20 16:00 ` Jiri Pirko
7 siblings, 0 replies; 114+ messages in thread
From: Jiri Pirko @ 2018-04-20 16:00 UTC (permalink / raw)
To: Stephen Hemminger
Cc: alexander.h.duyck, virtio-dev, mst, kubakici, Sridhar Samudrala,
virtualization, loseweigh, netdev, davem
Fri, Apr 20, 2018 at 05:28:02PM CEST, stephen@networkplumber.org wrote:
>On Thu, 19 Apr 2018 18:42:04 -0700
>Sridhar Samudrala <sridhar.samudrala@intel.com> wrote:
>
>> Use the registration/notification framework supported by the generic
>> failover infrastructure.
>>
>> Signed-off-by: Sridhar Samudrala <sridhar.samudrala@intel.com>
>
>Do what you want to other devices but leave netvsc alone.
>Adding these failover ops does not reduce the code size, and really is
>no benefit. The netvsc device driver needs to be backported to several
>other distributions and doing this makes that harder.
We should not care about the backport burden when we are trying to make
things right. And things are not right. The current netvsc approach is
just plain wrong shortcut. It should have been done in a generic way
from the very beginning. We are just trying to fix this situation.
Moreover, I believe that part of the fix is to convert netvsc to 3
netdev solution too. 2 netdev model is wrong.
>
>I will NAK patches to change to common code for netvsc especially the
>three device model. MS worked hard with distro vendors to support transparent
>mode, ans we really can't have a new model; or do backport.
>
>Plus, DPDK is now dependent on existing model.
Sorry, but nobody here cares about dpdk or other similar oddities.
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [virtio-dev] Re: [PATCH v7 net-next 2/4] net: Introduce generic failover module
2018-04-20 15:56 ` Alexander Duyck
@ 2018-04-20 16:03 ` Michael S. Tsirkin
-1 siblings, 0 replies; 114+ messages in thread
From: Michael S. Tsirkin @ 2018-04-20 16:03 UTC (permalink / raw)
To: Alexander Duyck
Cc: Samudrala, Sridhar, Stephen Hemminger, David Miller, Netdev,
virtualization, virtio-dev, Brandeburg, Jesse, Duyck,
Alexander H, Jakub Kicinski, Jason Wang, Siwei Liu, Jiri Pirko
On Fri, Apr 20, 2018 at 08:56:57AM -0700, Alexander Duyck wrote:
> On Fri, Apr 20, 2018 at 8:34 AM, Michael S. Tsirkin <mst@redhat.com> wrote:
> > On Fri, Apr 20, 2018 at 08:21:00AM -0700, Samudrala, Sridhar wrote:
> >> > > + finfo = netdev_priv(failover_dev);
> >> > > +
> >> > > + primary_dev = rtnl_dereference(finfo->primary_dev);
> >> > > + standby_dev = rtnl_dereference(finfo->standby_dev);
> >> > > +
> >> > > + if (slave_dev != primary_dev && slave_dev != standby_dev)
> >> > > + goto done;
> >> > > +
> >> > > + if ((primary_dev && failover_xmit_ready(primary_dev)) ||
> >> > > + (standby_dev && failover_xmit_ready(standby_dev))) {
> >> > > + netif_carrier_on(failover_dev);
> >> > > + netif_tx_wake_all_queues(failover_dev);
> >> > > + } else {
> >> > > + netif_carrier_off(failover_dev);
> >> > > + netif_tx_stop_all_queues(failover_dev);
> >> > And I think it's a good idea to get stats from device here too.
> >>
> >> Not sure why we need to get stats from lower devs here?
> >
> > link down is often indication of a hardware problem.
> > lower dev might stop responding down the road.
> >
> >> > > +static const struct net_device_ops failover_dev_ops = {
> >> > > + .ndo_open = failover_open,
> >> > > + .ndo_stop = failover_close,
> >> > > + .ndo_start_xmit = failover_start_xmit,
> >> > > + .ndo_select_queue = failover_select_queue,
> >> > > + .ndo_get_stats64 = failover_get_stats,
> >> > > + .ndo_change_mtu = failover_change_mtu,
> >> > > + .ndo_set_rx_mode = failover_set_rx_mode,
> >> > > + .ndo_validate_addr = eth_validate_addr,
> >> > > + .ndo_features_check = passthru_features_check,
> >> > xdp support?
> >>
> >> I think it should be possible to add it be calling the lower dev ndo_xdp routines
> >> with proper checks. can we add this later?
> >
> > I'd be concerned that if you don't xdp userspace will keep poking
> > at lower devs. Then it will stop working if you add this later.
>
> The failover device is better off not providing in-driver XDP since
> there are already skbs allocated by the time that we see the packet
> here anyway. As such generic XDP is the preferred way to handle this
> since it will work regardless of what lower devices are present.
>
> The only advantage of having XDP down at the virtio or VF level would
> be that it performs better, but at the cost of complexity since we
> would need to rebind the eBPF program any time a device is hotplugged
> out and then back in. For now the current approach is in keeping with
> how bonding and other similar drivers are currently handling this.
>
> Thanks.
>
> - Alex
OK fair enough.
--
MST
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [virtio-dev] Re: [PATCH v7 net-next 2/4] net: Introduce generic failover module
2018-04-20 15:56 ` Alexander Duyck
(?)
@ 2018-04-20 16:03 ` Michael S. Tsirkin
-1 siblings, 0 replies; 114+ messages in thread
From: Michael S. Tsirkin @ 2018-04-20 16:03 UTC (permalink / raw)
To: Alexander Duyck
Cc: Duyck, Alexander H, virtio-dev, Jiri Pirko, Jakub Kicinski,
Samudrala, Sridhar, virtualization, Siwei Liu, Netdev,
David Miller
On Fri, Apr 20, 2018 at 08:56:57AM -0700, Alexander Duyck wrote:
> On Fri, Apr 20, 2018 at 8:34 AM, Michael S. Tsirkin <mst@redhat.com> wrote:
> > On Fri, Apr 20, 2018 at 08:21:00AM -0700, Samudrala, Sridhar wrote:
> >> > > + finfo = netdev_priv(failover_dev);
> >> > > +
> >> > > + primary_dev = rtnl_dereference(finfo->primary_dev);
> >> > > + standby_dev = rtnl_dereference(finfo->standby_dev);
> >> > > +
> >> > > + if (slave_dev != primary_dev && slave_dev != standby_dev)
> >> > > + goto done;
> >> > > +
> >> > > + if ((primary_dev && failover_xmit_ready(primary_dev)) ||
> >> > > + (standby_dev && failover_xmit_ready(standby_dev))) {
> >> > > + netif_carrier_on(failover_dev);
> >> > > + netif_tx_wake_all_queues(failover_dev);
> >> > > + } else {
> >> > > + netif_carrier_off(failover_dev);
> >> > > + netif_tx_stop_all_queues(failover_dev);
> >> > And I think it's a good idea to get stats from device here too.
> >>
> >> Not sure why we need to get stats from lower devs here?
> >
> > link down is often indication of a hardware problem.
> > lower dev might stop responding down the road.
> >
> >> > > +static const struct net_device_ops failover_dev_ops = {
> >> > > + .ndo_open = failover_open,
> >> > > + .ndo_stop = failover_close,
> >> > > + .ndo_start_xmit = failover_start_xmit,
> >> > > + .ndo_select_queue = failover_select_queue,
> >> > > + .ndo_get_stats64 = failover_get_stats,
> >> > > + .ndo_change_mtu = failover_change_mtu,
> >> > > + .ndo_set_rx_mode = failover_set_rx_mode,
> >> > > + .ndo_validate_addr = eth_validate_addr,
> >> > > + .ndo_features_check = passthru_features_check,
> >> > xdp support?
> >>
> >> I think it should be possible to add it be calling the lower dev ndo_xdp routines
> >> with proper checks. can we add this later?
> >
> > I'd be concerned that if you don't xdp userspace will keep poking
> > at lower devs. Then it will stop working if you add this later.
>
> The failover device is better off not providing in-driver XDP since
> there are already skbs allocated by the time that we see the packet
> here anyway. As such generic XDP is the preferred way to handle this
> since it will work regardless of what lower devices are present.
>
> The only advantage of having XDP down at the virtio or VF level would
> be that it performs better, but at the cost of complexity since we
> would need to rebind the eBPF program any time a device is hotplugged
> out and then back in. For now the current approach is in keeping with
> how bonding and other similar drivers are currently handling this.
>
> Thanks.
>
> - Alex
OK fair enough.
--
MST
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [virtio-dev] Re: [PATCH v7 net-next 2/4] net: Introduce generic failover module
@ 2018-04-20 16:03 ` Michael S. Tsirkin
0 siblings, 0 replies; 114+ messages in thread
From: Michael S. Tsirkin @ 2018-04-20 16:03 UTC (permalink / raw)
To: Alexander Duyck
Cc: Samudrala, Sridhar, Stephen Hemminger, David Miller, Netdev,
virtualization, virtio-dev, Brandeburg, Jesse, Duyck,
Alexander H, Jakub Kicinski, Jason Wang, Siwei Liu, Jiri Pirko
On Fri, Apr 20, 2018 at 08:56:57AM -0700, Alexander Duyck wrote:
> On Fri, Apr 20, 2018 at 8:34 AM, Michael S. Tsirkin <mst@redhat.com> wrote:
> > On Fri, Apr 20, 2018 at 08:21:00AM -0700, Samudrala, Sridhar wrote:
> >> > > + finfo = netdev_priv(failover_dev);
> >> > > +
> >> > > + primary_dev = rtnl_dereference(finfo->primary_dev);
> >> > > + standby_dev = rtnl_dereference(finfo->standby_dev);
> >> > > +
> >> > > + if (slave_dev != primary_dev && slave_dev != standby_dev)
> >> > > + goto done;
> >> > > +
> >> > > + if ((primary_dev && failover_xmit_ready(primary_dev)) ||
> >> > > + (standby_dev && failover_xmit_ready(standby_dev))) {
> >> > > + netif_carrier_on(failover_dev);
> >> > > + netif_tx_wake_all_queues(failover_dev);
> >> > > + } else {
> >> > > + netif_carrier_off(failover_dev);
> >> > > + netif_tx_stop_all_queues(failover_dev);
> >> > And I think it's a good idea to get stats from device here too.
> >>
> >> Not sure why we need to get stats from lower devs here?
> >
> > link down is often indication of a hardware problem.
> > lower dev might stop responding down the road.
> >
> >> > > +static const struct net_device_ops failover_dev_ops = {
> >> > > + .ndo_open = failover_open,
> >> > > + .ndo_stop = failover_close,
> >> > > + .ndo_start_xmit = failover_start_xmit,
> >> > > + .ndo_select_queue = failover_select_queue,
> >> > > + .ndo_get_stats64 = failover_get_stats,
> >> > > + .ndo_change_mtu = failover_change_mtu,
> >> > > + .ndo_set_rx_mode = failover_set_rx_mode,
> >> > > + .ndo_validate_addr = eth_validate_addr,
> >> > > + .ndo_features_check = passthru_features_check,
> >> > xdp support?
> >>
> >> I think it should be possible to add it be calling the lower dev ndo_xdp routines
> >> with proper checks. can we add this later?
> >
> > I'd be concerned that if you don't xdp userspace will keep poking
> > at lower devs. Then it will stop working if you add this later.
>
> The failover device is better off not providing in-driver XDP since
> there are already skbs allocated by the time that we see the packet
> here anyway. As such generic XDP is the preferred way to handle this
> since it will work regardless of what lower devices are present.
>
> The only advantage of having XDP down at the virtio or VF level would
> be that it performs better, but at the cost of complexity since we
> would need to rebind the eBPF program any time a device is hotplugged
> out and then back in. For now the current approach is in keeping with
> how bonding and other similar drivers are currently handling this.
>
> Thanks.
>
> - Alex
OK fair enough.
--
MST
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 net-next 4/4] netvsc: refactor notifier/event handling code to use the failover framework
2018-04-20 1:42 ` [virtio-dev] " Sridhar Samudrala
@ 2018-04-22 15:41 ` kbuild test robot
-1 siblings, 0 replies; 114+ messages in thread
From: kbuild test robot @ 2018-04-22 15:41 UTC (permalink / raw)
To: Sridhar Samudrala
Cc: alexander.h.duyck, virtio-dev, jiri, mst, kubakici, netdev,
virtualization, loseweigh, kbuild-all, sridhar.samudrala, davem
[-- Attachment #1: Type: text/plain, Size: 7695 bytes --]
Hi Sridhar,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on net/master]
[also build test ERROR on v4.17-rc1]
[cannot apply to net-next/master next-20180420]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Sridhar-Samudrala/Enable-virtio_net-to-act-as-a-standby-for-a-passthru-device/20180422-210557
config: x86_64-allyesdebian (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All error/warnings (new ones prefixed by >>):
In file included from drivers/net/hyperv/netvsc_drv.c:46:0:
include/net/failover.h:67:1: error: expected identifier or '(' before '{' token
{
^
include/net/failover.h:78:16: warning: 'struct pfailover' declared inside parameter list will not be visible outside of this definition or declaration
struct pfailover **pfailover);
^~~~~~~~~
include/net/failover.h:79:1: error: expected identifier or '(' before '{' token
{
^
drivers/net/hyperv/netvsc_drv.c: In function 'netvsc_probe':
>> drivers/net/hyperv/netvsc_drv.c:2020:5: error: passing argument 3 of 'failover_register' from incompatible pointer type [-Werror=incompatible-pointer-types]
&net_device_ctx->failover);
^
In file included from drivers/net/hyperv/netvsc_drv.c:46:0:
include/net/failover.h:77:5: note: expected 'struct pfailover **' but argument is of type 'struct failover **'
int failover_register(struct net_device *standby_dev, struct failover_ops *ops,
^~~~~~~~~~~~~~~~~
drivers/net/hyperv/netvsc_drv.c: At top level:
include/net/failover.h:65:5: warning: 'failover_create' declared 'static' but never defined [-Wunused-function]
int failover_create(struct net_device *standby_dev,
^~~~~~~~~~~~~~~
>> include/net/failover.h:77:5: warning: 'failover_register' used but never defined
int failover_register(struct net_device *standby_dev, struct failover_ops *ops,
^~~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
--
In file included from drivers/net//hyperv/netvsc_drv.c:46:0:
include/net/failover.h:67:1: error: expected identifier or '(' before '{' token
{
^
include/net/failover.h:78:16: warning: 'struct pfailover' declared inside parameter list will not be visible outside of this definition or declaration
struct pfailover **pfailover);
^~~~~~~~~
include/net/failover.h:79:1: error: expected identifier or '(' before '{' token
{
^
drivers/net//hyperv/netvsc_drv.c: In function 'netvsc_probe':
drivers/net//hyperv/netvsc_drv.c:2020:5: error: passing argument 3 of 'failover_register' from incompatible pointer type [-Werror=incompatible-pointer-types]
&net_device_ctx->failover);
^
In file included from drivers/net//hyperv/netvsc_drv.c:46:0:
include/net/failover.h:77:5: note: expected 'struct pfailover **' but argument is of type 'struct failover **'
int failover_register(struct net_device *standby_dev, struct failover_ops *ops,
^~~~~~~~~~~~~~~~~
drivers/net//hyperv/netvsc_drv.c: At top level:
include/net/failover.h:65:5: warning: 'failover_create' declared 'static' but never defined [-Wunused-function]
int failover_create(struct net_device *standby_dev,
^~~~~~~~~~~~~~~
>> include/net/failover.h:77:5: warning: 'failover_register' used but never defined
int failover_register(struct net_device *standby_dev, struct failover_ops *ops,
^~~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
vim +/failover_register +2020 drivers/net/hyperv/netvsc_drv.c
1929
1930 static int netvsc_probe(struct hv_device *dev,
1931 const struct hv_vmbus_device_id *dev_id)
1932 {
1933 struct net_device *net = NULL;
1934 struct net_device_context *net_device_ctx;
1935 struct netvsc_device_info device_info;
1936 struct netvsc_device *nvdev;
1937 int ret = -ENOMEM;
1938
1939 net = alloc_etherdev_mq(sizeof(struct net_device_context),
1940 VRSS_CHANNEL_MAX);
1941 if (!net)
1942 goto no_net;
1943
1944 netif_carrier_off(net);
1945
1946 netvsc_init_settings(net);
1947
1948 net_device_ctx = netdev_priv(net);
1949 net_device_ctx->device_ctx = dev;
1950 net_device_ctx->msg_enable = netif_msg_init(debug, default_msg);
1951 if (netif_msg_probe(net_device_ctx))
1952 netdev_dbg(net, "netvsc msg_enable: %d\n",
1953 net_device_ctx->msg_enable);
1954
1955 hv_set_drvdata(dev, net);
1956
1957 INIT_DELAYED_WORK(&net_device_ctx->dwork, netvsc_link_change);
1958
1959 spin_lock_init(&net_device_ctx->lock);
1960 INIT_LIST_HEAD(&net_device_ctx->reconfig_events);
1961 INIT_DELAYED_WORK(&net_device_ctx->vf_takeover, netvsc_vf_setup);
1962
1963 net_device_ctx->vf_stats
1964 = netdev_alloc_pcpu_stats(struct netvsc_vf_pcpu_stats);
1965 if (!net_device_ctx->vf_stats)
1966 goto no_stats;
1967
1968 net->netdev_ops = &device_ops;
1969 net->ethtool_ops = ðtool_ops;
1970 SET_NETDEV_DEV(net, &dev->device);
1971
1972 /* We always need headroom for rndis header */
1973 net->needed_headroom = RNDIS_AND_PPI_SIZE;
1974
1975 /* Initialize the number of queues to be 1, we may change it if more
1976 * channels are offered later.
1977 */
1978 netif_set_real_num_tx_queues(net, 1);
1979 netif_set_real_num_rx_queues(net, 1);
1980
1981 /* Notify the netvsc driver of the new device */
1982 memset(&device_info, 0, sizeof(device_info));
1983 device_info.num_chn = VRSS_CHANNEL_DEFAULT;
1984 device_info.send_sections = NETVSC_DEFAULT_TX;
1985 device_info.send_section_size = NETVSC_SEND_SECTION_SIZE;
1986 device_info.recv_sections = NETVSC_DEFAULT_RX;
1987 device_info.recv_section_size = NETVSC_RECV_SECTION_SIZE;
1988
1989 nvdev = rndis_filter_device_add(dev, &device_info);
1990 if (IS_ERR(nvdev)) {
1991 ret = PTR_ERR(nvdev);
1992 netdev_err(net, "unable to add netvsc device (ret %d)\n", ret);
1993 goto rndis_failed;
1994 }
1995
1996 memcpy(net->dev_addr, device_info.mac_adr, ETH_ALEN);
1997
1998 /* hw_features computed in rndis_netdev_set_hwcaps() */
1999 net->features = net->hw_features |
2000 NETIF_F_HIGHDMA | NETIF_F_SG |
2001 NETIF_F_HW_VLAN_CTAG_TX | NETIF_F_HW_VLAN_CTAG_RX;
2002 net->vlan_features = net->features;
2003
2004 netdev_lockdep_set_classes(net);
2005
2006 /* MTU range: 68 - 1500 or 65521 */
2007 net->min_mtu = NETVSC_MTU_MIN;
2008 if (nvdev->nvsp_version >= NVSP_PROTOCOL_VERSION_2)
2009 net->max_mtu = NETVSC_MTU - ETH_HLEN;
2010 else
2011 net->max_mtu = ETH_DATA_LEN;
2012
2013 ret = register_netdev(net);
2014 if (ret != 0) {
2015 pr_err("Unable to register netdev.\n");
2016 goto register_failed;
2017 }
2018
2019 ret = failover_register(net, &netvsc_failover_ops,
> 2020 &net_device_ctx->failover);
2021 if (ret != 0)
2022 goto err_failover;
2023
2024 return ret;
2025
2026 err_failover:
2027 unregister_netdev(net);
2028 register_failed:
2029 rndis_filter_device_remove(dev, nvdev);
2030 rndis_failed:
2031 free_percpu(net_device_ctx->vf_stats);
2032 no_stats:
2033 hv_set_drvdata(dev, NULL);
2034 free_netdev(net);
2035 no_net:
2036 return ret;
2037 }
2038
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 39371 bytes --]
[-- Attachment #3: Type: text/plain, Size: 183 bytes --]
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 net-next 4/4] netvsc: refactor notifier/event handling code to use the failover framework
@ 2018-04-22 15:41 ` kbuild test robot
0 siblings, 0 replies; 114+ messages in thread
From: kbuild test robot @ 2018-04-22 15:41 UTC (permalink / raw)
Cc: alexander.h.duyck, virtio-dev, jiri, mst, kubakici, netdev,
virtualization, loseweigh, kbuild-all, sridhar.samudrala, davem
[-- Attachment #1: Type: text/plain, Size: 7695 bytes --]
Hi Sridhar,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on net/master]
[also build test ERROR on v4.17-rc1]
[cannot apply to net-next/master next-20180420]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Sridhar-Samudrala/Enable-virtio_net-to-act-as-a-standby-for-a-passthru-device/20180422-210557
config: x86_64-allyesdebian (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All error/warnings (new ones prefixed by >>):
In file included from drivers/net/hyperv/netvsc_drv.c:46:0:
include/net/failover.h:67:1: error: expected identifier or '(' before '{' token
{
^
include/net/failover.h:78:16: warning: 'struct pfailover' declared inside parameter list will not be visible outside of this definition or declaration
struct pfailover **pfailover);
^~~~~~~~~
include/net/failover.h:79:1: error: expected identifier or '(' before '{' token
{
^
drivers/net/hyperv/netvsc_drv.c: In function 'netvsc_probe':
>> drivers/net/hyperv/netvsc_drv.c:2020:5: error: passing argument 3 of 'failover_register' from incompatible pointer type [-Werror=incompatible-pointer-types]
&net_device_ctx->failover);
^
In file included from drivers/net/hyperv/netvsc_drv.c:46:0:
include/net/failover.h:77:5: note: expected 'struct pfailover **' but argument is of type 'struct failover **'
int failover_register(struct net_device *standby_dev, struct failover_ops *ops,
^~~~~~~~~~~~~~~~~
drivers/net/hyperv/netvsc_drv.c: At top level:
include/net/failover.h:65:5: warning: 'failover_create' declared 'static' but never defined [-Wunused-function]
int failover_create(struct net_device *standby_dev,
^~~~~~~~~~~~~~~
>> include/net/failover.h:77:5: warning: 'failover_register' used but never defined
int failover_register(struct net_device *standby_dev, struct failover_ops *ops,
^~~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
--
In file included from drivers/net//hyperv/netvsc_drv.c:46:0:
include/net/failover.h:67:1: error: expected identifier or '(' before '{' token
{
^
include/net/failover.h:78:16: warning: 'struct pfailover' declared inside parameter list will not be visible outside of this definition or declaration
struct pfailover **pfailover);
^~~~~~~~~
include/net/failover.h:79:1: error: expected identifier or '(' before '{' token
{
^
drivers/net//hyperv/netvsc_drv.c: In function 'netvsc_probe':
drivers/net//hyperv/netvsc_drv.c:2020:5: error: passing argument 3 of 'failover_register' from incompatible pointer type [-Werror=incompatible-pointer-types]
&net_device_ctx->failover);
^
In file included from drivers/net//hyperv/netvsc_drv.c:46:0:
include/net/failover.h:77:5: note: expected 'struct pfailover **' but argument is of type 'struct failover **'
int failover_register(struct net_device *standby_dev, struct failover_ops *ops,
^~~~~~~~~~~~~~~~~
drivers/net//hyperv/netvsc_drv.c: At top level:
include/net/failover.h:65:5: warning: 'failover_create' declared 'static' but never defined [-Wunused-function]
int failover_create(struct net_device *standby_dev,
^~~~~~~~~~~~~~~
>> include/net/failover.h:77:5: warning: 'failover_register' used but never defined
int failover_register(struct net_device *standby_dev, struct failover_ops *ops,
^~~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
vim +/failover_register +2020 drivers/net/hyperv/netvsc_drv.c
1929
1930 static int netvsc_probe(struct hv_device *dev,
1931 const struct hv_vmbus_device_id *dev_id)
1932 {
1933 struct net_device *net = NULL;
1934 struct net_device_context *net_device_ctx;
1935 struct netvsc_device_info device_info;
1936 struct netvsc_device *nvdev;
1937 int ret = -ENOMEM;
1938
1939 net = alloc_etherdev_mq(sizeof(struct net_device_context),
1940 VRSS_CHANNEL_MAX);
1941 if (!net)
1942 goto no_net;
1943
1944 netif_carrier_off(net);
1945
1946 netvsc_init_settings(net);
1947
1948 net_device_ctx = netdev_priv(net);
1949 net_device_ctx->device_ctx = dev;
1950 net_device_ctx->msg_enable = netif_msg_init(debug, default_msg);
1951 if (netif_msg_probe(net_device_ctx))
1952 netdev_dbg(net, "netvsc msg_enable: %d\n",
1953 net_device_ctx->msg_enable);
1954
1955 hv_set_drvdata(dev, net);
1956
1957 INIT_DELAYED_WORK(&net_device_ctx->dwork, netvsc_link_change);
1958
1959 spin_lock_init(&net_device_ctx->lock);
1960 INIT_LIST_HEAD(&net_device_ctx->reconfig_events);
1961 INIT_DELAYED_WORK(&net_device_ctx->vf_takeover, netvsc_vf_setup);
1962
1963 net_device_ctx->vf_stats
1964 = netdev_alloc_pcpu_stats(struct netvsc_vf_pcpu_stats);
1965 if (!net_device_ctx->vf_stats)
1966 goto no_stats;
1967
1968 net->netdev_ops = &device_ops;
1969 net->ethtool_ops = ðtool_ops;
1970 SET_NETDEV_DEV(net, &dev->device);
1971
1972 /* We always need headroom for rndis header */
1973 net->needed_headroom = RNDIS_AND_PPI_SIZE;
1974
1975 /* Initialize the number of queues to be 1, we may change it if more
1976 * channels are offered later.
1977 */
1978 netif_set_real_num_tx_queues(net, 1);
1979 netif_set_real_num_rx_queues(net, 1);
1980
1981 /* Notify the netvsc driver of the new device */
1982 memset(&device_info, 0, sizeof(device_info));
1983 device_info.num_chn = VRSS_CHANNEL_DEFAULT;
1984 device_info.send_sections = NETVSC_DEFAULT_TX;
1985 device_info.send_section_size = NETVSC_SEND_SECTION_SIZE;
1986 device_info.recv_sections = NETVSC_DEFAULT_RX;
1987 device_info.recv_section_size = NETVSC_RECV_SECTION_SIZE;
1988
1989 nvdev = rndis_filter_device_add(dev, &device_info);
1990 if (IS_ERR(nvdev)) {
1991 ret = PTR_ERR(nvdev);
1992 netdev_err(net, "unable to add netvsc device (ret %d)\n", ret);
1993 goto rndis_failed;
1994 }
1995
1996 memcpy(net->dev_addr, device_info.mac_adr, ETH_ALEN);
1997
1998 /* hw_features computed in rndis_netdev_set_hwcaps() */
1999 net->features = net->hw_features |
2000 NETIF_F_HIGHDMA | NETIF_F_SG |
2001 NETIF_F_HW_VLAN_CTAG_TX | NETIF_F_HW_VLAN_CTAG_RX;
2002 net->vlan_features = net->features;
2003
2004 netdev_lockdep_set_classes(net);
2005
2006 /* MTU range: 68 - 1500 or 65521 */
2007 net->min_mtu = NETVSC_MTU_MIN;
2008 if (nvdev->nvsp_version >= NVSP_PROTOCOL_VERSION_2)
2009 net->max_mtu = NETVSC_MTU - ETH_HLEN;
2010 else
2011 net->max_mtu = ETH_DATA_LEN;
2012
2013 ret = register_netdev(net);
2014 if (ret != 0) {
2015 pr_err("Unable to register netdev.\n");
2016 goto register_failed;
2017 }
2018
2019 ret = failover_register(net, &netvsc_failover_ops,
> 2020 &net_device_ctx->failover);
2021 if (ret != 0)
2022 goto err_failover;
2023
2024 return ret;
2025
2026 err_failover:
2027 unregister_netdev(net);
2028 register_failed:
2029 rndis_filter_device_remove(dev, nvdev);
2030 rndis_failed:
2031 free_percpu(net_device_ctx->vf_stats);
2032 no_stats:
2033 hv_set_drvdata(dev, NULL);
2034 free_netdev(net);
2035 no_net:
2036 return ret;
2037 }
2038
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 39371 bytes --]
[-- Attachment #3: Type: text/plain, Size: 183 bytes --]
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 net-next 3/4] virtio_net: Extend virtio to use VF datapath when available
2018-04-20 1:42 ` [virtio-dev] " Sridhar Samudrala
@ 2018-04-22 15:41 ` kbuild test robot
-1 siblings, 0 replies; 114+ messages in thread
From: kbuild test robot @ 2018-04-22 15:41 UTC (permalink / raw)
To: Sridhar Samudrala
Cc: alexander.h.duyck, virtio-dev, jiri, mst, kubakici, netdev,
virtualization, loseweigh, kbuild-all, sridhar.samudrala, davem
[-- Attachment #1: Type: text/plain, Size: 3173 bytes --]
Hi Sridhar,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on net/master]
[also build test ERROR on v4.17-rc1]
[cannot apply to net-next/master next-20180420]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Sridhar-Samudrala/Enable-virtio_net-to-act-as-a-standby-for-a-passthru-device/20180422-210557
config: i386-randconfig-x071-201816 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All error/warnings (new ones prefixed by >>):
In file included from drivers//net/virtio_net.c:37:0:
>> include/net/failover.h:67:1: error: expected identifier or '(' before '{' token
{
^
>> include/net/failover.h:78:16: warning: 'struct pfailover' declared inside parameter list will not be visible outside of this definition or declaration
struct pfailover **pfailover);
^~~~~~~~~
include/net/failover.h:79:1: error: expected identifier or '(' before '{' token
{
^
>> include/net/failover.h:65:5: warning: 'failover_create' used but never defined
int failover_create(struct net_device *standby_dev,
^~~~~~~~~~~~~~~
include/net/failover.h:77:5: warning: 'failover_register' declared 'static' but never defined [-Wunused-function]
int failover_register(struct net_device *standby_dev, struct failover_ops *ops,
^~~~~~~~~~~~~~~~~
vim +67 include/net/failover.h
891cac68 Sridhar Samudrala 2018-04-19 63
891cac68 Sridhar Samudrala 2018-04-19 64 static inline
891cac68 Sridhar Samudrala 2018-04-19 @65 int failover_create(struct net_device *standby_dev,
891cac68 Sridhar Samudrala 2018-04-19 66 struct failover **pfailover);
891cac68 Sridhar Samudrala 2018-04-19 @67 {
891cac68 Sridhar Samudrala 2018-04-19 68 return 0;
891cac68 Sridhar Samudrala 2018-04-19 69 }
891cac68 Sridhar Samudrala 2018-04-19 70
891cac68 Sridhar Samudrala 2018-04-19 71 static inline
891cac68 Sridhar Samudrala 2018-04-19 72 void failover_destroy(struct failover *failover)
891cac68 Sridhar Samudrala 2018-04-19 73 {
891cac68 Sridhar Samudrala 2018-04-19 74 }
891cac68 Sridhar Samudrala 2018-04-19 75
891cac68 Sridhar Samudrala 2018-04-19 76 static inline
891cac68 Sridhar Samudrala 2018-04-19 77 int failover_register(struct net_device *standby_dev, struct failover_ops *ops,
891cac68 Sridhar Samudrala 2018-04-19 @78 struct pfailover **pfailover);
891cac68 Sridhar Samudrala 2018-04-19 79 {
891cac68 Sridhar Samudrala 2018-04-19 80 return 0;
891cac68 Sridhar Samudrala 2018-04-19 81 }
891cac68 Sridhar Samudrala 2018-04-19 82
:::::: The code at line 67 was first introduced by commit
:::::: 891cac68e9283c9561d0097af77e7189b9752719 net: Introduce generic failover module
:::::: TO: Sridhar Samudrala <sridhar.samudrala@intel.com>
:::::: CC: 0day robot <fengguang.wu@intel.com>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 27072 bytes --]
[-- Attachment #3: Type: text/plain, Size: 183 bytes --]
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 net-next 3/4] virtio_net: Extend virtio to use VF datapath when available
@ 2018-04-22 15:41 ` kbuild test robot
0 siblings, 0 replies; 114+ messages in thread
From: kbuild test robot @ 2018-04-22 15:41 UTC (permalink / raw)
Cc: alexander.h.duyck, virtio-dev, jiri, mst, kubakici, netdev,
virtualization, loseweigh, kbuild-all, sridhar.samudrala, davem
[-- Attachment #1: Type: text/plain, Size: 3173 bytes --]
Hi Sridhar,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on net/master]
[also build test ERROR on v4.17-rc1]
[cannot apply to net-next/master next-20180420]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Sridhar-Samudrala/Enable-virtio_net-to-act-as-a-standby-for-a-passthru-device/20180422-210557
config: i386-randconfig-x071-201816 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All error/warnings (new ones prefixed by >>):
In file included from drivers//net/virtio_net.c:37:0:
>> include/net/failover.h:67:1: error: expected identifier or '(' before '{' token
{
^
>> include/net/failover.h:78:16: warning: 'struct pfailover' declared inside parameter list will not be visible outside of this definition or declaration
struct pfailover **pfailover);
^~~~~~~~~
include/net/failover.h:79:1: error: expected identifier or '(' before '{' token
{
^
>> include/net/failover.h:65:5: warning: 'failover_create' used but never defined
int failover_create(struct net_device *standby_dev,
^~~~~~~~~~~~~~~
include/net/failover.h:77:5: warning: 'failover_register' declared 'static' but never defined [-Wunused-function]
int failover_register(struct net_device *standby_dev, struct failover_ops *ops,
^~~~~~~~~~~~~~~~~
vim +67 include/net/failover.h
891cac68 Sridhar Samudrala 2018-04-19 63
891cac68 Sridhar Samudrala 2018-04-19 64 static inline
891cac68 Sridhar Samudrala 2018-04-19 @65 int failover_create(struct net_device *standby_dev,
891cac68 Sridhar Samudrala 2018-04-19 66 struct failover **pfailover);
891cac68 Sridhar Samudrala 2018-04-19 @67 {
891cac68 Sridhar Samudrala 2018-04-19 68 return 0;
891cac68 Sridhar Samudrala 2018-04-19 69 }
891cac68 Sridhar Samudrala 2018-04-19 70
891cac68 Sridhar Samudrala 2018-04-19 71 static inline
891cac68 Sridhar Samudrala 2018-04-19 72 void failover_destroy(struct failover *failover)
891cac68 Sridhar Samudrala 2018-04-19 73 {
891cac68 Sridhar Samudrala 2018-04-19 74 }
891cac68 Sridhar Samudrala 2018-04-19 75
891cac68 Sridhar Samudrala 2018-04-19 76 static inline
891cac68 Sridhar Samudrala 2018-04-19 77 int failover_register(struct net_device *standby_dev, struct failover_ops *ops,
891cac68 Sridhar Samudrala 2018-04-19 @78 struct pfailover **pfailover);
891cac68 Sridhar Samudrala 2018-04-19 79 {
891cac68 Sridhar Samudrala 2018-04-19 80 return 0;
891cac68 Sridhar Samudrala 2018-04-19 81 }
891cac68 Sridhar Samudrala 2018-04-19 82
:::::: The code at line 67 was first introduced by commit
:::::: 891cac68e9283c9561d0097af77e7189b9752719 net: Introduce generic failover module
:::::: TO: Sridhar Samudrala <sridhar.samudrala@intel.com>
:::::: CC: 0day robot <fengguang.wu@intel.com>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 27072 bytes --]
[-- Attachment #3: Type: text/plain, Size: 183 bytes --]
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 net-next 3/4] virtio_net: Extend virtio to use VF datapath when available
2018-04-20 1:42 ` [virtio-dev] " Sridhar Samudrala
@ 2018-04-22 15:41 ` kbuild test robot
-1 siblings, 0 replies; 114+ messages in thread
From: kbuild test robot @ 2018-04-22 15:41 UTC (permalink / raw)
To: Sridhar Samudrala
Cc: alexander.h.duyck, virtio-dev, jiri, mst, kubakici, netdev,
virtualization, loseweigh, kbuild-all, sridhar.samudrala, davem
[-- Attachment #1: Type: text/plain, Size: 3204 bytes --]
Hi Sridhar,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on net/master]
[also build test WARNING on v4.17-rc1]
[cannot apply to net-next/master next-20180420]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Sridhar-Samudrala/Enable-virtio_net-to-act-as-a-standby-for-a-passthru-device/20180422-210557
config: i386-randconfig-a1-04221429 (attached as .config)
compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All warnings (new ones prefixed by >>):
In file included from drivers//net/virtio_net.c:37:0:
include/net/failover.h:67:1: error: expected identifier or '(' before '{' token
{
^
>> include/net/failover.h:78:16: warning: 'struct pfailover' declared inside parameter list
struct pfailover **pfailover);
^
>> include/net/failover.h:78:16: warning: its scope is only this definition or declaration, which is probably not what you want
include/net/failover.h:79:1: error: expected identifier or '(' before '{' token
{
^
include/net/failover.h:65:5: warning: 'failover_create' used but never defined
int failover_create(struct net_device *standby_dev,
^
include/net/failover.h:77:5: warning: 'failover_register' declared 'static' but never defined [-Wunused-function]
int failover_register(struct net_device *standby_dev, struct failover_ops *ops,
^
vim +78 include/net/failover.h
891cac68 Sridhar Samudrala 2018-04-19 63
891cac68 Sridhar Samudrala 2018-04-19 64 static inline
891cac68 Sridhar Samudrala 2018-04-19 65 int failover_create(struct net_device *standby_dev,
891cac68 Sridhar Samudrala 2018-04-19 66 struct failover **pfailover);
891cac68 Sridhar Samudrala 2018-04-19 @67 {
891cac68 Sridhar Samudrala 2018-04-19 68 return 0;
891cac68 Sridhar Samudrala 2018-04-19 69 }
891cac68 Sridhar Samudrala 2018-04-19 70
891cac68 Sridhar Samudrala 2018-04-19 71 static inline
891cac68 Sridhar Samudrala 2018-04-19 72 void failover_destroy(struct failover *failover)
891cac68 Sridhar Samudrala 2018-04-19 73 {
891cac68 Sridhar Samudrala 2018-04-19 74 }
891cac68 Sridhar Samudrala 2018-04-19 75
891cac68 Sridhar Samudrala 2018-04-19 76 static inline
891cac68 Sridhar Samudrala 2018-04-19 77 int failover_register(struct net_device *standby_dev, struct failover_ops *ops,
891cac68 Sridhar Samudrala 2018-04-19 @78 struct pfailover **pfailover);
891cac68 Sridhar Samudrala 2018-04-19 79 {
891cac68 Sridhar Samudrala 2018-04-19 80 return 0;
891cac68 Sridhar Samudrala 2018-04-19 81 }
891cac68 Sridhar Samudrala 2018-04-19 82
:::::: The code at line 78 was first introduced by commit
:::::: 891cac68e9283c9561d0097af77e7189b9752719 net: Introduce generic failover module
:::::: TO: Sridhar Samudrala <sridhar.samudrala@intel.com>
:::::: CC: 0day robot <fengguang.wu@intel.com>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 29503 bytes --]
[-- Attachment #3: Type: text/plain, Size: 183 bytes --]
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 net-next 3/4] virtio_net: Extend virtio to use VF datapath when available
@ 2018-04-22 15:41 ` kbuild test robot
0 siblings, 0 replies; 114+ messages in thread
From: kbuild test robot @ 2018-04-22 15:41 UTC (permalink / raw)
Cc: alexander.h.duyck, virtio-dev, jiri, mst, kubakici, netdev,
virtualization, loseweigh, kbuild-all, sridhar.samudrala, davem
[-- Attachment #1: Type: text/plain, Size: 3204 bytes --]
Hi Sridhar,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on net/master]
[also build test WARNING on v4.17-rc1]
[cannot apply to net-next/master next-20180420]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Sridhar-Samudrala/Enable-virtio_net-to-act-as-a-standby-for-a-passthru-device/20180422-210557
config: i386-randconfig-a1-04221429 (attached as .config)
compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All warnings (new ones prefixed by >>):
In file included from drivers//net/virtio_net.c:37:0:
include/net/failover.h:67:1: error: expected identifier or '(' before '{' token
{
^
>> include/net/failover.h:78:16: warning: 'struct pfailover' declared inside parameter list
struct pfailover **pfailover);
^
>> include/net/failover.h:78:16: warning: its scope is only this definition or declaration, which is probably not what you want
include/net/failover.h:79:1: error: expected identifier or '(' before '{' token
{
^
include/net/failover.h:65:5: warning: 'failover_create' used but never defined
int failover_create(struct net_device *standby_dev,
^
include/net/failover.h:77:5: warning: 'failover_register' declared 'static' but never defined [-Wunused-function]
int failover_register(struct net_device *standby_dev, struct failover_ops *ops,
^
vim +78 include/net/failover.h
891cac68 Sridhar Samudrala 2018-04-19 63
891cac68 Sridhar Samudrala 2018-04-19 64 static inline
891cac68 Sridhar Samudrala 2018-04-19 65 int failover_create(struct net_device *standby_dev,
891cac68 Sridhar Samudrala 2018-04-19 66 struct failover **pfailover);
891cac68 Sridhar Samudrala 2018-04-19 @67 {
891cac68 Sridhar Samudrala 2018-04-19 68 return 0;
891cac68 Sridhar Samudrala 2018-04-19 69 }
891cac68 Sridhar Samudrala 2018-04-19 70
891cac68 Sridhar Samudrala 2018-04-19 71 static inline
891cac68 Sridhar Samudrala 2018-04-19 72 void failover_destroy(struct failover *failover)
891cac68 Sridhar Samudrala 2018-04-19 73 {
891cac68 Sridhar Samudrala 2018-04-19 74 }
891cac68 Sridhar Samudrala 2018-04-19 75
891cac68 Sridhar Samudrala 2018-04-19 76 static inline
891cac68 Sridhar Samudrala 2018-04-19 77 int failover_register(struct net_device *standby_dev, struct failover_ops *ops,
891cac68 Sridhar Samudrala 2018-04-19 @78 struct pfailover **pfailover);
891cac68 Sridhar Samudrala 2018-04-19 79 {
891cac68 Sridhar Samudrala 2018-04-19 80 return 0;
891cac68 Sridhar Samudrala 2018-04-19 81 }
891cac68 Sridhar Samudrala 2018-04-19 82
:::::: The code at line 78 was first introduced by commit
:::::: 891cac68e9283c9561d0097af77e7189b9752719 net: Introduce generic failover module
:::::: TO: Sridhar Samudrala <sridhar.samudrala@intel.com>
:::::: CC: 0day robot <fengguang.wu@intel.com>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 29503 bytes --]
[-- Attachment #3: Type: text/plain, Size: 183 bytes --]
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 net-next 2/4] net: Introduce generic failover module
2018-04-20 1:42 ` [virtio-dev] " Sridhar Samudrala
@ 2018-04-22 17:06 ` Michael S. Tsirkin
-1 siblings, 0 replies; 114+ messages in thread
From: Michael S. Tsirkin @ 2018-04-22 17:06 UTC (permalink / raw)
To: Sridhar Samudrala
Cc: stephen, davem, netdev, virtualization, virtio-dev,
jesse.brandeburg, alexander.h.duyck, kubakici, jasowang,
loseweigh, jiri
On Thu, Apr 19, 2018 at 06:42:02PM -0700, Sridhar Samudrala wrote:
> +#if IS_ENABLED(CONFIG_NET_FAILOVER)
> +
> +int failover_create(struct net_device *standby_dev,
> + struct failover **pfailover);
Should we rename all these structs net_failover?
It's possible to extend the concept to storage I think.
> +void failover_destroy(struct failover *failover);
> +
> +int failover_register(struct net_device *standby_dev, struct failover_ops *ops,
> + struct failover **pfailover);
> +void failover_unregister(struct failover *failover);
> +
> +int failover_slave_unregister(struct net_device *slave_dev);
> +
> +#else
> +
> +static inline
> +int failover_create(struct net_device *standby_dev,
> + struct failover **pfailover);
> +{
> + return 0;
Does this make callers do something sane?
Shouldn't these return an error?
> +}
> +
> +static inline
> +void failover_destroy(struct failover *failover)
> +{
> +}
> +
> +static inline
> +int failover_register(struct net_device *standby_dev, struct failover_ops *ops,
> + struct pfailover **pfailover);
> +{
> + return 0;
> +}
struct pfailover seems like a typo.
> +
> +static inline
> +void failover_unregister(struct failover *failover)
> +{
> +}
> +
> +static inline
> +int failover_slave_unregister(struct net_device *slave_dev)
> +{
> + return 0;
> +}
Does anyone test return value of unregister?
should this be void?
> +
> +#endif
> +
> +#endif /* _NET_FAILOVER_H */
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 net-next 2/4] net: Introduce generic failover module
2018-04-20 1:42 ` [virtio-dev] " Sridhar Samudrala
` (4 preceding siblings ...)
(?)
@ 2018-04-22 17:06 ` Michael S. Tsirkin
-1 siblings, 0 replies; 114+ messages in thread
From: Michael S. Tsirkin @ 2018-04-22 17:06 UTC (permalink / raw)
To: Sridhar Samudrala
Cc: alexander.h.duyck, virtio-dev, jiri, kubakici, netdev,
virtualization, loseweigh, davem
On Thu, Apr 19, 2018 at 06:42:02PM -0700, Sridhar Samudrala wrote:
> +#if IS_ENABLED(CONFIG_NET_FAILOVER)
> +
> +int failover_create(struct net_device *standby_dev,
> + struct failover **pfailover);
Should we rename all these structs net_failover?
It's possible to extend the concept to storage I think.
> +void failover_destroy(struct failover *failover);
> +
> +int failover_register(struct net_device *standby_dev, struct failover_ops *ops,
> + struct failover **pfailover);
> +void failover_unregister(struct failover *failover);
> +
> +int failover_slave_unregister(struct net_device *slave_dev);
> +
> +#else
> +
> +static inline
> +int failover_create(struct net_device *standby_dev,
> + struct failover **pfailover);
> +{
> + return 0;
Does this make callers do something sane?
Shouldn't these return an error?
> +}
> +
> +static inline
> +void failover_destroy(struct failover *failover)
> +{
> +}
> +
> +static inline
> +int failover_register(struct net_device *standby_dev, struct failover_ops *ops,
> + struct pfailover **pfailover);
> +{
> + return 0;
> +}
struct pfailover seems like a typo.
> +
> +static inline
> +void failover_unregister(struct failover *failover)
> +{
> +}
> +
> +static inline
> +int failover_slave_unregister(struct net_device *slave_dev)
> +{
> + return 0;
> +}
Does anyone test return value of unregister?
should this be void?
> +
> +#endif
> +
> +#endif /* _NET_FAILOVER_H */
^ permalink raw reply [flat|nested] 114+ messages in thread
* [virtio-dev] Re: [PATCH v7 net-next 2/4] net: Introduce generic failover module
@ 2018-04-22 17:06 ` Michael S. Tsirkin
0 siblings, 0 replies; 114+ messages in thread
From: Michael S. Tsirkin @ 2018-04-22 17:06 UTC (permalink / raw)
To: Sridhar Samudrala
Cc: stephen, davem, netdev, virtualization, virtio-dev,
jesse.brandeburg, alexander.h.duyck, kubakici, jasowang,
loseweigh, jiri
On Thu, Apr 19, 2018 at 06:42:02PM -0700, Sridhar Samudrala wrote:
> +#if IS_ENABLED(CONFIG_NET_FAILOVER)
> +
> +int failover_create(struct net_device *standby_dev,
> + struct failover **pfailover);
Should we rename all these structs net_failover?
It's possible to extend the concept to storage I think.
> +void failover_destroy(struct failover *failover);
> +
> +int failover_register(struct net_device *standby_dev, struct failover_ops *ops,
> + struct failover **pfailover);
> +void failover_unregister(struct failover *failover);
> +
> +int failover_slave_unregister(struct net_device *slave_dev);
> +
> +#else
> +
> +static inline
> +int failover_create(struct net_device *standby_dev,
> + struct failover **pfailover);
> +{
> + return 0;
Does this make callers do something sane?
Shouldn't these return an error?
> +}
> +
> +static inline
> +void failover_destroy(struct failover *failover)
> +{
> +}
> +
> +static inline
> +int failover_register(struct net_device *standby_dev, struct failover_ops *ops,
> + struct pfailover **pfailover);
> +{
> + return 0;
> +}
struct pfailover seems like a typo.
> +
> +static inline
> +void failover_unregister(struct failover *failover)
> +{
> +}
> +
> +static inline
> +int failover_slave_unregister(struct net_device *slave_dev)
> +{
> + return 0;
> +}
Does anyone test return value of unregister?
should this be void?
> +
> +#endif
> +
> +#endif /* _NET_FAILOVER_H */
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 net-next 2/4] net: Introduce generic failover module
2018-04-20 1:42 ` [virtio-dev] " Sridhar Samudrala
@ 2018-04-22 18:29 ` kbuild test robot
-1 siblings, 0 replies; 114+ messages in thread
From: kbuild test robot @ 2018-04-22 18:29 UTC (permalink / raw)
To: Sridhar Samudrala
Cc: alexander.h.duyck, virtio-dev, jiri, mst, kubakici, netdev,
virtualization, loseweigh, kbuild-all, sridhar.samudrala, davem
Hi Sridhar,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on net/master]
[also build test WARNING on v4.17-rc1]
[cannot apply to net-next/master next-20180420]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Sridhar-Samudrala/Enable-virtio_net-to-act-as-a-standby-for-a-passthru-device/20180422-210557
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__
sparse warnings: (new ones prefixed by >>)
>> net/core/failover.c:99:36: sparse: incorrect type in argument 1 (different address spaces) @@ expected struct net_device *dev @@ got struct net_devicestruct net_device *dev @@
net/core/failover.c:99:36: expected struct net_device *dev
net/core/failover.c:99:36: got struct net_device [noderef] <asn:4>*standby_dev
net/core/failover.c:102:36: sparse: incorrect type in argument 1 (different address spaces) @@ expected struct net_device *dev @@ got struct net_devicestruct net_device *dev @@
net/core/failover.c:102:36: expected struct net_device *dev
net/core/failover.c:102:36: got struct net_device [noderef] <asn:4>*primary_dev
>> net/core/failover.c:468:12: sparse: context imbalance in 'failover_select_queue' - wrong count at exit
vim +99 net/core/failover.c
58
59 static int failover_slave_join(struct net_device *slave_dev,
60 struct net_device *failover_dev,
61 struct failover_ops *failover_ops)
62 {
63 struct failover_info *finfo;
64 int err, orig_mtu;
65 bool standby;
66
67 if (failover_ops) {
68 if (!failover_ops->slave_join)
69 return -EINVAL;
70
71 return failover_ops->slave_join(slave_dev, failover_dev);
72 }
73
74 if (netif_running(failover_dev)) {
75 err = dev_open(slave_dev);
76 if (err && (err != -EBUSY)) {
77 netdev_err(failover_dev, "Opening slave %s failed err:%d\n",
78 slave_dev->name, err);
79 goto err_dev_open;
80 }
81 }
82
83 /* Align MTU of slave with failover dev */
84 orig_mtu = slave_dev->mtu;
85 err = dev_set_mtu(slave_dev, failover_dev->mtu);
86 if (err) {
87 netdev_err(failover_dev, "unable to change mtu of %s to %u register failed\n",
88 slave_dev->name, failover_dev->mtu);
89 goto err_set_mtu;
90 }
91
92 finfo = netdev_priv(failover_dev);
93 standby = (slave_dev->dev.parent == failover_dev->dev.parent);
94
95 dev_hold(slave_dev);
96
97 if (standby) {
98 rcu_assign_pointer(finfo->standby_dev, slave_dev);
> 99 dev_get_stats(finfo->standby_dev, &finfo->standby_stats);
100 } else {
101 rcu_assign_pointer(finfo->primary_dev, slave_dev);
102 dev_get_stats(finfo->primary_dev, &finfo->primary_stats);
103 failover_dev->min_mtu = slave_dev->min_mtu;
104 failover_dev->max_mtu = slave_dev->max_mtu;
105 }
106
107 netdev_info(failover_dev, "failover slave:%s joined\n",
108 slave_dev->name);
109
110 return 0;
111
112 err_set_mtu:
113 dev_close(slave_dev);
114 err_dev_open:
115 return err;
116 }
117
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 net-next 2/4] net: Introduce generic failover module
@ 2018-04-22 18:29 ` kbuild test robot
0 siblings, 0 replies; 114+ messages in thread
From: kbuild test robot @ 2018-04-22 18:29 UTC (permalink / raw)
Cc: alexander.h.duyck, virtio-dev, jiri, mst, kubakici, netdev,
virtualization, loseweigh, kbuild-all, sridhar.samudrala, davem
Hi Sridhar,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on net/master]
[also build test WARNING on v4.17-rc1]
[cannot apply to net-next/master next-20180420]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Sridhar-Samudrala/Enable-virtio_net-to-act-as-a-standby-for-a-passthru-device/20180422-210557
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__
sparse warnings: (new ones prefixed by >>)
>> net/core/failover.c:99:36: sparse: incorrect type in argument 1 (different address spaces) @@ expected struct net_device *dev @@ got struct net_devicestruct net_device *dev @@
net/core/failover.c:99:36: expected struct net_device *dev
net/core/failover.c:99:36: got struct net_device [noderef] <asn:4>*standby_dev
net/core/failover.c:102:36: sparse: incorrect type in argument 1 (different address spaces) @@ expected struct net_device *dev @@ got struct net_devicestruct net_device *dev @@
net/core/failover.c:102:36: expected struct net_device *dev
net/core/failover.c:102:36: got struct net_device [noderef] <asn:4>*primary_dev
>> net/core/failover.c:468:12: sparse: context imbalance in 'failover_select_queue' - wrong count at exit
vim +99 net/core/failover.c
58
59 static int failover_slave_join(struct net_device *slave_dev,
60 struct net_device *failover_dev,
61 struct failover_ops *failover_ops)
62 {
63 struct failover_info *finfo;
64 int err, orig_mtu;
65 bool standby;
66
67 if (failover_ops) {
68 if (!failover_ops->slave_join)
69 return -EINVAL;
70
71 return failover_ops->slave_join(slave_dev, failover_dev);
72 }
73
74 if (netif_running(failover_dev)) {
75 err = dev_open(slave_dev);
76 if (err && (err != -EBUSY)) {
77 netdev_err(failover_dev, "Opening slave %s failed err:%d\n",
78 slave_dev->name, err);
79 goto err_dev_open;
80 }
81 }
82
83 /* Align MTU of slave with failover dev */
84 orig_mtu = slave_dev->mtu;
85 err = dev_set_mtu(slave_dev, failover_dev->mtu);
86 if (err) {
87 netdev_err(failover_dev, "unable to change mtu of %s to %u register failed\n",
88 slave_dev->name, failover_dev->mtu);
89 goto err_set_mtu;
90 }
91
92 finfo = netdev_priv(failover_dev);
93 standby = (slave_dev->dev.parent == failover_dev->dev.parent);
94
95 dev_hold(slave_dev);
96
97 if (standby) {
98 rcu_assign_pointer(finfo->standby_dev, slave_dev);
> 99 dev_get_stats(finfo->standby_dev, &finfo->standby_stats);
100 } else {
101 rcu_assign_pointer(finfo->primary_dev, slave_dev);
102 dev_get_stats(finfo->primary_dev, &finfo->primary_stats);
103 failover_dev->min_mtu = slave_dev->min_mtu;
104 failover_dev->max_mtu = slave_dev->max_mtu;
105 }
106
107 netdev_info(failover_dev, "failover slave:%s joined\n",
108 slave_dev->name);
109
110 return 0;
111
112 err_set_mtu:
113 dev_close(slave_dev);
114 err_dev_open:
115 return err;
116 }
117
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 net-next 4/4] netvsc: refactor notifier/event handling code to use the failover framework
2018-04-20 16:00 ` Jiri Pirko
@ 2018-04-23 17:04 ` Stephen Hemminger
2018-04-23 17:24 ` Michael S. Tsirkin
` (3 more replies)
2018-04-23 17:04 ` Stephen Hemminger
1 sibling, 4 replies; 114+ messages in thread
From: Stephen Hemminger @ 2018-04-23 17:04 UTC (permalink / raw)
To: Jiri Pirko
Cc: Sridhar Samudrala, mst, davem, netdev, virtualization,
virtio-dev, jesse.brandeburg, alexander.h.duyck, kubakici,
jasowang, loseweigh
On Fri, 20 Apr 2018 18:00:58 +0200
Jiri Pirko <jiri@resnulli.us> wrote:
> Fri, Apr 20, 2018 at 05:28:02PM CEST, stephen@networkplumber.org wrote:
> >On Thu, 19 Apr 2018 18:42:04 -0700
> >Sridhar Samudrala <sridhar.samudrala@intel.com> wrote:
> >
> >> Use the registration/notification framework supported by the generic
> >> failover infrastructure.
> >>
> >> Signed-off-by: Sridhar Samudrala <sridhar.samudrala@intel.com>
> >
> >Do what you want to other devices but leave netvsc alone.
> >Adding these failover ops does not reduce the code size, and really is
> >no benefit. The netvsc device driver needs to be backported to several
> >other distributions and doing this makes that harder.
>
> We should not care about the backport burden when we are trying to make
> things right. And things are not right. The current netvsc approach is
> just plain wrong shortcut. It should have been done in a generic way
> from the very beginning. We are just trying to fix this situation.
>
> Moreover, I believe that part of the fix is to convert netvsc to 3
> netdev solution too. 2 netdev model is wrong.
>
>
> >
> >I will NAK patches to change to common code for netvsc especially the
> >three device model. MS worked hard with distro vendors to support transparent
> >mode, ans we really can't have a new model; or do backport.
> >
> >Plus, DPDK is now dependent on existing model.
>
> Sorry, but nobody here cares about dpdk or other similar oddities.
The network device model is a userspace API, and DPDK is a userspace application.
You can't go breaking userspace even if you don't like the application.
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 net-next 4/4] netvsc: refactor notifier/event handling code to use the failover framework
2018-04-20 16:00 ` Jiri Pirko
2018-04-23 17:04 ` Stephen Hemminger
@ 2018-04-23 17:04 ` Stephen Hemminger
1 sibling, 0 replies; 114+ messages in thread
From: Stephen Hemminger @ 2018-04-23 17:04 UTC (permalink / raw)
To: Jiri Pirko
Cc: alexander.h.duyck, virtio-dev, mst, kubakici, Sridhar Samudrala,
virtualization, loseweigh, netdev, davem
On Fri, 20 Apr 2018 18:00:58 +0200
Jiri Pirko <jiri@resnulli.us> wrote:
> Fri, Apr 20, 2018 at 05:28:02PM CEST, stephen@networkplumber.org wrote:
> >On Thu, 19 Apr 2018 18:42:04 -0700
> >Sridhar Samudrala <sridhar.samudrala@intel.com> wrote:
> >
> >> Use the registration/notification framework supported by the generic
> >> failover infrastructure.
> >>
> >> Signed-off-by: Sridhar Samudrala <sridhar.samudrala@intel.com>
> >
> >Do what you want to other devices but leave netvsc alone.
> >Adding these failover ops does not reduce the code size, and really is
> >no benefit. The netvsc device driver needs to be backported to several
> >other distributions and doing this makes that harder.
>
> We should not care about the backport burden when we are trying to make
> things right. And things are not right. The current netvsc approach is
> just plain wrong shortcut. It should have been done in a generic way
> from the very beginning. We are just trying to fix this situation.
>
> Moreover, I believe that part of the fix is to convert netvsc to 3
> netdev solution too. 2 netdev model is wrong.
>
>
> >
> >I will NAK patches to change to common code for netvsc especially the
> >three device model. MS worked hard with distro vendors to support transparent
> >mode, ans we really can't have a new model; or do backport.
> >
> >Plus, DPDK is now dependent on existing model.
>
> Sorry, but nobody here cares about dpdk or other similar oddities.
The network device model is a userspace API, and DPDK is a userspace application.
You can't go breaking userspace even if you don't like the application.
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 net-next 2/4] net: Introduce generic failover module
2018-04-22 17:06 ` [virtio-dev] " Michael S. Tsirkin
@ 2018-04-23 17:21 ` Samudrala, Sridhar
-1 siblings, 0 replies; 114+ messages in thread
From: Samudrala, Sridhar @ 2018-04-23 17:21 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: alexander.h.duyck, virtio-dev, jiri, kubakici, netdev,
virtualization, loseweigh, davem
On 4/22/2018 10:06 AM, Michael S. Tsirkin wrote:
> On Thu, Apr 19, 2018 at 06:42:02PM -0700, Sridhar Samudrala wrote:
>> +#if IS_ENABLED(CONFIG_NET_FAILOVER)
>> +
>> +int failover_create(struct net_device *standby_dev,
>> + struct failover **pfailover);
> Should we rename all these structs net_failover?
> It's possible to extend the concept to storage I think.
We could, the only downside is that the names become longer. i think we need
to change the filenames and the function names also to be consistent.
>
>> +void failover_destroy(struct failover *failover);
>> +
>> +int failover_register(struct net_device *standby_dev, struct failover_ops *ops,
>> + struct failover **pfailover);
>> +void failover_unregister(struct failover *failover);
>> +
>> +int failover_slave_unregister(struct net_device *slave_dev);
>> +
>> +#else
>> +
>> +static inline
>> +int failover_create(struct net_device *standby_dev,
>> + struct failover **pfailover);
>> +{
>> + return 0;
> Does this make callers do something sane?
> Shouldn't these return an error?
Yes. i think i should return -EOPNOTSUPP here, so that we fail
when CONFIG_NET_FAILOVER is not enabled and the virtio-net driver is trying
to create a failover device.
>> +}
>> +
>> +static inline
>> +void failover_destroy(struct failover *failover)
>> +{
>> +}
>> +
>> +static inline
>> +int failover_register(struct net_device *standby_dev, struct failover_ops *ops,
>> + struct pfailover **pfailover);
>> +{
>> + return 0;
>> +}
> struct pfailover seems like a typo.
yes. will also change the return to -EOPNOTSUPP
>
>> +
>> +static inline
>> +void failover_unregister(struct failover *failover)
>> +{
>> +}
>> +
>> +static inline
>> +int failover_slave_unregister(struct net_device *slave_dev)
>> +{
>> + return 0;
>> +}
> Does anyone test return value of unregister?
> should this be void?
yes. can be changed to void.
>
>> +
>> +#endif
>> +
>> +#endif /* _NET_FAILOVER_H */
^ permalink raw reply [flat|nested] 114+ messages in thread
* [virtio-dev] Re: [PATCH v7 net-next 2/4] net: Introduce generic failover module
@ 2018-04-23 17:21 ` Samudrala, Sridhar
0 siblings, 0 replies; 114+ messages in thread
From: Samudrala, Sridhar @ 2018-04-23 17:21 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: stephen, davem, netdev, virtualization, virtio-dev,
jesse.brandeburg, alexander.h.duyck, kubakici, jasowang,
loseweigh, jiri
On 4/22/2018 10:06 AM, Michael S. Tsirkin wrote:
> On Thu, Apr 19, 2018 at 06:42:02PM -0700, Sridhar Samudrala wrote:
>> +#if IS_ENABLED(CONFIG_NET_FAILOVER)
>> +
>> +int failover_create(struct net_device *standby_dev,
>> + struct failover **pfailover);
> Should we rename all these structs net_failover?
> It's possible to extend the concept to storage I think.
We could, the only downside is that the names become longer. i think we need
to change the filenames and the function names also to be consistent.
>
>> +void failover_destroy(struct failover *failover);
>> +
>> +int failover_register(struct net_device *standby_dev, struct failover_ops *ops,
>> + struct failover **pfailover);
>> +void failover_unregister(struct failover *failover);
>> +
>> +int failover_slave_unregister(struct net_device *slave_dev);
>> +
>> +#else
>> +
>> +static inline
>> +int failover_create(struct net_device *standby_dev,
>> + struct failover **pfailover);
>> +{
>> + return 0;
> Does this make callers do something sane?
> Shouldn't these return an error?
Yes. i think i should return -EOPNOTSUPP here, so that we fail
when CONFIG_NET_FAILOVER is not enabled and the virtio-net driver is trying
to create a failover device.
>> +}
>> +
>> +static inline
>> +void failover_destroy(struct failover *failover)
>> +{
>> +}
>> +
>> +static inline
>> +int failover_register(struct net_device *standby_dev, struct failover_ops *ops,
>> + struct pfailover **pfailover);
>> +{
>> + return 0;
>> +}
> struct pfailover seems like a typo.
yes. will also change the return to -EOPNOTSUPP
>
>> +
>> +static inline
>> +void failover_unregister(struct failover *failover)
>> +{
>> +}
>> +
>> +static inline
>> +int failover_slave_unregister(struct net_device *slave_dev)
>> +{
>> + return 0;
>> +}
> Does anyone test return value of unregister?
> should this be void?
yes. can be changed to void.
>
>> +
>> +#endif
>> +
>> +#endif /* _NET_FAILOVER_H */
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 net-next 4/4] netvsc: refactor notifier/event handling code to use the failover framework
2018-04-23 17:04 ` Stephen Hemminger
@ 2018-04-23 17:24 ` Michael S. Tsirkin
2018-04-23 17:24 ` [virtio-dev] " Michael S. Tsirkin
` (2 subsequent siblings)
3 siblings, 0 replies; 114+ messages in thread
From: Michael S. Tsirkin @ 2018-04-23 17:24 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Jiri Pirko, Sridhar Samudrala, davem, netdev, virtualization,
virtio-dev, jesse.brandeburg, alexander.h.duyck, kubakici,
jasowang, loseweigh
On Mon, Apr 23, 2018 at 10:04:06AM -0700, Stephen Hemminger wrote:
> > >
> > >I will NAK patches to change to common code for netvsc especially the
> > >three device model. MS worked hard with distro vendors to support transparent
> > >mode, ans we really can't have a new model; or do backport.
> > >
> > >Plus, DPDK is now dependent on existing model.
> >
> > Sorry, but nobody here cares about dpdk or other similar oddities.
>
> The network device model is a userspace API, and DPDK is a userspace application.
It is userspace but are you sure dpdk is actually poking at netdevs?
AFAIK it's normally banging device registers directly.
> You can't go breaking userspace even if you don't like the application.
Could you please explain how is the proposed patchset breaking
userspace? Ignoring DPDK for now, I don't think it changes the userspace
API at all.
--
MST
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 net-next 4/4] netvsc: refactor notifier/event handling code to use the failover framework
2018-04-23 17:04 ` Stephen Hemminger
@ 2018-04-23 17:24 ` Michael S. Tsirkin
2018-04-23 17:24 ` [virtio-dev] " Michael S. Tsirkin
` (2 subsequent siblings)
3 siblings, 0 replies; 114+ messages in thread
From: Michael S. Tsirkin @ 2018-04-23 17:24 UTC (permalink / raw)
To: Stephen Hemminger
Cc: alexander.h.duyck, virtio-dev, Jiri Pirko, kubakici,
Sridhar Samudrala, virtualization, loseweigh, netdev, davem
On Mon, Apr 23, 2018 at 10:04:06AM -0700, Stephen Hemminger wrote:
> > >
> > >I will NAK patches to change to common code for netvsc especially the
> > >three device model. MS worked hard with distro vendors to support transparent
> > >mode, ans we really can't have a new model; or do backport.
> > >
> > >Plus, DPDK is now dependent on existing model.
> >
> > Sorry, but nobody here cares about dpdk or other similar oddities.
>
> The network device model is a userspace API, and DPDK is a userspace application.
It is userspace but are you sure dpdk is actually poking at netdevs?
AFAIK it's normally banging device registers directly.
> You can't go breaking userspace even if you don't like the application.
Could you please explain how is the proposed patchset breaking
userspace? Ignoring DPDK for now, I don't think it changes the userspace
API at all.
--
MST
^ permalink raw reply [flat|nested] 114+ messages in thread
* [virtio-dev] Re: [PATCH v7 net-next 4/4] netvsc: refactor notifier/event handling code to use the failover framework
@ 2018-04-23 17:24 ` Michael S. Tsirkin
0 siblings, 0 replies; 114+ messages in thread
From: Michael S. Tsirkin @ 2018-04-23 17:24 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Jiri Pirko, Sridhar Samudrala, davem, netdev, virtualization,
virtio-dev, jesse.brandeburg, alexander.h.duyck, kubakici,
jasowang, loseweigh
On Mon, Apr 23, 2018 at 10:04:06AM -0700, Stephen Hemminger wrote:
> > >
> > >I will NAK patches to change to common code for netvsc especially the
> > >three device model. MS worked hard with distro vendors to support transparent
> > >mode, ans we really can't have a new model; or do backport.
> > >
> > >Plus, DPDK is now dependent on existing model.
> >
> > Sorry, but nobody here cares about dpdk or other similar oddities.
>
> The network device model is a userspace API, and DPDK is a userspace application.
It is userspace but are you sure dpdk is actually poking at netdevs?
AFAIK it's normally banging device registers directly.
> You can't go breaking userspace even if you don't like the application.
Could you please explain how is the proposed patchset breaking
userspace? Ignoring DPDK for now, I don't think it changes the userspace
API at all.
--
MST
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 net-next 4/4] netvsc: refactor notifier/event handling code to use the failover framework
2018-04-23 17:04 ` Stephen Hemminger
2018-04-23 17:24 ` Michael S. Tsirkin
2018-04-23 17:24 ` [virtio-dev] " Michael S. Tsirkin
@ 2018-04-23 17:25 ` Jiri Pirko
2018-04-23 17:25 ` Jiri Pirko
3 siblings, 0 replies; 114+ messages in thread
From: Jiri Pirko @ 2018-04-23 17:25 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Sridhar Samudrala, mst, davem, netdev, virtualization,
virtio-dev, jesse.brandeburg, alexander.h.duyck, kubakici,
jasowang, loseweigh
Mon, Apr 23, 2018 at 07:04:06PM CEST, stephen@networkplumber.org wrote:
>On Fri, 20 Apr 2018 18:00:58 +0200
>Jiri Pirko <jiri@resnulli.us> wrote:
>
>> Fri, Apr 20, 2018 at 05:28:02PM CEST, stephen@networkplumber.org wrote:
>> >On Thu, 19 Apr 2018 18:42:04 -0700
>> >Sridhar Samudrala <sridhar.samudrala@intel.com> wrote:
>> >
>> >> Use the registration/notification framework supported by the generic
>> >> failover infrastructure.
>> >>
>> >> Signed-off-by: Sridhar Samudrala <sridhar.samudrala@intel.com>
>> >
>> >Do what you want to other devices but leave netvsc alone.
>> >Adding these failover ops does not reduce the code size, and really is
>> >no benefit. The netvsc device driver needs to be backported to several
>> >other distributions and doing this makes that harder.
>>
>> We should not care about the backport burden when we are trying to make
>> things right. And things are not right. The current netvsc approach is
>> just plain wrong shortcut. It should have been done in a generic way
>> from the very beginning. We are just trying to fix this situation.
>>
>> Moreover, I believe that part of the fix is to convert netvsc to 3
>> netdev solution too. 2 netdev model is wrong.
>>
>>
>> >
>> >I will NAK patches to change to common code for netvsc especially the
>> >three device model. MS worked hard with distro vendors to support transparent
>> >mode, ans we really can't have a new model; or do backport.
>> >
>> >Plus, DPDK is now dependent on existing model.
>>
>> Sorry, but nobody here cares about dpdk or other similar oddities.
>
>The network device model is a userspace API, and DPDK is a userspace application.
>You can't go breaking userspace even if you don't like the application.
I don't understand how you can break anything by exposing
just-another-netdevice. If you break it, it is already broken...
And how you can break anything in userspace by doing refactoring inside
the kernel is puzzling me even more...
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 net-next 4/4] netvsc: refactor notifier/event handling code to use the failover framework
2018-04-23 17:04 ` Stephen Hemminger
` (2 preceding siblings ...)
2018-04-23 17:25 ` Jiri Pirko
@ 2018-04-23 17:25 ` Jiri Pirko
3 siblings, 0 replies; 114+ messages in thread
From: Jiri Pirko @ 2018-04-23 17:25 UTC (permalink / raw)
To: Stephen Hemminger
Cc: alexander.h.duyck, virtio-dev, mst, kubakici, Sridhar Samudrala,
virtualization, loseweigh, netdev, davem
Mon, Apr 23, 2018 at 07:04:06PM CEST, stephen@networkplumber.org wrote:
>On Fri, 20 Apr 2018 18:00:58 +0200
>Jiri Pirko <jiri@resnulli.us> wrote:
>
>> Fri, Apr 20, 2018 at 05:28:02PM CEST, stephen@networkplumber.org wrote:
>> >On Thu, 19 Apr 2018 18:42:04 -0700
>> >Sridhar Samudrala <sridhar.samudrala@intel.com> wrote:
>> >
>> >> Use the registration/notification framework supported by the generic
>> >> failover infrastructure.
>> >>
>> >> Signed-off-by: Sridhar Samudrala <sridhar.samudrala@intel.com>
>> >
>> >Do what you want to other devices but leave netvsc alone.
>> >Adding these failover ops does not reduce the code size, and really is
>> >no benefit. The netvsc device driver needs to be backported to several
>> >other distributions and doing this makes that harder.
>>
>> We should not care about the backport burden when we are trying to make
>> things right. And things are not right. The current netvsc approach is
>> just plain wrong shortcut. It should have been done in a generic way
>> from the very beginning. We are just trying to fix this situation.
>>
>> Moreover, I believe that part of the fix is to convert netvsc to 3
>> netdev solution too. 2 netdev model is wrong.
>>
>>
>> >
>> >I will NAK patches to change to common code for netvsc especially the
>> >three device model. MS worked hard with distro vendors to support transparent
>> >mode, ans we really can't have a new model; or do backport.
>> >
>> >Plus, DPDK is now dependent on existing model.
>>
>> Sorry, but nobody here cares about dpdk or other similar oddities.
>
>The network device model is a userspace API, and DPDK is a userspace application.
>You can't go breaking userspace even if you don't like the application.
I don't understand how you can break anything by exposing
just-another-netdevice. If you break it, it is already broken...
And how you can break anything in userspace by doing refactoring inside
the kernel is puzzling me even more...
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 net-next 4/4] netvsc: refactor notifier/event handling code to use the failover framework
2018-04-23 17:24 ` [virtio-dev] " Michael S. Tsirkin
(?)
@ 2018-04-23 17:44 ` Stephen Hemminger
2018-04-23 17:56 ` Michael S. Tsirkin
2018-04-23 17:56 ` [virtio-dev] " Michael S. Tsirkin
-1 siblings, 2 replies; 114+ messages in thread
From: Stephen Hemminger @ 2018-04-23 17:44 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Jiri Pirko, Sridhar Samudrala, davem, netdev, virtualization,
virtio-dev, jesse.brandeburg, alexander.h.duyck, kubakici,
jasowang, loseweigh
On Mon, 23 Apr 2018 20:24:56 +0300
"Michael S. Tsirkin" <mst@redhat.com> wrote:
> On Mon, Apr 23, 2018 at 10:04:06AM -0700, Stephen Hemminger wrote:
> > > >
> > > >I will NAK patches to change to common code for netvsc especially the
> > > >three device model. MS worked hard with distro vendors to support transparent
> > > >mode, ans we really can't have a new model; or do backport.
> > > >
> > > >Plus, DPDK is now dependent on existing model.
> > >
> > > Sorry, but nobody here cares about dpdk or other similar oddities.
> >
> > The network device model is a userspace API, and DPDK is a userspace application.
>
> It is userspace but are you sure dpdk is actually poking at netdevs?
> AFAIK it's normally banging device registers directly.
>
> > You can't go breaking userspace even if you don't like the application.
>
> Could you please explain how is the proposed patchset breaking
> userspace? Ignoring DPDK for now, I don't think it changes the userspace
> API at all.
>
The DPDK has a device driver vdev_netvsc which scans the Linux network devices
to look for Linux netvsc device and the paired VF device and setup the
DPDK environment. This setup creates a DPDK failsafe (bondingish) instance
and sets up TAP support over the Linux netvsc device as well as the Mellanox
VF device.
So it depends on existing 2 device model. You can't go to a 3 device model
or start hiding devices from userspace.
Also, I am working on associating netvsc and VF device based on serial number
rather than MAC address. The serial number is how Windows works now, and it makes
sense for Linux and Windows to use the same mechanism if possible.
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 net-next 4/4] netvsc: refactor notifier/event handling code to use the failover framework
2018-04-23 17:24 ` [virtio-dev] " Michael S. Tsirkin
(?)
(?)
@ 2018-04-23 17:44 ` Stephen Hemminger
-1 siblings, 0 replies; 114+ messages in thread
From: Stephen Hemminger @ 2018-04-23 17:44 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: alexander.h.duyck, virtio-dev, Jiri Pirko, kubakici,
Sridhar Samudrala, virtualization, loseweigh, netdev, davem
On Mon, 23 Apr 2018 20:24:56 +0300
"Michael S. Tsirkin" <mst@redhat.com> wrote:
> On Mon, Apr 23, 2018 at 10:04:06AM -0700, Stephen Hemminger wrote:
> > > >
> > > >I will NAK patches to change to common code for netvsc especially the
> > > >three device model. MS worked hard with distro vendors to support transparent
> > > >mode, ans we really can't have a new model; or do backport.
> > > >
> > > >Plus, DPDK is now dependent on existing model.
> > >
> > > Sorry, but nobody here cares about dpdk or other similar oddities.
> >
> > The network device model is a userspace API, and DPDK is a userspace application.
>
> It is userspace but are you sure dpdk is actually poking at netdevs?
> AFAIK it's normally banging device registers directly.
>
> > You can't go breaking userspace even if you don't like the application.
>
> Could you please explain how is the proposed patchset breaking
> userspace? Ignoring DPDK for now, I don't think it changes the userspace
> API at all.
>
The DPDK has a device driver vdev_netvsc which scans the Linux network devices
to look for Linux netvsc device and the paired VF device and setup the
DPDK environment. This setup creates a DPDK failsafe (bondingish) instance
and sets up TAP support over the Linux netvsc device as well as the Mellanox
VF device.
So it depends on existing 2 device model. You can't go to a 3 device model
or start hiding devices from userspace.
Also, I am working on associating netvsc and VF device based on serial number
rather than MAC address. The serial number is how Windows works now, and it makes
sense for Linux and Windows to use the same mechanism if possible.
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 net-next 4/4] netvsc: refactor notifier/event handling code to use the failover framework
2018-04-23 17:44 ` Stephen Hemminger
@ 2018-04-23 17:56 ` Michael S. Tsirkin
2018-04-23 17:56 ` [virtio-dev] " Michael S. Tsirkin
1 sibling, 0 replies; 114+ messages in thread
From: Michael S. Tsirkin @ 2018-04-23 17:56 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Jiri Pirko, Sridhar Samudrala, davem, netdev, virtualization,
virtio-dev, jesse.brandeburg, alexander.h.duyck, kubakici,
jasowang, loseweigh
On Mon, Apr 23, 2018 at 10:44:40AM -0700, Stephen Hemminger wrote:
> On Mon, 23 Apr 2018 20:24:56 +0300
> "Michael S. Tsirkin" <mst@redhat.com> wrote:
>
> > On Mon, Apr 23, 2018 at 10:04:06AM -0700, Stephen Hemminger wrote:
> > > > >
> > > > >I will NAK patches to change to common code for netvsc especially the
> > > > >three device model. MS worked hard with distro vendors to support transparent
> > > > >mode, ans we really can't have a new model; or do backport.
> > > > >
> > > > >Plus, DPDK is now dependent on existing model.
> > > >
> > > > Sorry, but nobody here cares about dpdk or other similar oddities.
> > >
> > > The network device model is a userspace API, and DPDK is a userspace application.
> >
> > It is userspace but are you sure dpdk is actually poking at netdevs?
> > AFAIK it's normally banging device registers directly.
> >
> > > You can't go breaking userspace even if you don't like the application.
> >
> > Could you please explain how is the proposed patchset breaking
> > userspace? Ignoring DPDK for now, I don't think it changes the userspace
> > API at all.
> >
>
> The DPDK has a device driver vdev_netvsc which scans the Linux network devices
> to look for Linux netvsc device and the paired VF device and setup the
> DPDK environment. This setup creates a DPDK failsafe (bondingish) instance
> and sets up TAP support over the Linux netvsc device as well as the Mellanox
> VF device.
>
> So it depends on existing 2 device model. You can't go to a 3 device model
> or start hiding devices from userspace.
Okay so how does the existing patch break that? IIUC does not go to
a 3 device model since netvsc calls failover_register directly.
> Also, I am working on associating netvsc and VF device based on serial number
> rather than MAC address. The serial number is how Windows works now, and it makes
> sense for Linux and Windows to use the same mechanism if possible.
Maybe we should support same for virtio ...
Which serial do you mean? From vpd?
I guess you will want to keep supporting MAC for old hypervisors?
It all seems like a reasonable thing to support in the generic core.
--
MST
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 net-next 4/4] netvsc: refactor notifier/event handling code to use the failover framework
2018-04-23 17:44 ` Stephen Hemminger
@ 2018-04-23 17:56 ` Michael S. Tsirkin
2018-04-23 17:56 ` [virtio-dev] " Michael S. Tsirkin
1 sibling, 0 replies; 114+ messages in thread
From: Michael S. Tsirkin @ 2018-04-23 17:56 UTC (permalink / raw)
To: Stephen Hemminger
Cc: alexander.h.duyck, virtio-dev, Jiri Pirko, kubakici,
Sridhar Samudrala, virtualization, loseweigh, netdev, davem
On Mon, Apr 23, 2018 at 10:44:40AM -0700, Stephen Hemminger wrote:
> On Mon, 23 Apr 2018 20:24:56 +0300
> "Michael S. Tsirkin" <mst@redhat.com> wrote:
>
> > On Mon, Apr 23, 2018 at 10:04:06AM -0700, Stephen Hemminger wrote:
> > > > >
> > > > >I will NAK patches to change to common code for netvsc especially the
> > > > >three device model. MS worked hard with distro vendors to support transparent
> > > > >mode, ans we really can't have a new model; or do backport.
> > > > >
> > > > >Plus, DPDK is now dependent on existing model.
> > > >
> > > > Sorry, but nobody here cares about dpdk or other similar oddities.
> > >
> > > The network device model is a userspace API, and DPDK is a userspace application.
> >
> > It is userspace but are you sure dpdk is actually poking at netdevs?
> > AFAIK it's normally banging device registers directly.
> >
> > > You can't go breaking userspace even if you don't like the application.
> >
> > Could you please explain how is the proposed patchset breaking
> > userspace? Ignoring DPDK for now, I don't think it changes the userspace
> > API at all.
> >
>
> The DPDK has a device driver vdev_netvsc which scans the Linux network devices
> to look for Linux netvsc device and the paired VF device and setup the
> DPDK environment. This setup creates a DPDK failsafe (bondingish) instance
> and sets up TAP support over the Linux netvsc device as well as the Mellanox
> VF device.
>
> So it depends on existing 2 device model. You can't go to a 3 device model
> or start hiding devices from userspace.
Okay so how does the existing patch break that? IIUC does not go to
a 3 device model since netvsc calls failover_register directly.
> Also, I am working on associating netvsc and VF device based on serial number
> rather than MAC address. The serial number is how Windows works now, and it makes
> sense for Linux and Windows to use the same mechanism if possible.
Maybe we should support same for virtio ...
Which serial do you mean? From vpd?
I guess you will want to keep supporting MAC for old hypervisors?
It all seems like a reasonable thing to support in the generic core.
--
MST
^ permalink raw reply [flat|nested] 114+ messages in thread
* [virtio-dev] Re: [PATCH v7 net-next 4/4] netvsc: refactor notifier/event handling code to use the failover framework
@ 2018-04-23 17:56 ` Michael S. Tsirkin
0 siblings, 0 replies; 114+ messages in thread
From: Michael S. Tsirkin @ 2018-04-23 17:56 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Jiri Pirko, Sridhar Samudrala, davem, netdev, virtualization,
virtio-dev, jesse.brandeburg, alexander.h.duyck, kubakici,
jasowang, loseweigh
On Mon, Apr 23, 2018 at 10:44:40AM -0700, Stephen Hemminger wrote:
> On Mon, 23 Apr 2018 20:24:56 +0300
> "Michael S. Tsirkin" <mst@redhat.com> wrote:
>
> > On Mon, Apr 23, 2018 at 10:04:06AM -0700, Stephen Hemminger wrote:
> > > > >
> > > > >I will NAK patches to change to common code for netvsc especially the
> > > > >three device model. MS worked hard with distro vendors to support transparent
> > > > >mode, ans we really can't have a new model; or do backport.
> > > > >
> > > > >Plus, DPDK is now dependent on existing model.
> > > >
> > > > Sorry, but nobody here cares about dpdk or other similar oddities.
> > >
> > > The network device model is a userspace API, and DPDK is a userspace application.
> >
> > It is userspace but are you sure dpdk is actually poking at netdevs?
> > AFAIK it's normally banging device registers directly.
> >
> > > You can't go breaking userspace even if you don't like the application.
> >
> > Could you please explain how is the proposed patchset breaking
> > userspace? Ignoring DPDK for now, I don't think it changes the userspace
> > API at all.
> >
>
> The DPDK has a device driver vdev_netvsc which scans the Linux network devices
> to look for Linux netvsc device and the paired VF device and setup the
> DPDK environment. This setup creates a DPDK failsafe (bondingish) instance
> and sets up TAP support over the Linux netvsc device as well as the Mellanox
> VF device.
>
> So it depends on existing 2 device model. You can't go to a 3 device model
> or start hiding devices from userspace.
Okay so how does the existing patch break that? IIUC does not go to
a 3 device model since netvsc calls failover_register directly.
> Also, I am working on associating netvsc and VF device based on serial number
> rather than MAC address. The serial number is how Windows works now, and it makes
> sense for Linux and Windows to use the same mechanism if possible.
Maybe we should support same for virtio ...
Which serial do you mean? From vpd?
I guess you will want to keep supporting MAC for old hypervisors?
It all seems like a reasonable thing to support in the generic core.
--
MST
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 net-next 4/4] netvsc: refactor notifier/event handling code to use the failover framework
2018-04-23 17:56 ` [virtio-dev] " Michael S. Tsirkin
@ 2018-04-23 19:44 ` Siwei Liu
-1 siblings, 0 replies; 114+ messages in thread
From: Siwei Liu @ 2018-04-23 19:44 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Stephen Hemminger, Jiri Pirko, Sridhar Samudrala, David Miller,
Netdev, virtualization, virtio-dev, Brandeburg, Jesse,
Alexander Duyck, Jakub Kicinski, Jason Wang
On Mon, Apr 23, 2018 at 10:56 AM, Michael S. Tsirkin <mst@redhat.com> wrote:
> On Mon, Apr 23, 2018 at 10:44:40AM -0700, Stephen Hemminger wrote:
>> On Mon, 23 Apr 2018 20:24:56 +0300
>> "Michael S. Tsirkin" <mst@redhat.com> wrote:
>>
>> > On Mon, Apr 23, 2018 at 10:04:06AM -0700, Stephen Hemminger wrote:
>> > > > >
>> > > > >I will NAK patches to change to common code for netvsc especially the
>> > > > >three device model. MS worked hard with distro vendors to support transparent
>> > > > >mode, ans we really can't have a new model; or do backport.
>> > > > >
>> > > > >Plus, DPDK is now dependent on existing model.
>> > > >
>> > > > Sorry, but nobody here cares about dpdk or other similar oddities.
>> > >
>> > > The network device model is a userspace API, and DPDK is a userspace application.
>> >
>> > It is userspace but are you sure dpdk is actually poking at netdevs?
>> > AFAIK it's normally banging device registers directly.
>> >
>> > > You can't go breaking userspace even if you don't like the application.
>> >
>> > Could you please explain how is the proposed patchset breaking
>> > userspace? Ignoring DPDK for now, I don't think it changes the userspace
>> > API at all.
>> >
>>
>> The DPDK has a device driver vdev_netvsc which scans the Linux network devices
>> to look for Linux netvsc device and the paired VF device and setup the
>> DPDK environment. This setup creates a DPDK failsafe (bondingish) instance
>> and sets up TAP support over the Linux netvsc device as well as the Mellanox
>> VF device.
>>
>> So it depends on existing 2 device model. You can't go to a 3 device model
>> or start hiding devices from userspace.
>
> Okay so how does the existing patch break that? IIUC does not go to
> a 3 device model since netvsc calls failover_register directly.
>
>> Also, I am working on associating netvsc and VF device based on serial number
>> rather than MAC address. The serial number is how Windows works now, and it makes
>> sense for Linux and Windows to use the same mechanism if possible.
>
> Maybe we should support same for virtio ...
> Which serial do you mean? From vpd?
>
> I guess you will want to keep supporting MAC for old hypervisors?
>
> It all seems like a reasonable thing to support in the generic core.
That's the reason why I chose explicit identifier rather than rely on
MAC address to bind/pair a device. MAC address can change. Even if it
can't, malicious guest user can fake MAC address to skip binding.
-Siwei
>
> --
> MST
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 net-next 4/4] netvsc: refactor notifier/event handling code to use the failover framework
2018-04-23 17:56 ` [virtio-dev] " Michael S. Tsirkin
(?)
@ 2018-04-23 19:44 ` Siwei Liu
-1 siblings, 0 replies; 114+ messages in thread
From: Siwei Liu @ 2018-04-23 19:44 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Alexander Duyck, virtio-dev, Jiri Pirko, Jakub Kicinski,
Sridhar Samudrala, virtualization, Netdev, David Miller
On Mon, Apr 23, 2018 at 10:56 AM, Michael S. Tsirkin <mst@redhat.com> wrote:
> On Mon, Apr 23, 2018 at 10:44:40AM -0700, Stephen Hemminger wrote:
>> On Mon, 23 Apr 2018 20:24:56 +0300
>> "Michael S. Tsirkin" <mst@redhat.com> wrote:
>>
>> > On Mon, Apr 23, 2018 at 10:04:06AM -0700, Stephen Hemminger wrote:
>> > > > >
>> > > > >I will NAK patches to change to common code for netvsc especially the
>> > > > >three device model. MS worked hard with distro vendors to support transparent
>> > > > >mode, ans we really can't have a new model; or do backport.
>> > > > >
>> > > > >Plus, DPDK is now dependent on existing model.
>> > > >
>> > > > Sorry, but nobody here cares about dpdk or other similar oddities.
>> > >
>> > > The network device model is a userspace API, and DPDK is a userspace application.
>> >
>> > It is userspace but are you sure dpdk is actually poking at netdevs?
>> > AFAIK it's normally banging device registers directly.
>> >
>> > > You can't go breaking userspace even if you don't like the application.
>> >
>> > Could you please explain how is the proposed patchset breaking
>> > userspace? Ignoring DPDK for now, I don't think it changes the userspace
>> > API at all.
>> >
>>
>> The DPDK has a device driver vdev_netvsc which scans the Linux network devices
>> to look for Linux netvsc device and the paired VF device and setup the
>> DPDK environment. This setup creates a DPDK failsafe (bondingish) instance
>> and sets up TAP support over the Linux netvsc device as well as the Mellanox
>> VF device.
>>
>> So it depends on existing 2 device model. You can't go to a 3 device model
>> or start hiding devices from userspace.
>
> Okay so how does the existing patch break that? IIUC does not go to
> a 3 device model since netvsc calls failover_register directly.
>
>> Also, I am working on associating netvsc and VF device based on serial number
>> rather than MAC address. The serial number is how Windows works now, and it makes
>> sense for Linux and Windows to use the same mechanism if possible.
>
> Maybe we should support same for virtio ...
> Which serial do you mean? From vpd?
>
> I guess you will want to keep supporting MAC for old hypervisors?
>
> It all seems like a reasonable thing to support in the generic core.
That's the reason why I chose explicit identifier rather than rely on
MAC address to bind/pair a device. MAC address can change. Even if it
can't, malicious guest user can fake MAC address to skip binding.
-Siwei
>
> --
> MST
^ permalink raw reply [flat|nested] 114+ messages in thread
* [virtio-dev] Re: [PATCH v7 net-next 4/4] netvsc: refactor notifier/event handling code to use the failover framework
@ 2018-04-23 19:44 ` Siwei Liu
0 siblings, 0 replies; 114+ messages in thread
From: Siwei Liu @ 2018-04-23 19:44 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Stephen Hemminger, Jiri Pirko, Sridhar Samudrala, David Miller,
Netdev, virtualization, virtio-dev, Brandeburg, Jesse,
Alexander Duyck, Jakub Kicinski, Jason Wang
On Mon, Apr 23, 2018 at 10:56 AM, Michael S. Tsirkin <mst@redhat.com> wrote:
> On Mon, Apr 23, 2018 at 10:44:40AM -0700, Stephen Hemminger wrote:
>> On Mon, 23 Apr 2018 20:24:56 +0300
>> "Michael S. Tsirkin" <mst@redhat.com> wrote:
>>
>> > On Mon, Apr 23, 2018 at 10:04:06AM -0700, Stephen Hemminger wrote:
>> > > > >
>> > > > >I will NAK patches to change to common code for netvsc especially the
>> > > > >three device model. MS worked hard with distro vendors to support transparent
>> > > > >mode, ans we really can't have a new model; or do backport.
>> > > > >
>> > > > >Plus, DPDK is now dependent on existing model.
>> > > >
>> > > > Sorry, but nobody here cares about dpdk or other similar oddities.
>> > >
>> > > The network device model is a userspace API, and DPDK is a userspace application.
>> >
>> > It is userspace but are you sure dpdk is actually poking at netdevs?
>> > AFAIK it's normally banging device registers directly.
>> >
>> > > You can't go breaking userspace even if you don't like the application.
>> >
>> > Could you please explain how is the proposed patchset breaking
>> > userspace? Ignoring DPDK for now, I don't think it changes the userspace
>> > API at all.
>> >
>>
>> The DPDK has a device driver vdev_netvsc which scans the Linux network devices
>> to look for Linux netvsc device and the paired VF device and setup the
>> DPDK environment. This setup creates a DPDK failsafe (bondingish) instance
>> and sets up TAP support over the Linux netvsc device as well as the Mellanox
>> VF device.
>>
>> So it depends on existing 2 device model. You can't go to a 3 device model
>> or start hiding devices from userspace.
>
> Okay so how does the existing patch break that? IIUC does not go to
> a 3 device model since netvsc calls failover_register directly.
>
>> Also, I am working on associating netvsc and VF device based on serial number
>> rather than MAC address. The serial number is how Windows works now, and it makes
>> sense for Linux and Windows to use the same mechanism if possible.
>
> Maybe we should support same for virtio ...
> Which serial do you mean? From vpd?
>
> I guess you will want to keep supporting MAC for old hypervisors?
>
> It all seems like a reasonable thing to support in the generic core.
That's the reason why I chose explicit identifier rather than rely on
MAC address to bind/pair a device. MAC address can change. Even if it
can't, malicious guest user can fake MAC address to skip binding.
-Siwei
>
> --
> MST
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 net-next 4/4] netvsc: refactor notifier/event handling code to use the failover framework
2018-04-23 19:44 ` [virtio-dev] " Siwei Liu
@ 2018-04-23 20:06 ` Michael S. Tsirkin
-1 siblings, 0 replies; 114+ messages in thread
From: Michael S. Tsirkin @ 2018-04-23 20:06 UTC (permalink / raw)
To: Siwei Liu
Cc: Stephen Hemminger, Jiri Pirko, Sridhar Samudrala, David Miller,
Netdev, virtualization, virtio-dev, Brandeburg, Jesse,
Alexander Duyck, Jakub Kicinski, Jason Wang
On Mon, Apr 23, 2018 at 12:44:39PM -0700, Siwei Liu wrote:
> On Mon, Apr 23, 2018 at 10:56 AM, Michael S. Tsirkin <mst@redhat.com> wrote:
> > On Mon, Apr 23, 2018 at 10:44:40AM -0700, Stephen Hemminger wrote:
> >> On Mon, 23 Apr 2018 20:24:56 +0300
> >> "Michael S. Tsirkin" <mst@redhat.com> wrote:
> >>
> >> > On Mon, Apr 23, 2018 at 10:04:06AM -0700, Stephen Hemminger wrote:
> >> > > > >
> >> > > > >I will NAK patches to change to common code for netvsc especially the
> >> > > > >three device model. MS worked hard with distro vendors to support transparent
> >> > > > >mode, ans we really can't have a new model; or do backport.
> >> > > > >
> >> > > > >Plus, DPDK is now dependent on existing model.
> >> > > >
> >> > > > Sorry, but nobody here cares about dpdk or other similar oddities.
> >> > >
> >> > > The network device model is a userspace API, and DPDK is a userspace application.
> >> >
> >> > It is userspace but are you sure dpdk is actually poking at netdevs?
> >> > AFAIK it's normally banging device registers directly.
> >> >
> >> > > You can't go breaking userspace even if you don't like the application.
> >> >
> >> > Could you please explain how is the proposed patchset breaking
> >> > userspace? Ignoring DPDK for now, I don't think it changes the userspace
> >> > API at all.
> >> >
> >>
> >> The DPDK has a device driver vdev_netvsc which scans the Linux network devices
> >> to look for Linux netvsc device and the paired VF device and setup the
> >> DPDK environment. This setup creates a DPDK failsafe (bondingish) instance
> >> and sets up TAP support over the Linux netvsc device as well as the Mellanox
> >> VF device.
> >>
> >> So it depends on existing 2 device model. You can't go to a 3 device model
> >> or start hiding devices from userspace.
> >
> > Okay so how does the existing patch break that? IIUC does not go to
> > a 3 device model since netvsc calls failover_register directly.
> >
> >> Also, I am working on associating netvsc and VF device based on serial number
> >> rather than MAC address. The serial number is how Windows works now, and it makes
> >> sense for Linux and Windows to use the same mechanism if possible.
> >
> > Maybe we should support same for virtio ...
> > Which serial do you mean? From vpd?
> >
> > I guess you will want to keep supporting MAC for old hypervisors?
> >
> > It all seems like a reasonable thing to support in the generic core.
>
> That's the reason why I chose explicit identifier rather than rely on
> MAC address to bind/pair a device. MAC address can change. Even if it
> can't, malicious guest user can fake MAC address to skip binding.
>
> -Siwei
Address should be sampled at device creation to prevent this
kind of hack. Not that it buys the malicious user much:
if you can poke at MAC addresses you probably already can
break networking.
>
> >
> > --
> > MST
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 net-next 4/4] netvsc: refactor notifier/event handling code to use the failover framework
2018-04-23 19:44 ` [virtio-dev] " Siwei Liu
(?)
@ 2018-04-23 20:06 ` Michael S. Tsirkin
-1 siblings, 0 replies; 114+ messages in thread
From: Michael S. Tsirkin @ 2018-04-23 20:06 UTC (permalink / raw)
To: Siwei Liu
Cc: Alexander Duyck, virtio-dev, Jiri Pirko, Jakub Kicinski,
Sridhar Samudrala, virtualization, Netdev, David Miller
On Mon, Apr 23, 2018 at 12:44:39PM -0700, Siwei Liu wrote:
> On Mon, Apr 23, 2018 at 10:56 AM, Michael S. Tsirkin <mst@redhat.com> wrote:
> > On Mon, Apr 23, 2018 at 10:44:40AM -0700, Stephen Hemminger wrote:
> >> On Mon, 23 Apr 2018 20:24:56 +0300
> >> "Michael S. Tsirkin" <mst@redhat.com> wrote:
> >>
> >> > On Mon, Apr 23, 2018 at 10:04:06AM -0700, Stephen Hemminger wrote:
> >> > > > >
> >> > > > >I will NAK patches to change to common code for netvsc especially the
> >> > > > >three device model. MS worked hard with distro vendors to support transparent
> >> > > > >mode, ans we really can't have a new model; or do backport.
> >> > > > >
> >> > > > >Plus, DPDK is now dependent on existing model.
> >> > > >
> >> > > > Sorry, but nobody here cares about dpdk or other similar oddities.
> >> > >
> >> > > The network device model is a userspace API, and DPDK is a userspace application.
> >> >
> >> > It is userspace but are you sure dpdk is actually poking at netdevs?
> >> > AFAIK it's normally banging device registers directly.
> >> >
> >> > > You can't go breaking userspace even if you don't like the application.
> >> >
> >> > Could you please explain how is the proposed patchset breaking
> >> > userspace? Ignoring DPDK for now, I don't think it changes the userspace
> >> > API at all.
> >> >
> >>
> >> The DPDK has a device driver vdev_netvsc which scans the Linux network devices
> >> to look for Linux netvsc device and the paired VF device and setup the
> >> DPDK environment. This setup creates a DPDK failsafe (bondingish) instance
> >> and sets up TAP support over the Linux netvsc device as well as the Mellanox
> >> VF device.
> >>
> >> So it depends on existing 2 device model. You can't go to a 3 device model
> >> or start hiding devices from userspace.
> >
> > Okay so how does the existing patch break that? IIUC does not go to
> > a 3 device model since netvsc calls failover_register directly.
> >
> >> Also, I am working on associating netvsc and VF device based on serial number
> >> rather than MAC address. The serial number is how Windows works now, and it makes
> >> sense for Linux and Windows to use the same mechanism if possible.
> >
> > Maybe we should support same for virtio ...
> > Which serial do you mean? From vpd?
> >
> > I guess you will want to keep supporting MAC for old hypervisors?
> >
> > It all seems like a reasonable thing to support in the generic core.
>
> That's the reason why I chose explicit identifier rather than rely on
> MAC address to bind/pair a device. MAC address can change. Even if it
> can't, malicious guest user can fake MAC address to skip binding.
>
> -Siwei
Address should be sampled at device creation to prevent this
kind of hack. Not that it buys the malicious user much:
if you can poke at MAC addresses you probably already can
break networking.
>
> >
> > --
> > MST
^ permalink raw reply [flat|nested] 114+ messages in thread
* [virtio-dev] Re: [PATCH v7 net-next 4/4] netvsc: refactor notifier/event handling code to use the failover framework
@ 2018-04-23 20:06 ` Michael S. Tsirkin
0 siblings, 0 replies; 114+ messages in thread
From: Michael S. Tsirkin @ 2018-04-23 20:06 UTC (permalink / raw)
To: Siwei Liu
Cc: Stephen Hemminger, Jiri Pirko, Sridhar Samudrala, David Miller,
Netdev, virtualization, virtio-dev, Brandeburg, Jesse,
Alexander Duyck, Jakub Kicinski, Jason Wang
On Mon, Apr 23, 2018 at 12:44:39PM -0700, Siwei Liu wrote:
> On Mon, Apr 23, 2018 at 10:56 AM, Michael S. Tsirkin <mst@redhat.com> wrote:
> > On Mon, Apr 23, 2018 at 10:44:40AM -0700, Stephen Hemminger wrote:
> >> On Mon, 23 Apr 2018 20:24:56 +0300
> >> "Michael S. Tsirkin" <mst@redhat.com> wrote:
> >>
> >> > On Mon, Apr 23, 2018 at 10:04:06AM -0700, Stephen Hemminger wrote:
> >> > > > >
> >> > > > >I will NAK patches to change to common code for netvsc especially the
> >> > > > >three device model. MS worked hard with distro vendors to support transparent
> >> > > > >mode, ans we really can't have a new model; or do backport.
> >> > > > >
> >> > > > >Plus, DPDK is now dependent on existing model.
> >> > > >
> >> > > > Sorry, but nobody here cares about dpdk or other similar oddities.
> >> > >
> >> > > The network device model is a userspace API, and DPDK is a userspace application.
> >> >
> >> > It is userspace but are you sure dpdk is actually poking at netdevs?
> >> > AFAIK it's normally banging device registers directly.
> >> >
> >> > > You can't go breaking userspace even if you don't like the application.
> >> >
> >> > Could you please explain how is the proposed patchset breaking
> >> > userspace? Ignoring DPDK for now, I don't think it changes the userspace
> >> > API at all.
> >> >
> >>
> >> The DPDK has a device driver vdev_netvsc which scans the Linux network devices
> >> to look for Linux netvsc device and the paired VF device and setup the
> >> DPDK environment. This setup creates a DPDK failsafe (bondingish) instance
> >> and sets up TAP support over the Linux netvsc device as well as the Mellanox
> >> VF device.
> >>
> >> So it depends on existing 2 device model. You can't go to a 3 device model
> >> or start hiding devices from userspace.
> >
> > Okay so how does the existing patch break that? IIUC does not go to
> > a 3 device model since netvsc calls failover_register directly.
> >
> >> Also, I am working on associating netvsc and VF device based on serial number
> >> rather than MAC address. The serial number is how Windows works now, and it makes
> >> sense for Linux and Windows to use the same mechanism if possible.
> >
> > Maybe we should support same for virtio ...
> > Which serial do you mean? From vpd?
> >
> > I guess you will want to keep supporting MAC for old hypervisors?
> >
> > It all seems like a reasonable thing to support in the generic core.
>
> That's the reason why I chose explicit identifier rather than rely on
> MAC address to bind/pair a device. MAC address can change. Even if it
> can't, malicious guest user can fake MAC address to skip binding.
>
> -Siwei
Address should be sampled at device creation to prevent this
kind of hack. Not that it buys the malicious user much:
if you can poke at MAC addresses you probably already can
break networking.
>
> >
> > --
> > MST
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 net-next 4/4] netvsc: refactor notifier/event handling code to use the failover framework
2018-04-23 19:44 ` [virtio-dev] " Siwei Liu
` (3 preceding siblings ...)
(?)
@ 2018-04-24 1:25 ` Stephen Hemminger
2018-04-24 1:42 ` Michael S. Tsirkin
2018-04-24 1:42 ` [virtio-dev] " Michael S. Tsirkin
-1 siblings, 2 replies; 114+ messages in thread
From: Stephen Hemminger @ 2018-04-24 1:25 UTC (permalink / raw)
To: Siwei Liu
Cc: Michael S. Tsirkin, Jiri Pirko, Sridhar Samudrala, David Miller,
Netdev, virtualization, virtio-dev, Brandeburg, Jesse,
Alexander Duyck, Jakub Kicinski, Jason Wang
On Mon, 23 Apr 2018 12:44:39 -0700
Siwei Liu <loseweigh@gmail.com> wrote:
> On Mon, Apr 23, 2018 at 10:56 AM, Michael S. Tsirkin <mst@redhat.com> wrote:
> > On Mon, Apr 23, 2018 at 10:44:40AM -0700, Stephen Hemminger wrote:
> >> On Mon, 23 Apr 2018 20:24:56 +0300
> >> "Michael S. Tsirkin" <mst@redhat.com> wrote:
> >>
> >> > On Mon, Apr 23, 2018 at 10:04:06AM -0700, Stephen Hemminger wrote:
> >> > > > >
> >> > > > >I will NAK patches to change to common code for netvsc especially the
> >> > > > >three device model. MS worked hard with distro vendors to support transparent
> >> > > > >mode, ans we really can't have a new model; or do backport.
> >> > > > >
> >> > > > >Plus, DPDK is now dependent on existing model.
> >> > > >
> >> > > > Sorry, but nobody here cares about dpdk or other similar oddities.
> >> > >
> >> > > The network device model is a userspace API, and DPDK is a userspace application.
> >> >
> >> > It is userspace but are you sure dpdk is actually poking at netdevs?
> >> > AFAIK it's normally banging device registers directly.
> >> >
> >> > > You can't go breaking userspace even if you don't like the application.
> >> >
> >> > Could you please explain how is the proposed patchset breaking
> >> > userspace? Ignoring DPDK for now, I don't think it changes the userspace
> >> > API at all.
> >> >
> >>
> >> The DPDK has a device driver vdev_netvsc which scans the Linux network devices
> >> to look for Linux netvsc device and the paired VF device and setup the
> >> DPDK environment. This setup creates a DPDK failsafe (bondingish) instance
> >> and sets up TAP support over the Linux netvsc device as well as the Mellanox
> >> VF device.
> >>
> >> So it depends on existing 2 device model. You can't go to a 3 device model
> >> or start hiding devices from userspace.
> >
> > Okay so how does the existing patch break that? IIUC does not go to
> > a 3 device model since netvsc calls failover_register directly.
> >
> >> Also, I am working on associating netvsc and VF device based on serial number
> >> rather than MAC address. The serial number is how Windows works now, and it makes
> >> sense for Linux and Windows to use the same mechanism if possible.
> >
> > Maybe we should support same for virtio ...
> > Which serial do you mean? From vpd?
> >
> > I guess you will want to keep supporting MAC for old hypervisors?
The serial number has always been in the hypervisor since original support of SR-IOV
in WS2008. So no backward compatibility special cases would be needed.
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 net-next 4/4] netvsc: refactor notifier/event handling code to use the failover framework
2018-04-23 19:44 ` [virtio-dev] " Siwei Liu
` (2 preceding siblings ...)
(?)
@ 2018-04-24 1:25 ` Stephen Hemminger
-1 siblings, 0 replies; 114+ messages in thread
From: Stephen Hemminger @ 2018-04-24 1:25 UTC (permalink / raw)
To: Siwei Liu
Cc: Alexander Duyck, virtio-dev, Jiri Pirko, Michael S. Tsirkin,
Jakub Kicinski, Sridhar Samudrala, virtualization, Netdev,
David Miller
On Mon, 23 Apr 2018 12:44:39 -0700
Siwei Liu <loseweigh@gmail.com> wrote:
> On Mon, Apr 23, 2018 at 10:56 AM, Michael S. Tsirkin <mst@redhat.com> wrote:
> > On Mon, Apr 23, 2018 at 10:44:40AM -0700, Stephen Hemminger wrote:
> >> On Mon, 23 Apr 2018 20:24:56 +0300
> >> "Michael S. Tsirkin" <mst@redhat.com> wrote:
> >>
> >> > On Mon, Apr 23, 2018 at 10:04:06AM -0700, Stephen Hemminger wrote:
> >> > > > >
> >> > > > >I will NAK patches to change to common code for netvsc especially the
> >> > > > >three device model. MS worked hard with distro vendors to support transparent
> >> > > > >mode, ans we really can't have a new model; or do backport.
> >> > > > >
> >> > > > >Plus, DPDK is now dependent on existing model.
> >> > > >
> >> > > > Sorry, but nobody here cares about dpdk or other similar oddities.
> >> > >
> >> > > The network device model is a userspace API, and DPDK is a userspace application.
> >> >
> >> > It is userspace but are you sure dpdk is actually poking at netdevs?
> >> > AFAIK it's normally banging device registers directly.
> >> >
> >> > > You can't go breaking userspace even if you don't like the application.
> >> >
> >> > Could you please explain how is the proposed patchset breaking
> >> > userspace? Ignoring DPDK for now, I don't think it changes the userspace
> >> > API at all.
> >> >
> >>
> >> The DPDK has a device driver vdev_netvsc which scans the Linux network devices
> >> to look for Linux netvsc device and the paired VF device and setup the
> >> DPDK environment. This setup creates a DPDK failsafe (bondingish) instance
> >> and sets up TAP support over the Linux netvsc device as well as the Mellanox
> >> VF device.
> >>
> >> So it depends on existing 2 device model. You can't go to a 3 device model
> >> or start hiding devices from userspace.
> >
> > Okay so how does the existing patch break that? IIUC does not go to
> > a 3 device model since netvsc calls failover_register directly.
> >
> >> Also, I am working on associating netvsc and VF device based on serial number
> >> rather than MAC address. The serial number is how Windows works now, and it makes
> >> sense for Linux and Windows to use the same mechanism if possible.
> >
> > Maybe we should support same for virtio ...
> > Which serial do you mean? From vpd?
> >
> > I guess you will want to keep supporting MAC for old hypervisors?
The serial number has always been in the hypervisor since original support of SR-IOV
in WS2008. So no backward compatibility special cases would be needed.
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 net-next 4/4] netvsc: refactor notifier/event handling code to use the failover framework
2018-04-23 20:06 ` [virtio-dev] " Michael S. Tsirkin
(?)
(?)
@ 2018-04-24 1:28 ` Stephen Hemminger
-1 siblings, 0 replies; 114+ messages in thread
From: Stephen Hemminger @ 2018-04-24 1:28 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Siwei Liu, Jiri Pirko, Sridhar Samudrala, David Miller, Netdev,
virtualization, virtio-dev, Brandeburg, Jesse, Alexander Duyck,
Jakub Kicinski, Jason Wang
On Mon, 23 Apr 2018 23:06:55 +0300
"Michael S. Tsirkin" <mst@redhat.com> wrote:
> On Mon, Apr 23, 2018 at 12:44:39PM -0700, Siwei Liu wrote:
> > On Mon, Apr 23, 2018 at 10:56 AM, Michael S. Tsirkin <mst@redhat.com> wrote:
> > > On Mon, Apr 23, 2018 at 10:44:40AM -0700, Stephen Hemminger wrote:
> > >> On Mon, 23 Apr 2018 20:24:56 +0300
> > >> "Michael S. Tsirkin" <mst@redhat.com> wrote:
> > >>
> > >> > On Mon, Apr 23, 2018 at 10:04:06AM -0700, Stephen Hemminger wrote:
> > >> > > > >
> > >> > > > >I will NAK patches to change to common code for netvsc especially the
> > >> > > > >three device model. MS worked hard with distro vendors to support transparent
> > >> > > > >mode, ans we really can't have a new model; or do backport.
> > >> > > > >
> > >> > > > >Plus, DPDK is now dependent on existing model.
> > >> > > >
> > >> > > > Sorry, but nobody here cares about dpdk or other similar oddities.
> > >> > >
> > >> > > The network device model is a userspace API, and DPDK is a userspace application.
> > >> >
> > >> > It is userspace but are you sure dpdk is actually poking at netdevs?
> > >> > AFAIK it's normally banging device registers directly.
> > >> >
> > >> > > You can't go breaking userspace even if you don't like the application.
> > >> >
> > >> > Could you please explain how is the proposed patchset breaking
> > >> > userspace? Ignoring DPDK for now, I don't think it changes the userspace
> > >> > API at all.
> > >> >
> > >>
> > >> The DPDK has a device driver vdev_netvsc which scans the Linux network devices
> > >> to look for Linux netvsc device and the paired VF device and setup the
> > >> DPDK environment. This setup creates a DPDK failsafe (bondingish) instance
> > >> and sets up TAP support over the Linux netvsc device as well as the Mellanox
> > >> VF device.
> > >>
> > >> So it depends on existing 2 device model. You can't go to a 3 device model
> > >> or start hiding devices from userspace.
> > >
> > > Okay so how does the existing patch break that? IIUC does not go to
> > > a 3 device model since netvsc calls failover_register directly.
> > >
> > >> Also, I am working on associating netvsc and VF device based on serial number
> > >> rather than MAC address. The serial number is how Windows works now, and it makes
> > >> sense for Linux and Windows to use the same mechanism if possible.
> > >
> > > Maybe we should support same for virtio ...
> > > Which serial do you mean? From vpd?
> > >
> > > I guess you will want to keep supporting MAC for old hypervisors?
> > >
> > > It all seems like a reasonable thing to support in the generic core.
> >
> > That's the reason why I chose explicit identifier rather than rely on
> > MAC address to bind/pair a device. MAC address can change. Even if it
> > can't, malicious guest user can fake MAC address to skip binding.
> >
> > -Siwei
>
> Address should be sampled at device creation to prevent this
> kind of hack. Not that it buys the malicious user much:
> if you can poke at MAC addresses you probably already can
> break networking.
On Hyper-V guest can't really change MAC address if SR-IOV is enabled.
Also, Linux has permanent ether address in netdev which is what should
be used to avoid user messing with device.
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 net-next 4/4] netvsc: refactor notifier/event handling code to use the failover framework
2018-04-23 20:06 ` [virtio-dev] " Michael S. Tsirkin
(?)
@ 2018-04-24 1:28 ` Stephen Hemminger
-1 siblings, 0 replies; 114+ messages in thread
From: Stephen Hemminger @ 2018-04-24 1:28 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Alexander Duyck, virtio-dev, Jiri Pirko, Jakub Kicinski, Netdev,
virtualization, Siwei Liu, Sridhar Samudrala, David Miller
On Mon, 23 Apr 2018 23:06:55 +0300
"Michael S. Tsirkin" <mst@redhat.com> wrote:
> On Mon, Apr 23, 2018 at 12:44:39PM -0700, Siwei Liu wrote:
> > On Mon, Apr 23, 2018 at 10:56 AM, Michael S. Tsirkin <mst@redhat.com> wrote:
> > > On Mon, Apr 23, 2018 at 10:44:40AM -0700, Stephen Hemminger wrote:
> > >> On Mon, 23 Apr 2018 20:24:56 +0300
> > >> "Michael S. Tsirkin" <mst@redhat.com> wrote:
> > >>
> > >> > On Mon, Apr 23, 2018 at 10:04:06AM -0700, Stephen Hemminger wrote:
> > >> > > > >
> > >> > > > >I will NAK patches to change to common code for netvsc especially the
> > >> > > > >three device model. MS worked hard with distro vendors to support transparent
> > >> > > > >mode, ans we really can't have a new model; or do backport.
> > >> > > > >
> > >> > > > >Plus, DPDK is now dependent on existing model.
> > >> > > >
> > >> > > > Sorry, but nobody here cares about dpdk or other similar oddities.
> > >> > >
> > >> > > The network device model is a userspace API, and DPDK is a userspace application.
> > >> >
> > >> > It is userspace but are you sure dpdk is actually poking at netdevs?
> > >> > AFAIK it's normally banging device registers directly.
> > >> >
> > >> > > You can't go breaking userspace even if you don't like the application.
> > >> >
> > >> > Could you please explain how is the proposed patchset breaking
> > >> > userspace? Ignoring DPDK for now, I don't think it changes the userspace
> > >> > API at all.
> > >> >
> > >>
> > >> The DPDK has a device driver vdev_netvsc which scans the Linux network devices
> > >> to look for Linux netvsc device and the paired VF device and setup the
> > >> DPDK environment. This setup creates a DPDK failsafe (bondingish) instance
> > >> and sets up TAP support over the Linux netvsc device as well as the Mellanox
> > >> VF device.
> > >>
> > >> So it depends on existing 2 device model. You can't go to a 3 device model
> > >> or start hiding devices from userspace.
> > >
> > > Okay so how does the existing patch break that? IIUC does not go to
> > > a 3 device model since netvsc calls failover_register directly.
> > >
> > >> Also, I am working on associating netvsc and VF device based on serial number
> > >> rather than MAC address. The serial number is how Windows works now, and it makes
> > >> sense for Linux and Windows to use the same mechanism if possible.
> > >
> > > Maybe we should support same for virtio ...
> > > Which serial do you mean? From vpd?
> > >
> > > I guess you will want to keep supporting MAC for old hypervisors?
> > >
> > > It all seems like a reasonable thing to support in the generic core.
> >
> > That's the reason why I chose explicit identifier rather than rely on
> > MAC address to bind/pair a device. MAC address can change. Even if it
> > can't, malicious guest user can fake MAC address to skip binding.
> >
> > -Siwei
>
> Address should be sampled at device creation to prevent this
> kind of hack. Not that it buys the malicious user much:
> if you can poke at MAC addresses you probably already can
> break networking.
On Hyper-V guest can't really change MAC address if SR-IOV is enabled.
Also, Linux has permanent ether address in netdev which is what should
be used to avoid user messing with device.
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 net-next 4/4] netvsc: refactor notifier/event handling code to use the failover framework
2018-04-24 1:25 ` Stephen Hemminger
@ 2018-04-24 1:42 ` Michael S. Tsirkin
2018-04-24 1:42 ` [virtio-dev] " Michael S. Tsirkin
1 sibling, 0 replies; 114+ messages in thread
From: Michael S. Tsirkin @ 2018-04-24 1:42 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Siwei Liu, Jiri Pirko, Sridhar Samudrala, David Miller, Netdev,
virtualization, virtio-dev, Brandeburg, Jesse, Alexander Duyck,
Jakub Kicinski, Jason Wang
On Mon, Apr 23, 2018 at 06:25:03PM -0700, Stephen Hemminger wrote:
> On Mon, 23 Apr 2018 12:44:39 -0700
> Siwei Liu <loseweigh@gmail.com> wrote:
>
> > On Mon, Apr 23, 2018 at 10:56 AM, Michael S. Tsirkin <mst@redhat.com> wrote:
> > > On Mon, Apr 23, 2018 at 10:44:40AM -0700, Stephen Hemminger wrote:
> > >> On Mon, 23 Apr 2018 20:24:56 +0300
> > >> "Michael S. Tsirkin" <mst@redhat.com> wrote:
> > >>
> > >> > On Mon, Apr 23, 2018 at 10:04:06AM -0700, Stephen Hemminger wrote:
> > >> > > > >
> > >> > > > >I will NAK patches to change to common code for netvsc especially the
> > >> > > > >three device model. MS worked hard with distro vendors to support transparent
> > >> > > > >mode, ans we really can't have a new model; or do backport.
> > >> > > > >
> > >> > > > >Plus, DPDK is now dependent on existing model.
> > >> > > >
> > >> > > > Sorry, but nobody here cares about dpdk or other similar oddities.
> > >> > >
> > >> > > The network device model is a userspace API, and DPDK is a userspace application.
> > >> >
> > >> > It is userspace but are you sure dpdk is actually poking at netdevs?
> > >> > AFAIK it's normally banging device registers directly.
> > >> >
> > >> > > You can't go breaking userspace even if you don't like the application.
> > >> >
> > >> > Could you please explain how is the proposed patchset breaking
> > >> > userspace? Ignoring DPDK for now, I don't think it changes the userspace
> > >> > API at all.
> > >> >
> > >>
> > >> The DPDK has a device driver vdev_netvsc which scans the Linux network devices
> > >> to look for Linux netvsc device and the paired VF device and setup the
> > >> DPDK environment. This setup creates a DPDK failsafe (bondingish) instance
> > >> and sets up TAP support over the Linux netvsc device as well as the Mellanox
> > >> VF device.
> > >>
> > >> So it depends on existing 2 device model. You can't go to a 3 device model
> > >> or start hiding devices from userspace.
> > >
> > > Okay so how does the existing patch break that? IIUC does not go to
> > > a 3 device model since netvsc calls failover_register directly.
> > >
> > >> Also, I am working on associating netvsc and VF device based on serial number
> > >> rather than MAC address. The serial number is how Windows works now, and it makes
> > >> sense for Linux and Windows to use the same mechanism if possible.
> > >
> > > Maybe we should support same for virtio ...
> > > Which serial do you mean? From vpd?
> > >
> > > I guess you will want to keep supporting MAC for old hypervisors?
>
> The serial number has always been in the hypervisor since original support of SR-IOV
> in WS2008. So no backward compatibility special cases would be needed.
Is that a serial from real hardware or a hypervisor thing?
--
MST
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 net-next 4/4] netvsc: refactor notifier/event handling code to use the failover framework
2018-04-24 1:25 ` Stephen Hemminger
@ 2018-04-24 1:42 ` Michael S. Tsirkin
2018-04-24 1:42 ` [virtio-dev] " Michael S. Tsirkin
1 sibling, 0 replies; 114+ messages in thread
From: Michael S. Tsirkin @ 2018-04-24 1:42 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Alexander Duyck, virtio-dev, Jiri Pirko, Jakub Kicinski, Netdev,
virtualization, Siwei Liu, Sridhar Samudrala, David Miller
On Mon, Apr 23, 2018 at 06:25:03PM -0700, Stephen Hemminger wrote:
> On Mon, 23 Apr 2018 12:44:39 -0700
> Siwei Liu <loseweigh@gmail.com> wrote:
>
> > On Mon, Apr 23, 2018 at 10:56 AM, Michael S. Tsirkin <mst@redhat.com> wrote:
> > > On Mon, Apr 23, 2018 at 10:44:40AM -0700, Stephen Hemminger wrote:
> > >> On Mon, 23 Apr 2018 20:24:56 +0300
> > >> "Michael S. Tsirkin" <mst@redhat.com> wrote:
> > >>
> > >> > On Mon, Apr 23, 2018 at 10:04:06AM -0700, Stephen Hemminger wrote:
> > >> > > > >
> > >> > > > >I will NAK patches to change to common code for netvsc especially the
> > >> > > > >three device model. MS worked hard with distro vendors to support transparent
> > >> > > > >mode, ans we really can't have a new model; or do backport.
> > >> > > > >
> > >> > > > >Plus, DPDK is now dependent on existing model.
> > >> > > >
> > >> > > > Sorry, but nobody here cares about dpdk or other similar oddities.
> > >> > >
> > >> > > The network device model is a userspace API, and DPDK is a userspace application.
> > >> >
> > >> > It is userspace but are you sure dpdk is actually poking at netdevs?
> > >> > AFAIK it's normally banging device registers directly.
> > >> >
> > >> > > You can't go breaking userspace even if you don't like the application.
> > >> >
> > >> > Could you please explain how is the proposed patchset breaking
> > >> > userspace? Ignoring DPDK for now, I don't think it changes the userspace
> > >> > API at all.
> > >> >
> > >>
> > >> The DPDK has a device driver vdev_netvsc which scans the Linux network devices
> > >> to look for Linux netvsc device and the paired VF device and setup the
> > >> DPDK environment. This setup creates a DPDK failsafe (bondingish) instance
> > >> and sets up TAP support over the Linux netvsc device as well as the Mellanox
> > >> VF device.
> > >>
> > >> So it depends on existing 2 device model. You can't go to a 3 device model
> > >> or start hiding devices from userspace.
> > >
> > > Okay so how does the existing patch break that? IIUC does not go to
> > > a 3 device model since netvsc calls failover_register directly.
> > >
> > >> Also, I am working on associating netvsc and VF device based on serial number
> > >> rather than MAC address. The serial number is how Windows works now, and it makes
> > >> sense for Linux and Windows to use the same mechanism if possible.
> > >
> > > Maybe we should support same for virtio ...
> > > Which serial do you mean? From vpd?
> > >
> > > I guess you will want to keep supporting MAC for old hypervisors?
>
> The serial number has always been in the hypervisor since original support of SR-IOV
> in WS2008. So no backward compatibility special cases would be needed.
Is that a serial from real hardware or a hypervisor thing?
--
MST
^ permalink raw reply [flat|nested] 114+ messages in thread
* [virtio-dev] Re: [PATCH v7 net-next 4/4] netvsc: refactor notifier/event handling code to use the failover framework
@ 2018-04-24 1:42 ` Michael S. Tsirkin
0 siblings, 0 replies; 114+ messages in thread
From: Michael S. Tsirkin @ 2018-04-24 1:42 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Siwei Liu, Jiri Pirko, Sridhar Samudrala, David Miller, Netdev,
virtualization, virtio-dev, Brandeburg, Jesse, Alexander Duyck,
Jakub Kicinski, Jason Wang
On Mon, Apr 23, 2018 at 06:25:03PM -0700, Stephen Hemminger wrote:
> On Mon, 23 Apr 2018 12:44:39 -0700
> Siwei Liu <loseweigh@gmail.com> wrote:
>
> > On Mon, Apr 23, 2018 at 10:56 AM, Michael S. Tsirkin <mst@redhat.com> wrote:
> > > On Mon, Apr 23, 2018 at 10:44:40AM -0700, Stephen Hemminger wrote:
> > >> On Mon, 23 Apr 2018 20:24:56 +0300
> > >> "Michael S. Tsirkin" <mst@redhat.com> wrote:
> > >>
> > >> > On Mon, Apr 23, 2018 at 10:04:06AM -0700, Stephen Hemminger wrote:
> > >> > > > >
> > >> > > > >I will NAK patches to change to common code for netvsc especially the
> > >> > > > >three device model. MS worked hard with distro vendors to support transparent
> > >> > > > >mode, ans we really can't have a new model; or do backport.
> > >> > > > >
> > >> > > > >Plus, DPDK is now dependent on existing model.
> > >> > > >
> > >> > > > Sorry, but nobody here cares about dpdk or other similar oddities.
> > >> > >
> > >> > > The network device model is a userspace API, and DPDK is a userspace application.
> > >> >
> > >> > It is userspace but are you sure dpdk is actually poking at netdevs?
> > >> > AFAIK it's normally banging device registers directly.
> > >> >
> > >> > > You can't go breaking userspace even if you don't like the application.
> > >> >
> > >> > Could you please explain how is the proposed patchset breaking
> > >> > userspace? Ignoring DPDK for now, I don't think it changes the userspace
> > >> > API at all.
> > >> >
> > >>
> > >> The DPDK has a device driver vdev_netvsc which scans the Linux network devices
> > >> to look for Linux netvsc device and the paired VF device and setup the
> > >> DPDK environment. This setup creates a DPDK failsafe (bondingish) instance
> > >> and sets up TAP support over the Linux netvsc device as well as the Mellanox
> > >> VF device.
> > >>
> > >> So it depends on existing 2 device model. You can't go to a 3 device model
> > >> or start hiding devices from userspace.
> > >
> > > Okay so how does the existing patch break that? IIUC does not go to
> > > a 3 device model since netvsc calls failover_register directly.
> > >
> > >> Also, I am working on associating netvsc and VF device based on serial number
> > >> rather than MAC address. The serial number is how Windows works now, and it makes
> > >> sense for Linux and Windows to use the same mechanism if possible.
> > >
> > > Maybe we should support same for virtio ...
> > > Which serial do you mean? From vpd?
> > >
> > > I guess you will want to keep supporting MAC for old hypervisors?
>
> The serial number has always been in the hypervisor since original support of SR-IOV
> in WS2008. So no backward compatibility special cases would be needed.
Is that a serial from real hardware or a hypervisor thing?
--
MST
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 net-next 4/4] netvsc: refactor notifier/event handling code to use the failover framework
2018-04-24 1:42 ` [virtio-dev] " Michael S. Tsirkin
(?)
(?)
@ 2018-04-24 5:07 ` Stephen Hemminger
-1 siblings, 0 replies; 114+ messages in thread
From: Stephen Hemminger @ 2018-04-24 5:07 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Siwei Liu, Jiri Pirko, Sridhar Samudrala, David Miller, Netdev,
virtualization, virtio-dev, Brandeburg, Jesse, Alexander Duyck,
Jakub Kicinski, Jason Wang
On Tue, 24 Apr 2018 04:42:22 +0300
"Michael S. Tsirkin" <mst@redhat.com> wrote:
> On Mon, Apr 23, 2018 at 06:25:03PM -0700, Stephen Hemminger wrote:
> > On Mon, 23 Apr 2018 12:44:39 -0700
> > Siwei Liu <loseweigh@gmail.com> wrote:
> >
> > > On Mon, Apr 23, 2018 at 10:56 AM, Michael S. Tsirkin <mst@redhat.com> wrote:
> > > > On Mon, Apr 23, 2018 at 10:44:40AM -0700, Stephen Hemminger wrote:
> > > >> On Mon, 23 Apr 2018 20:24:56 +0300
> > > >> "Michael S. Tsirkin" <mst@redhat.com> wrote:
> > > >>
> > > >> > On Mon, Apr 23, 2018 at 10:04:06AM -0700, Stephen Hemminger wrote:
> > > >> > > > >
> > > >> > > > >I will NAK patches to change to common code for netvsc especially the
> > > >> > > > >three device model. MS worked hard with distro vendors to support transparent
> > > >> > > > >mode, ans we really can't have a new model; or do backport.
> > > >> > > > >
> > > >> > > > >Plus, DPDK is now dependent on existing model.
> > > >> > > >
> > > >> > > > Sorry, but nobody here cares about dpdk or other similar oddities.
> > > >> > >
> > > >> > > The network device model is a userspace API, and DPDK is a userspace application.
> > > >> >
> > > >> > It is userspace but are you sure dpdk is actually poking at netdevs?
> > > >> > AFAIK it's normally banging device registers directly.
> > > >> >
> > > >> > > You can't go breaking userspace even if you don't like the application.
> > > >> >
> > > >> > Could you please explain how is the proposed patchset breaking
> > > >> > userspace? Ignoring DPDK for now, I don't think it changes the userspace
> > > >> > API at all.
> > > >> >
> > > >>
> > > >> The DPDK has a device driver vdev_netvsc which scans the Linux network devices
> > > >> to look for Linux netvsc device and the paired VF device and setup the
> > > >> DPDK environment. This setup creates a DPDK failsafe (bondingish) instance
> > > >> and sets up TAP support over the Linux netvsc device as well as the Mellanox
> > > >> VF device.
> > > >>
> > > >> So it depends on existing 2 device model. You can't go to a 3 device model
> > > >> or start hiding devices from userspace.
> > > >
> > > > Okay so how does the existing patch break that? IIUC does not go to
> > > > a 3 device model since netvsc calls failover_register directly.
> > > >
> > > >> Also, I am working on associating netvsc and VF device based on serial number
> > > >> rather than MAC address. The serial number is how Windows works now, and it makes
> > > >> sense for Linux and Windows to use the same mechanism if possible.
> > > >
> > > > Maybe we should support same for virtio ...
> > > > Which serial do you mean? From vpd?
> > > >
> > > > I guess you will want to keep supporting MAC for old hypervisors?
> >
> > The serial number has always been in the hypervisor since original support of SR-IOV
> > in WS2008. So no backward compatibility special cases would be needed.
>
> Is that a serial from real hardware or a hypervisor thing?
>
>
It is a hypervisor thing in the PCI hyperv code and the hyperv Netvsc interface.
It might also be in the PCI spec, but the value in Hyper-V is being generated by the host.
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 net-next 4/4] netvsc: refactor notifier/event handling code to use the failover framework
2018-04-24 1:42 ` [virtio-dev] " Michael S. Tsirkin
(?)
@ 2018-04-24 5:07 ` Stephen Hemminger
-1 siblings, 0 replies; 114+ messages in thread
From: Stephen Hemminger @ 2018-04-24 5:07 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Alexander Duyck, virtio-dev, Jiri Pirko, Jakub Kicinski, Netdev,
virtualization, Siwei Liu, Sridhar Samudrala, David Miller
On Tue, 24 Apr 2018 04:42:22 +0300
"Michael S. Tsirkin" <mst@redhat.com> wrote:
> On Mon, Apr 23, 2018 at 06:25:03PM -0700, Stephen Hemminger wrote:
> > On Mon, 23 Apr 2018 12:44:39 -0700
> > Siwei Liu <loseweigh@gmail.com> wrote:
> >
> > > On Mon, Apr 23, 2018 at 10:56 AM, Michael S. Tsirkin <mst@redhat.com> wrote:
> > > > On Mon, Apr 23, 2018 at 10:44:40AM -0700, Stephen Hemminger wrote:
> > > >> On Mon, 23 Apr 2018 20:24:56 +0300
> > > >> "Michael S. Tsirkin" <mst@redhat.com> wrote:
> > > >>
> > > >> > On Mon, Apr 23, 2018 at 10:04:06AM -0700, Stephen Hemminger wrote:
> > > >> > > > >
> > > >> > > > >I will NAK patches to change to common code for netvsc especially the
> > > >> > > > >three device model. MS worked hard with distro vendors to support transparent
> > > >> > > > >mode, ans we really can't have a new model; or do backport.
> > > >> > > > >
> > > >> > > > >Plus, DPDK is now dependent on existing model.
> > > >> > > >
> > > >> > > > Sorry, but nobody here cares about dpdk or other similar oddities.
> > > >> > >
> > > >> > > The network device model is a userspace API, and DPDK is a userspace application.
> > > >> >
> > > >> > It is userspace but are you sure dpdk is actually poking at netdevs?
> > > >> > AFAIK it's normally banging device registers directly.
> > > >> >
> > > >> > > You can't go breaking userspace even if you don't like the application.
> > > >> >
> > > >> > Could you please explain how is the proposed patchset breaking
> > > >> > userspace? Ignoring DPDK for now, I don't think it changes the userspace
> > > >> > API at all.
> > > >> >
> > > >>
> > > >> The DPDK has a device driver vdev_netvsc which scans the Linux network devices
> > > >> to look for Linux netvsc device and the paired VF device and setup the
> > > >> DPDK environment. This setup creates a DPDK failsafe (bondingish) instance
> > > >> and sets up TAP support over the Linux netvsc device as well as the Mellanox
> > > >> VF device.
> > > >>
> > > >> So it depends on existing 2 device model. You can't go to a 3 device model
> > > >> or start hiding devices from userspace.
> > > >
> > > > Okay so how does the existing patch break that? IIUC does not go to
> > > > a 3 device model since netvsc calls failover_register directly.
> > > >
> > > >> Also, I am working on associating netvsc and VF device based on serial number
> > > >> rather than MAC address. The serial number is how Windows works now, and it makes
> > > >> sense for Linux and Windows to use the same mechanism if possible.
> > > >
> > > > Maybe we should support same for virtio ...
> > > > Which serial do you mean? From vpd?
> > > >
> > > > I guess you will want to keep supporting MAC for old hypervisors?
> >
> > The serial number has always been in the hypervisor since original support of SR-IOV
> > in WS2008. So no backward compatibility special cases would be needed.
>
> Is that a serial from real hardware or a hypervisor thing?
>
>
It is a hypervisor thing in the PCI hyperv code and the hyperv Netvsc interface.
It might also be in the PCI spec, but the value in Hyper-V is being generated by the host.
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 net-next 4/4] netvsc: refactor notifier/event handling code to use the failover framework
2018-04-23 20:06 ` [virtio-dev] " Michael S. Tsirkin
@ 2018-04-25 21:38 ` Siwei Liu
-1 siblings, 0 replies; 114+ messages in thread
From: Siwei Liu @ 2018-04-25 21:38 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Alexander Duyck, virtio-dev, Jiri Pirko, Jakub Kicinski,
Sridhar Samudrala, virtualization, Netdev, David Miller
On Mon, Apr 23, 2018 at 1:06 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
> On Mon, Apr 23, 2018 at 12:44:39PM -0700, Siwei Liu wrote:
>> On Mon, Apr 23, 2018 at 10:56 AM, Michael S. Tsirkin <mst@redhat.com> wrote:
>> > On Mon, Apr 23, 2018 at 10:44:40AM -0700, Stephen Hemminger wrote:
>> >> On Mon, 23 Apr 2018 20:24:56 +0300
>> >> "Michael S. Tsirkin" <mst@redhat.com> wrote:
>> >>
>> >> > On Mon, Apr 23, 2018 at 10:04:06AM -0700, Stephen Hemminger wrote:
>> >> > > > >
>> >> > > > >I will NAK patches to change to common code for netvsc especially the
>> >> > > > >three device model. MS worked hard with distro vendors to support transparent
>> >> > > > >mode, ans we really can't have a new model; or do backport.
>> >> > > > >
>> >> > > > >Plus, DPDK is now dependent on existing model.
>> >> > > >
>> >> > > > Sorry, but nobody here cares about dpdk or other similar oddities.
>> >> > >
>> >> > > The network device model is a userspace API, and DPDK is a userspace application.
>> >> >
>> >> > It is userspace but are you sure dpdk is actually poking at netdevs?
>> >> > AFAIK it's normally banging device registers directly.
>> >> >
>> >> > > You can't go breaking userspace even if you don't like the application.
>> >> >
>> >> > Could you please explain how is the proposed patchset breaking
>> >> > userspace? Ignoring DPDK for now, I don't think it changes the userspace
>> >> > API at all.
>> >> >
>> >>
>> >> The DPDK has a device driver vdev_netvsc which scans the Linux network devices
>> >> to look for Linux netvsc device and the paired VF device and setup the
>> >> DPDK environment. This setup creates a DPDK failsafe (bondingish) instance
>> >> and sets up TAP support over the Linux netvsc device as well as the Mellanox
>> >> VF device.
>> >>
>> >> So it depends on existing 2 device model. You can't go to a 3 device model
>> >> or start hiding devices from userspace.
>> >
>> > Okay so how does the existing patch break that? IIUC does not go to
>> > a 3 device model since netvsc calls failover_register directly.
>> >
>> >> Also, I am working on associating netvsc and VF device based on serial number
>> >> rather than MAC address. The serial number is how Windows works now, and it makes
>> >> sense for Linux and Windows to use the same mechanism if possible.
>> >
>> > Maybe we should support same for virtio ...
>> > Which serial do you mean? From vpd?
>> >
>> > I guess you will want to keep supporting MAC for old hypervisors?
>> >
>> > It all seems like a reasonable thing to support in the generic core.
>>
>> That's the reason why I chose explicit identifier rather than rely on
>> MAC address to bind/pair a device. MAC address can change. Even if it
>> can't, malicious guest user can fake MAC address to skip binding.
>>
>> -Siwei
>
> Address should be sampled at device creation to prevent this
> kind of hack. Not that it buys the malicious user much:
> if you can poke at MAC addresses you probably already can
> break networking.
I don't understand why poking at MAC address may potentially break
networking. Unlike VF, passthrough PCI endpoint device has its freedom
to change the MAC address. Even on a VF setup it's not neccessarily
always safe to assume the VF's MAC address cannot or shouldn't be
changed. That depends on the specific need whether the host admin
wants to restrict guest from changing the MAC address, although in
most cases it's true.
I understand we can use the perm_addr to distinguish. But as said,
this will pose limitation of flexible configuration where one can
assign VFs with identical MAC address at all while each VF belongs to
different PF and/or different subnet for e.g. load balancing. And
furthermore, the QEMU device model never uses MAC address to be
interpreted as an identifier, which requires to be unique per VM
instance. Why we're introducing this inconsistency?
-Siwei
>
>
>
>
>>
>> >
>> > --
>> > MST
^ permalink raw reply [flat|nested] 114+ messages in thread
* [virtio-dev] Re: [PATCH v7 net-next 4/4] netvsc: refactor notifier/event handling code to use the failover framework
@ 2018-04-25 21:38 ` Siwei Liu
0 siblings, 0 replies; 114+ messages in thread
From: Siwei Liu @ 2018-04-25 21:38 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Stephen Hemminger, Jiri Pirko, Sridhar Samudrala, David Miller,
Netdev, virtualization, virtio-dev, Brandeburg, Jesse,
Alexander Duyck, Jakub Kicinski, Jason Wang
On Mon, Apr 23, 2018 at 1:06 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
> On Mon, Apr 23, 2018 at 12:44:39PM -0700, Siwei Liu wrote:
>> On Mon, Apr 23, 2018 at 10:56 AM, Michael S. Tsirkin <mst@redhat.com> wrote:
>> > On Mon, Apr 23, 2018 at 10:44:40AM -0700, Stephen Hemminger wrote:
>> >> On Mon, 23 Apr 2018 20:24:56 +0300
>> >> "Michael S. Tsirkin" <mst@redhat.com> wrote:
>> >>
>> >> > On Mon, Apr 23, 2018 at 10:04:06AM -0700, Stephen Hemminger wrote:
>> >> > > > >
>> >> > > > >I will NAK patches to change to common code for netvsc especially the
>> >> > > > >three device model. MS worked hard with distro vendors to support transparent
>> >> > > > >mode, ans we really can't have a new model; or do backport.
>> >> > > > >
>> >> > > > >Plus, DPDK is now dependent on existing model.
>> >> > > >
>> >> > > > Sorry, but nobody here cares about dpdk or other similar oddities.
>> >> > >
>> >> > > The network device model is a userspace API, and DPDK is a userspace application.
>> >> >
>> >> > It is userspace but are you sure dpdk is actually poking at netdevs?
>> >> > AFAIK it's normally banging device registers directly.
>> >> >
>> >> > > You can't go breaking userspace even if you don't like the application.
>> >> >
>> >> > Could you please explain how is the proposed patchset breaking
>> >> > userspace? Ignoring DPDK for now, I don't think it changes the userspace
>> >> > API at all.
>> >> >
>> >>
>> >> The DPDK has a device driver vdev_netvsc which scans the Linux network devices
>> >> to look for Linux netvsc device and the paired VF device and setup the
>> >> DPDK environment. This setup creates a DPDK failsafe (bondingish) instance
>> >> and sets up TAP support over the Linux netvsc device as well as the Mellanox
>> >> VF device.
>> >>
>> >> So it depends on existing 2 device model. You can't go to a 3 device model
>> >> or start hiding devices from userspace.
>> >
>> > Okay so how does the existing patch break that? IIUC does not go to
>> > a 3 device model since netvsc calls failover_register directly.
>> >
>> >> Also, I am working on associating netvsc and VF device based on serial number
>> >> rather than MAC address. The serial number is how Windows works now, and it makes
>> >> sense for Linux and Windows to use the same mechanism if possible.
>> >
>> > Maybe we should support same for virtio ...
>> > Which serial do you mean? From vpd?
>> >
>> > I guess you will want to keep supporting MAC for old hypervisors?
>> >
>> > It all seems like a reasonable thing to support in the generic core.
>>
>> That's the reason why I chose explicit identifier rather than rely on
>> MAC address to bind/pair a device. MAC address can change. Even if it
>> can't, malicious guest user can fake MAC address to skip binding.
>>
>> -Siwei
>
> Address should be sampled at device creation to prevent this
> kind of hack. Not that it buys the malicious user much:
> if you can poke at MAC addresses you probably already can
> break networking.
I don't understand why poking at MAC address may potentially break
networking. Unlike VF, passthrough PCI endpoint device has its freedom
to change the MAC address. Even on a VF setup it's not neccessarily
always safe to assume the VF's MAC address cannot or shouldn't be
changed. That depends on the specific need whether the host admin
wants to restrict guest from changing the MAC address, although in
most cases it's true.
I understand we can use the perm_addr to distinguish. But as said,
this will pose limitation of flexible configuration where one can
assign VFs with identical MAC address at all while each VF belongs to
different PF and/or different subnet for e.g. load balancing. And
furthermore, the QEMU device model never uses MAC address to be
interpreted as an identifier, which requires to be unique per VM
instance. Why we're introducing this inconsistency?
-Siwei
>
>
>
>
>>
>> >
>> > --
>> > MST
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 net-next 4/4] netvsc: refactor notifier/event handling code to use the failover framework
2018-04-25 21:38 ` [virtio-dev] " Siwei Liu
@ 2018-04-25 22:22 ` Michael S. Tsirkin
-1 siblings, 0 replies; 114+ messages in thread
From: Michael S. Tsirkin @ 2018-04-25 22:22 UTC (permalink / raw)
To: Siwei Liu
Cc: Stephen Hemminger, Jiri Pirko, Sridhar Samudrala, David Miller,
Netdev, virtualization, virtio-dev, Brandeburg, Jesse,
Alexander Duyck, Jakub Kicinski, Jason Wang
On Wed, Apr 25, 2018 at 02:38:57PM -0700, Siwei Liu wrote:
> On Mon, Apr 23, 2018 at 1:06 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
> > On Mon, Apr 23, 2018 at 12:44:39PM -0700, Siwei Liu wrote:
> >> On Mon, Apr 23, 2018 at 10:56 AM, Michael S. Tsirkin <mst@redhat.com> wrote:
> >> > On Mon, Apr 23, 2018 at 10:44:40AM -0700, Stephen Hemminger wrote:
> >> >> On Mon, 23 Apr 2018 20:24:56 +0300
> >> >> "Michael S. Tsirkin" <mst@redhat.com> wrote:
> >> >>
> >> >> > On Mon, Apr 23, 2018 at 10:04:06AM -0700, Stephen Hemminger wrote:
> >> >> > > > >
> >> >> > > > >I will NAK patches to change to common code for netvsc especially the
> >> >> > > > >three device model. MS worked hard with distro vendors to support transparent
> >> >> > > > >mode, ans we really can't have a new model; or do backport.
> >> >> > > > >
> >> >> > > > >Plus, DPDK is now dependent on existing model.
> >> >> > > >
> >> >> > > > Sorry, but nobody here cares about dpdk or other similar oddities.
> >> >> > >
> >> >> > > The network device model is a userspace API, and DPDK is a userspace application.
> >> >> >
> >> >> > It is userspace but are you sure dpdk is actually poking at netdevs?
> >> >> > AFAIK it's normally banging device registers directly.
> >> >> >
> >> >> > > You can't go breaking userspace even if you don't like the application.
> >> >> >
> >> >> > Could you please explain how is the proposed patchset breaking
> >> >> > userspace? Ignoring DPDK for now, I don't think it changes the userspace
> >> >> > API at all.
> >> >> >
> >> >>
> >> >> The DPDK has a device driver vdev_netvsc which scans the Linux network devices
> >> >> to look for Linux netvsc device and the paired VF device and setup the
> >> >> DPDK environment. This setup creates a DPDK failsafe (bondingish) instance
> >> >> and sets up TAP support over the Linux netvsc device as well as the Mellanox
> >> >> VF device.
> >> >>
> >> >> So it depends on existing 2 device model. You can't go to a 3 device model
> >> >> or start hiding devices from userspace.
> >> >
> >> > Okay so how does the existing patch break that? IIUC does not go to
> >> > a 3 device model since netvsc calls failover_register directly.
> >> >
> >> >> Also, I am working on associating netvsc and VF device based on serial number
> >> >> rather than MAC address. The serial number is how Windows works now, and it makes
> >> >> sense for Linux and Windows to use the same mechanism if possible.
> >> >
> >> > Maybe we should support same for virtio ...
> >> > Which serial do you mean? From vpd?
> >> >
> >> > I guess you will want to keep supporting MAC for old hypervisors?
> >> >
> >> > It all seems like a reasonable thing to support in the generic core.
> >>
> >> That's the reason why I chose explicit identifier rather than rely on
> >> MAC address to bind/pair a device. MAC address can change. Even if it
> >> can't, malicious guest user can fake MAC address to skip binding.
> >>
> >> -Siwei
> >
> > Address should be sampled at device creation to prevent this
> > kind of hack. Not that it buys the malicious user much:
> > if you can poke at MAC addresses you probably already can
> > break networking.
>
> I don't understand why poking at MAC address may potentially break
> networking.
Set a MAC address to match another device on the same LAN,
packets will stop reaching that MAC.
> Unlike VF, passthrough PCI endpoint device has its freedom
> to change the MAC address. Even on a VF setup it's not neccessarily
> always safe to assume the VF's MAC address cannot or shouldn't be
> changed. That depends on the specific need whether the host admin
> wants to restrict guest from changing the MAC address, although in
> most cases it's true.
>
> I understand we can use the perm_addr to distinguish. But as said,
> this will pose limitation of flexible configuration where one can
> assign VFs with identical MAC address at all while each VF belongs to
> different PF and/or different subnet for e.g. load balancing.
> And
> furthermore, the QEMU device model never uses MAC address to be
> interpreted as an identifier, which requires to be unique per VM
> instance. Why we're introducing this inconsistency?
>
> -Siwei
Because it addresses most of the issues and is simple. That's already
much better than what we have now which is nothing unless guest
configures things manually.
I think ideally the infrastructure should suppport flexible matching of
NICs - netvsc is already reported to be moving to some kind of serial
address.
> >
> >
> >
> >
> >>
> >> >
> >> > --
> >> > MST
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 net-next 4/4] netvsc: refactor notifier/event handling code to use the failover framework
2018-04-25 21:38 ` [virtio-dev] " Siwei Liu
(?)
@ 2018-04-25 22:22 ` Michael S. Tsirkin
-1 siblings, 0 replies; 114+ messages in thread
From: Michael S. Tsirkin @ 2018-04-25 22:22 UTC (permalink / raw)
To: Siwei Liu
Cc: Alexander Duyck, virtio-dev, Jiri Pirko, Jakub Kicinski,
Sridhar Samudrala, virtualization, Netdev, David Miller
On Wed, Apr 25, 2018 at 02:38:57PM -0700, Siwei Liu wrote:
> On Mon, Apr 23, 2018 at 1:06 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
> > On Mon, Apr 23, 2018 at 12:44:39PM -0700, Siwei Liu wrote:
> >> On Mon, Apr 23, 2018 at 10:56 AM, Michael S. Tsirkin <mst@redhat.com> wrote:
> >> > On Mon, Apr 23, 2018 at 10:44:40AM -0700, Stephen Hemminger wrote:
> >> >> On Mon, 23 Apr 2018 20:24:56 +0300
> >> >> "Michael S. Tsirkin" <mst@redhat.com> wrote:
> >> >>
> >> >> > On Mon, Apr 23, 2018 at 10:04:06AM -0700, Stephen Hemminger wrote:
> >> >> > > > >
> >> >> > > > >I will NAK patches to change to common code for netvsc especially the
> >> >> > > > >three device model. MS worked hard with distro vendors to support transparent
> >> >> > > > >mode, ans we really can't have a new model; or do backport.
> >> >> > > > >
> >> >> > > > >Plus, DPDK is now dependent on existing model.
> >> >> > > >
> >> >> > > > Sorry, but nobody here cares about dpdk or other similar oddities.
> >> >> > >
> >> >> > > The network device model is a userspace API, and DPDK is a userspace application.
> >> >> >
> >> >> > It is userspace but are you sure dpdk is actually poking at netdevs?
> >> >> > AFAIK it's normally banging device registers directly.
> >> >> >
> >> >> > > You can't go breaking userspace even if you don't like the application.
> >> >> >
> >> >> > Could you please explain how is the proposed patchset breaking
> >> >> > userspace? Ignoring DPDK for now, I don't think it changes the userspace
> >> >> > API at all.
> >> >> >
> >> >>
> >> >> The DPDK has a device driver vdev_netvsc which scans the Linux network devices
> >> >> to look for Linux netvsc device and the paired VF device and setup the
> >> >> DPDK environment. This setup creates a DPDK failsafe (bondingish) instance
> >> >> and sets up TAP support over the Linux netvsc device as well as the Mellanox
> >> >> VF device.
> >> >>
> >> >> So it depends on existing 2 device model. You can't go to a 3 device model
> >> >> or start hiding devices from userspace.
> >> >
> >> > Okay so how does the existing patch break that? IIUC does not go to
> >> > a 3 device model since netvsc calls failover_register directly.
> >> >
> >> >> Also, I am working on associating netvsc and VF device based on serial number
> >> >> rather than MAC address. The serial number is how Windows works now, and it makes
> >> >> sense for Linux and Windows to use the same mechanism if possible.
> >> >
> >> > Maybe we should support same for virtio ...
> >> > Which serial do you mean? From vpd?
> >> >
> >> > I guess you will want to keep supporting MAC for old hypervisors?
> >> >
> >> > It all seems like a reasonable thing to support in the generic core.
> >>
> >> That's the reason why I chose explicit identifier rather than rely on
> >> MAC address to bind/pair a device. MAC address can change. Even if it
> >> can't, malicious guest user can fake MAC address to skip binding.
> >>
> >> -Siwei
> >
> > Address should be sampled at device creation to prevent this
> > kind of hack. Not that it buys the malicious user much:
> > if you can poke at MAC addresses you probably already can
> > break networking.
>
> I don't understand why poking at MAC address may potentially break
> networking.
Set a MAC address to match another device on the same LAN,
packets will stop reaching that MAC.
> Unlike VF, passthrough PCI endpoint device has its freedom
> to change the MAC address. Even on a VF setup it's not neccessarily
> always safe to assume the VF's MAC address cannot or shouldn't be
> changed. That depends on the specific need whether the host admin
> wants to restrict guest from changing the MAC address, although in
> most cases it's true.
>
> I understand we can use the perm_addr to distinguish. But as said,
> this will pose limitation of flexible configuration where one can
> assign VFs with identical MAC address at all while each VF belongs to
> different PF and/or different subnet for e.g. load balancing.
> And
> furthermore, the QEMU device model never uses MAC address to be
> interpreted as an identifier, which requires to be unique per VM
> instance. Why we're introducing this inconsistency?
>
> -Siwei
Because it addresses most of the issues and is simple. That's already
much better than what we have now which is nothing unless guest
configures things manually.
I think ideally the infrastructure should suppport flexible matching of
NICs - netvsc is already reported to be moving to some kind of serial
address.
> >
> >
> >
> >
> >>
> >> >
> >> > --
> >> > MST
^ permalink raw reply [flat|nested] 114+ messages in thread
* [virtio-dev] Re: [PATCH v7 net-next 4/4] netvsc: refactor notifier/event handling code to use the failover framework
@ 2018-04-25 22:22 ` Michael S. Tsirkin
0 siblings, 0 replies; 114+ messages in thread
From: Michael S. Tsirkin @ 2018-04-25 22:22 UTC (permalink / raw)
To: Siwei Liu
Cc: Stephen Hemminger, Jiri Pirko, Sridhar Samudrala, David Miller,
Netdev, virtualization, virtio-dev, Brandeburg, Jesse,
Alexander Duyck, Jakub Kicinski, Jason Wang
On Wed, Apr 25, 2018 at 02:38:57PM -0700, Siwei Liu wrote:
> On Mon, Apr 23, 2018 at 1:06 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
> > On Mon, Apr 23, 2018 at 12:44:39PM -0700, Siwei Liu wrote:
> >> On Mon, Apr 23, 2018 at 10:56 AM, Michael S. Tsirkin <mst@redhat.com> wrote:
> >> > On Mon, Apr 23, 2018 at 10:44:40AM -0700, Stephen Hemminger wrote:
> >> >> On Mon, 23 Apr 2018 20:24:56 +0300
> >> >> "Michael S. Tsirkin" <mst@redhat.com> wrote:
> >> >>
> >> >> > On Mon, Apr 23, 2018 at 10:04:06AM -0700, Stephen Hemminger wrote:
> >> >> > > > >
> >> >> > > > >I will NAK patches to change to common code for netvsc especially the
> >> >> > > > >three device model. MS worked hard with distro vendors to support transparent
> >> >> > > > >mode, ans we really can't have a new model; or do backport.
> >> >> > > > >
> >> >> > > > >Plus, DPDK is now dependent on existing model.
> >> >> > > >
> >> >> > > > Sorry, but nobody here cares about dpdk or other similar oddities.
> >> >> > >
> >> >> > > The network device model is a userspace API, and DPDK is a userspace application.
> >> >> >
> >> >> > It is userspace but are you sure dpdk is actually poking at netdevs?
> >> >> > AFAIK it's normally banging device registers directly.
> >> >> >
> >> >> > > You can't go breaking userspace even if you don't like the application.
> >> >> >
> >> >> > Could you please explain how is the proposed patchset breaking
> >> >> > userspace? Ignoring DPDK for now, I don't think it changes the userspace
> >> >> > API at all.
> >> >> >
> >> >>
> >> >> The DPDK has a device driver vdev_netvsc which scans the Linux network devices
> >> >> to look for Linux netvsc device and the paired VF device and setup the
> >> >> DPDK environment. This setup creates a DPDK failsafe (bondingish) instance
> >> >> and sets up TAP support over the Linux netvsc device as well as the Mellanox
> >> >> VF device.
> >> >>
> >> >> So it depends on existing 2 device model. You can't go to a 3 device model
> >> >> or start hiding devices from userspace.
> >> >
> >> > Okay so how does the existing patch break that? IIUC does not go to
> >> > a 3 device model since netvsc calls failover_register directly.
> >> >
> >> >> Also, I am working on associating netvsc and VF device based on serial number
> >> >> rather than MAC address. The serial number is how Windows works now, and it makes
> >> >> sense for Linux and Windows to use the same mechanism if possible.
> >> >
> >> > Maybe we should support same for virtio ...
> >> > Which serial do you mean? From vpd?
> >> >
> >> > I guess you will want to keep supporting MAC for old hypervisors?
> >> >
> >> > It all seems like a reasonable thing to support in the generic core.
> >>
> >> That's the reason why I chose explicit identifier rather than rely on
> >> MAC address to bind/pair a device. MAC address can change. Even if it
> >> can't, malicious guest user can fake MAC address to skip binding.
> >>
> >> -Siwei
> >
> > Address should be sampled at device creation to prevent this
> > kind of hack. Not that it buys the malicious user much:
> > if you can poke at MAC addresses you probably already can
> > break networking.
>
> I don't understand why poking at MAC address may potentially break
> networking.
Set a MAC address to match another device on the same LAN,
packets will stop reaching that MAC.
> Unlike VF, passthrough PCI endpoint device has its freedom
> to change the MAC address. Even on a VF setup it's not neccessarily
> always safe to assume the VF's MAC address cannot or shouldn't be
> changed. That depends on the specific need whether the host admin
> wants to restrict guest from changing the MAC address, although in
> most cases it's true.
>
> I understand we can use the perm_addr to distinguish. But as said,
> this will pose limitation of flexible configuration where one can
> assign VFs with identical MAC address at all while each VF belongs to
> different PF and/or different subnet for e.g. load balancing.
> And
> furthermore, the QEMU device model never uses MAC address to be
> interpreted as an identifier, which requires to be unique per VM
> instance. Why we're introducing this inconsistency?
>
> -Siwei
Because it addresses most of the issues and is simple. That's already
much better than what we have now which is nothing unless guest
configures things manually.
I think ideally the infrastructure should suppport flexible matching of
NICs - netvsc is already reported to be moving to some kind of serial
address.
> >
> >
> >
> >
> >>
> >> >
> >> > --
> >> > MST
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 net-next 4/4] netvsc: refactor notifier/event handling code to use the failover framework
2018-04-25 22:22 ` [virtio-dev] " Michael S. Tsirkin
@ 2018-04-25 22:57 ` Siwei Liu
-1 siblings, 0 replies; 114+ messages in thread
From: Siwei Liu @ 2018-04-25 22:57 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Stephen Hemminger, Jiri Pirko, Sridhar Samudrala, David Miller,
Netdev, virtualization, virtio-dev, Brandeburg, Jesse,
Alexander Duyck, Jakub Kicinski, Jason Wang
On Wed, Apr 25, 2018 at 3:22 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
> On Wed, Apr 25, 2018 at 02:38:57PM -0700, Siwei Liu wrote:
>> On Mon, Apr 23, 2018 at 1:06 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
>> > On Mon, Apr 23, 2018 at 12:44:39PM -0700, Siwei Liu wrote:
>> >> On Mon, Apr 23, 2018 at 10:56 AM, Michael S. Tsirkin <mst@redhat.com> wrote:
>> >> > On Mon, Apr 23, 2018 at 10:44:40AM -0700, Stephen Hemminger wrote:
>> >> >> On Mon, 23 Apr 2018 20:24:56 +0300
>> >> >> "Michael S. Tsirkin" <mst@redhat.com> wrote:
>> >> >>
>> >> >> > On Mon, Apr 23, 2018 at 10:04:06AM -0700, Stephen Hemminger wrote:
>> >> >> > > > >
>> >> >> > > > >I will NAK patches to change to common code for netvsc especially the
>> >> >> > > > >three device model. MS worked hard with distro vendors to support transparent
>> >> >> > > > >mode, ans we really can't have a new model; or do backport.
>> >> >> > > > >
>> >> >> > > > >Plus, DPDK is now dependent on existing model.
>> >> >> > > >
>> >> >> > > > Sorry, but nobody here cares about dpdk or other similar oddities.
>> >> >> > >
>> >> >> > > The network device model is a userspace API, and DPDK is a userspace application.
>> >> >> >
>> >> >> > It is userspace but are you sure dpdk is actually poking at netdevs?
>> >> >> > AFAIK it's normally banging device registers directly.
>> >> >> >
>> >> >> > > You can't go breaking userspace even if you don't like the application.
>> >> >> >
>> >> >> > Could you please explain how is the proposed patchset breaking
>> >> >> > userspace? Ignoring DPDK for now, I don't think it changes the userspace
>> >> >> > API at all.
>> >> >> >
>> >> >>
>> >> >> The DPDK has a device driver vdev_netvsc which scans the Linux network devices
>> >> >> to look for Linux netvsc device and the paired VF device and setup the
>> >> >> DPDK environment. This setup creates a DPDK failsafe (bondingish) instance
>> >> >> and sets up TAP support over the Linux netvsc device as well as the Mellanox
>> >> >> VF device.
>> >> >>
>> >> >> So it depends on existing 2 device model. You can't go to a 3 device model
>> >> >> or start hiding devices from userspace.
>> >> >
>> >> > Okay so how does the existing patch break that? IIUC does not go to
>> >> > a 3 device model since netvsc calls failover_register directly.
>> >> >
>> >> >> Also, I am working on associating netvsc and VF device based on serial number
>> >> >> rather than MAC address. The serial number is how Windows works now, and it makes
>> >> >> sense for Linux and Windows to use the same mechanism if possible.
>> >> >
>> >> > Maybe we should support same for virtio ...
>> >> > Which serial do you mean? From vpd?
>> >> >
>> >> > I guess you will want to keep supporting MAC for old hypervisors?
>> >> >
>> >> > It all seems like a reasonable thing to support in the generic core.
>> >>
>> >> That's the reason why I chose explicit identifier rather than rely on
>> >> MAC address to bind/pair a device. MAC address can change. Even if it
>> >> can't, malicious guest user can fake MAC address to skip binding.
>> >>
>> >> -Siwei
>> >
>> > Address should be sampled at device creation to prevent this
>> > kind of hack. Not that it buys the malicious user much:
>> > if you can poke at MAC addresses you probably already can
>> > break networking.
>>
>> I don't understand why poking at MAC address may potentially break
>> networking.
>
> Set a MAC address to match another device on the same LAN,
> packets will stop reaching that MAC.
What I meant was guest users may create a virtual link, say veth that
has exactly the same MAC address as that for the VF, which can easily
get around of the binding procedure. There's no explicit flag to
identify a VF or pass-through device AFAIK. And sometimes this happens
maybe due to user misconfiguring the link. This process should be
hardened to avoid from any potential configuration errors.
>
>> Unlike VF, passthrough PCI endpoint device has its freedom
>> to change the MAC address. Even on a VF setup it's not neccessarily
>> always safe to assume the VF's MAC address cannot or shouldn't be
>> changed. That depends on the specific need whether the host admin
>> wants to restrict guest from changing the MAC address, although in
>> most cases it's true.
>>
>> I understand we can use the perm_addr to distinguish. But as said,
>> this will pose limitation of flexible configuration where one can
>> assign VFs with identical MAC address at all while each VF belongs to
>> different PF and/or different subnet for e.g. load balancing.
>> And
>> furthermore, the QEMU device model never uses MAC address to be
>> interpreted as an identifier, which requires to be unique per VM
>> instance. Why we're introducing this inconsistency?
>>
>> -Siwei
>
> Because it addresses most of the issues and is simple. That's already
> much better than what we have now which is nothing unless guest
> configures things manually.
Did you see my QEMU patch for using BDF as the grouping identifier?
And there can be others like what you suggested, but the point is that
it's requried to support explicit grouping mechanism from day one,
before the backup property cast into stones. This is orthogonal to
device model being proposed, be it 1-netdev or not. Delaying it would
just mean support and compatibility burden, appearing more like a
design flaw rather than a feature to add later on.
>
> I think ideally the infrastructure should suppport flexible matching of
> NICs - netvsc is already reported to be moving to some kind of serial
> address.
>
As Stephen said, Hyper-V supports the serial UUID thing from day-one.
It's just the Linux netvsc guest driver itself does not leverage that
ID from the very beginging.
Regards,
-Siwei
>
>> >
>> >
>> >
>> >
>> >>
>> >> >
>> >> > --
>> >> > MST
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 net-next 4/4] netvsc: refactor notifier/event handling code to use the failover framework
2018-04-25 22:22 ` [virtio-dev] " Michael S. Tsirkin
(?)
(?)
@ 2018-04-25 22:57 ` Siwei Liu
-1 siblings, 0 replies; 114+ messages in thread
From: Siwei Liu @ 2018-04-25 22:57 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Alexander Duyck, virtio-dev, Jiri Pirko, Jakub Kicinski,
Sridhar Samudrala, virtualization, Netdev, David Miller
On Wed, Apr 25, 2018 at 3:22 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
> On Wed, Apr 25, 2018 at 02:38:57PM -0700, Siwei Liu wrote:
>> On Mon, Apr 23, 2018 at 1:06 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
>> > On Mon, Apr 23, 2018 at 12:44:39PM -0700, Siwei Liu wrote:
>> >> On Mon, Apr 23, 2018 at 10:56 AM, Michael S. Tsirkin <mst@redhat.com> wrote:
>> >> > On Mon, Apr 23, 2018 at 10:44:40AM -0700, Stephen Hemminger wrote:
>> >> >> On Mon, 23 Apr 2018 20:24:56 +0300
>> >> >> "Michael S. Tsirkin" <mst@redhat.com> wrote:
>> >> >>
>> >> >> > On Mon, Apr 23, 2018 at 10:04:06AM -0700, Stephen Hemminger wrote:
>> >> >> > > > >
>> >> >> > > > >I will NAK patches to change to common code for netvsc especially the
>> >> >> > > > >three device model. MS worked hard with distro vendors to support transparent
>> >> >> > > > >mode, ans we really can't have a new model; or do backport.
>> >> >> > > > >
>> >> >> > > > >Plus, DPDK is now dependent on existing model.
>> >> >> > > >
>> >> >> > > > Sorry, but nobody here cares about dpdk or other similar oddities.
>> >> >> > >
>> >> >> > > The network device model is a userspace API, and DPDK is a userspace application.
>> >> >> >
>> >> >> > It is userspace but are you sure dpdk is actually poking at netdevs?
>> >> >> > AFAIK it's normally banging device registers directly.
>> >> >> >
>> >> >> > > You can't go breaking userspace even if you don't like the application.
>> >> >> >
>> >> >> > Could you please explain how is the proposed patchset breaking
>> >> >> > userspace? Ignoring DPDK for now, I don't think it changes the userspace
>> >> >> > API at all.
>> >> >> >
>> >> >>
>> >> >> The DPDK has a device driver vdev_netvsc which scans the Linux network devices
>> >> >> to look for Linux netvsc device and the paired VF device and setup the
>> >> >> DPDK environment. This setup creates a DPDK failsafe (bondingish) instance
>> >> >> and sets up TAP support over the Linux netvsc device as well as the Mellanox
>> >> >> VF device.
>> >> >>
>> >> >> So it depends on existing 2 device model. You can't go to a 3 device model
>> >> >> or start hiding devices from userspace.
>> >> >
>> >> > Okay so how does the existing patch break that? IIUC does not go to
>> >> > a 3 device model since netvsc calls failover_register directly.
>> >> >
>> >> >> Also, I am working on associating netvsc and VF device based on serial number
>> >> >> rather than MAC address. The serial number is how Windows works now, and it makes
>> >> >> sense for Linux and Windows to use the same mechanism if possible.
>> >> >
>> >> > Maybe we should support same for virtio ...
>> >> > Which serial do you mean? From vpd?
>> >> >
>> >> > I guess you will want to keep supporting MAC for old hypervisors?
>> >> >
>> >> > It all seems like a reasonable thing to support in the generic core.
>> >>
>> >> That's the reason why I chose explicit identifier rather than rely on
>> >> MAC address to bind/pair a device. MAC address can change. Even if it
>> >> can't, malicious guest user can fake MAC address to skip binding.
>> >>
>> >> -Siwei
>> >
>> > Address should be sampled at device creation to prevent this
>> > kind of hack. Not that it buys the malicious user much:
>> > if you can poke at MAC addresses you probably already can
>> > break networking.
>>
>> I don't understand why poking at MAC address may potentially break
>> networking.
>
> Set a MAC address to match another device on the same LAN,
> packets will stop reaching that MAC.
What I meant was guest users may create a virtual link, say veth that
has exactly the same MAC address as that for the VF, which can easily
get around of the binding procedure. There's no explicit flag to
identify a VF or pass-through device AFAIK. And sometimes this happens
maybe due to user misconfiguring the link. This process should be
hardened to avoid from any potential configuration errors.
>
>> Unlike VF, passthrough PCI endpoint device has its freedom
>> to change the MAC address. Even on a VF setup it's not neccessarily
>> always safe to assume the VF's MAC address cannot or shouldn't be
>> changed. That depends on the specific need whether the host admin
>> wants to restrict guest from changing the MAC address, although in
>> most cases it's true.
>>
>> I understand we can use the perm_addr to distinguish. But as said,
>> this will pose limitation of flexible configuration where one can
>> assign VFs with identical MAC address at all while each VF belongs to
>> different PF and/or different subnet for e.g. load balancing.
>> And
>> furthermore, the QEMU device model never uses MAC address to be
>> interpreted as an identifier, which requires to be unique per VM
>> instance. Why we're introducing this inconsistency?
>>
>> -Siwei
>
> Because it addresses most of the issues and is simple. That's already
> much better than what we have now which is nothing unless guest
> configures things manually.
Did you see my QEMU patch for using BDF as the grouping identifier?
And there can be others like what you suggested, but the point is that
it's requried to support explicit grouping mechanism from day one,
before the backup property cast into stones. This is orthogonal to
device model being proposed, be it 1-netdev or not. Delaying it would
just mean support and compatibility burden, appearing more like a
design flaw rather than a feature to add later on.
>
> I think ideally the infrastructure should suppport flexible matching of
> NICs - netvsc is already reported to be moving to some kind of serial
> address.
>
As Stephen said, Hyper-V supports the serial UUID thing from day-one.
It's just the Linux netvsc guest driver itself does not leverage that
ID from the very beginging.
Regards,
-Siwei
>
>> >
>> >
>> >
>> >
>> >>
>> >> >
>> >> > --
>> >> > MST
^ permalink raw reply [flat|nested] 114+ messages in thread
* [virtio-dev] Re: [PATCH v7 net-next 4/4] netvsc: refactor notifier/event handling code to use the failover framework
@ 2018-04-25 22:57 ` Siwei Liu
0 siblings, 0 replies; 114+ messages in thread
From: Siwei Liu @ 2018-04-25 22:57 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Stephen Hemminger, Jiri Pirko, Sridhar Samudrala, David Miller,
Netdev, virtualization, virtio-dev, Brandeburg, Jesse,
Alexander Duyck, Jakub Kicinski, Jason Wang
On Wed, Apr 25, 2018 at 3:22 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
> On Wed, Apr 25, 2018 at 02:38:57PM -0700, Siwei Liu wrote:
>> On Mon, Apr 23, 2018 at 1:06 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
>> > On Mon, Apr 23, 2018 at 12:44:39PM -0700, Siwei Liu wrote:
>> >> On Mon, Apr 23, 2018 at 10:56 AM, Michael S. Tsirkin <mst@redhat.com> wrote:
>> >> > On Mon, Apr 23, 2018 at 10:44:40AM -0700, Stephen Hemminger wrote:
>> >> >> On Mon, 23 Apr 2018 20:24:56 +0300
>> >> >> "Michael S. Tsirkin" <mst@redhat.com> wrote:
>> >> >>
>> >> >> > On Mon, Apr 23, 2018 at 10:04:06AM -0700, Stephen Hemminger wrote:
>> >> >> > > > >
>> >> >> > > > >I will NAK patches to change to common code for netvsc especially the
>> >> >> > > > >three device model. MS worked hard with distro vendors to support transparent
>> >> >> > > > >mode, ans we really can't have a new model; or do backport.
>> >> >> > > > >
>> >> >> > > > >Plus, DPDK is now dependent on existing model.
>> >> >> > > >
>> >> >> > > > Sorry, but nobody here cares about dpdk or other similar oddities.
>> >> >> > >
>> >> >> > > The network device model is a userspace API, and DPDK is a userspace application.
>> >> >> >
>> >> >> > It is userspace but are you sure dpdk is actually poking at netdevs?
>> >> >> > AFAIK it's normally banging device registers directly.
>> >> >> >
>> >> >> > > You can't go breaking userspace even if you don't like the application.
>> >> >> >
>> >> >> > Could you please explain how is the proposed patchset breaking
>> >> >> > userspace? Ignoring DPDK for now, I don't think it changes the userspace
>> >> >> > API at all.
>> >> >> >
>> >> >>
>> >> >> The DPDK has a device driver vdev_netvsc which scans the Linux network devices
>> >> >> to look for Linux netvsc device and the paired VF device and setup the
>> >> >> DPDK environment. This setup creates a DPDK failsafe (bondingish) instance
>> >> >> and sets up TAP support over the Linux netvsc device as well as the Mellanox
>> >> >> VF device.
>> >> >>
>> >> >> So it depends on existing 2 device model. You can't go to a 3 device model
>> >> >> or start hiding devices from userspace.
>> >> >
>> >> > Okay so how does the existing patch break that? IIUC does not go to
>> >> > a 3 device model since netvsc calls failover_register directly.
>> >> >
>> >> >> Also, I am working on associating netvsc and VF device based on serial number
>> >> >> rather than MAC address. The serial number is how Windows works now, and it makes
>> >> >> sense for Linux and Windows to use the same mechanism if possible.
>> >> >
>> >> > Maybe we should support same for virtio ...
>> >> > Which serial do you mean? From vpd?
>> >> >
>> >> > I guess you will want to keep supporting MAC for old hypervisors?
>> >> >
>> >> > It all seems like a reasonable thing to support in the generic core.
>> >>
>> >> That's the reason why I chose explicit identifier rather than rely on
>> >> MAC address to bind/pair a device. MAC address can change. Even if it
>> >> can't, malicious guest user can fake MAC address to skip binding.
>> >>
>> >> -Siwei
>> >
>> > Address should be sampled at device creation to prevent this
>> > kind of hack. Not that it buys the malicious user much:
>> > if you can poke at MAC addresses you probably already can
>> > break networking.
>>
>> I don't understand why poking at MAC address may potentially break
>> networking.
>
> Set a MAC address to match another device on the same LAN,
> packets will stop reaching that MAC.
What I meant was guest users may create a virtual link, say veth that
has exactly the same MAC address as that for the VF, which can easily
get around of the binding procedure. There's no explicit flag to
identify a VF or pass-through device AFAIK. And sometimes this happens
maybe due to user misconfiguring the link. This process should be
hardened to avoid from any potential configuration errors.
>
>> Unlike VF, passthrough PCI endpoint device has its freedom
>> to change the MAC address. Even on a VF setup it's not neccessarily
>> always safe to assume the VF's MAC address cannot or shouldn't be
>> changed. That depends on the specific need whether the host admin
>> wants to restrict guest from changing the MAC address, although in
>> most cases it's true.
>>
>> I understand we can use the perm_addr to distinguish. But as said,
>> this will pose limitation of flexible configuration where one can
>> assign VFs with identical MAC address at all while each VF belongs to
>> different PF and/or different subnet for e.g. load balancing.
>> And
>> furthermore, the QEMU device model never uses MAC address to be
>> interpreted as an identifier, which requires to be unique per VM
>> instance. Why we're introducing this inconsistency?
>>
>> -Siwei
>
> Because it addresses most of the issues and is simple. That's already
> much better than what we have now which is nothing unless guest
> configures things manually.
Did you see my QEMU patch for using BDF as the grouping identifier?
And there can be others like what you suggested, but the point is that
it's requried to support explicit grouping mechanism from day one,
before the backup property cast into stones. This is orthogonal to
device model being proposed, be it 1-netdev or not. Delaying it would
just mean support and compatibility burden, appearing more like a
design flaw rather than a feature to add later on.
>
> I think ideally the infrastructure should suppport flexible matching of
> NICs - netvsc is already reported to be moving to some kind of serial
> address.
>
As Stephen said, Hyper-V supports the serial UUID thing from day-one.
It's just the Linux netvsc guest driver itself does not leverage that
ID from the very beginging.
Regards,
-Siwei
>
>> >
>> >
>> >
>> >
>> >>
>> >> >
>> >> > --
>> >> > MST
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 net-next 4/4] netvsc: refactor notifier/event handling code to use the failover framework
2018-04-25 22:57 ` [virtio-dev] " Siwei Liu
(?)
(?)
@ 2018-04-26 0:18 ` Stephen Hemminger
2018-04-26 2:43 ` Michael S. Tsirkin
2018-04-26 2:43 ` [virtio-dev] " Michael S. Tsirkin
-1 siblings, 2 replies; 114+ messages in thread
From: Stephen Hemminger @ 2018-04-26 0:18 UTC (permalink / raw)
To: Siwei Liu
Cc: Michael S. Tsirkin, Jiri Pirko, Sridhar Samudrala, David Miller,
Netdev, virtualization, virtio-dev, Brandeburg, Jesse,
Alexander Duyck, Jakub Kicinski, Jason Wang
On Wed, 25 Apr 2018 15:57:57 -0700
Siwei Liu <loseweigh@gmail.com> wrote:
> >
> > I think ideally the infrastructure should suppport flexible matching of
> > NICs - netvsc is already reported to be moving to some kind of serial
> > address.
> >
> As Stephen said, Hyper-V supports the serial UUID thing from day-one.
> It's just the Linux netvsc guest driver itself does not leverage that
> ID from the very beginging.
>
> Regards,
> -Siwei
I am working on that. The problem is that it requires some messy work
to go from VF netdevice back to PCI device and from there to the PCI hyperv
host infrastructure to find the serial number.
I was hoping that the serial number would also match the concept of PCI Express
device serial number. But that is a completely different ID :-(
The PCI-E serial number is a hardware serial number more like MAC address.
The Hyper-V serial number is more like PCI slot value.
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 net-next 4/4] netvsc: refactor notifier/event handling code to use the failover framework
2018-04-25 22:57 ` [virtio-dev] " Siwei Liu
(?)
@ 2018-04-26 0:18 ` Stephen Hemminger
-1 siblings, 0 replies; 114+ messages in thread
From: Stephen Hemminger @ 2018-04-26 0:18 UTC (permalink / raw)
To: Siwei Liu
Cc: Alexander Duyck, virtio-dev, Jiri Pirko, Michael S. Tsirkin,
Jakub Kicinski, Sridhar Samudrala, virtualization, Netdev,
David Miller
On Wed, 25 Apr 2018 15:57:57 -0700
Siwei Liu <loseweigh@gmail.com> wrote:
> >
> > I think ideally the infrastructure should suppport flexible matching of
> > NICs - netvsc is already reported to be moving to some kind of serial
> > address.
> >
> As Stephen said, Hyper-V supports the serial UUID thing from day-one.
> It's just the Linux netvsc guest driver itself does not leverage that
> ID from the very beginging.
>
> Regards,
> -Siwei
I am working on that. The problem is that it requires some messy work
to go from VF netdevice back to PCI device and from there to the PCI hyperv
host infrastructure to find the serial number.
I was hoping that the serial number would also match the concept of PCI Express
device serial number. But that is a completely different ID :-(
The PCI-E serial number is a hardware serial number more like MAC address.
The Hyper-V serial number is more like PCI slot value.
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 net-next 4/4] netvsc: refactor notifier/event handling code to use the failover framework
2018-04-25 22:57 ` [virtio-dev] " Siwei Liu
@ 2018-04-26 2:28 ` Michael S. Tsirkin
-1 siblings, 0 replies; 114+ messages in thread
From: Michael S. Tsirkin @ 2018-04-26 2:28 UTC (permalink / raw)
To: Siwei Liu
Cc: Stephen Hemminger, Jiri Pirko, Sridhar Samudrala, David Miller,
Netdev, virtualization, virtio-dev, Brandeburg, Jesse,
Alexander Duyck, Jakub Kicinski, Jason Wang
On Wed, Apr 25, 2018 at 03:57:57PM -0700, Siwei Liu wrote:
> On Wed, Apr 25, 2018 at 3:22 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
> > On Wed, Apr 25, 2018 at 02:38:57PM -0700, Siwei Liu wrote:
> >> On Mon, Apr 23, 2018 at 1:06 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
> >> > On Mon, Apr 23, 2018 at 12:44:39PM -0700, Siwei Liu wrote:
> >> >> On Mon, Apr 23, 2018 at 10:56 AM, Michael S. Tsirkin <mst@redhat.com> wrote:
> >> >> > On Mon, Apr 23, 2018 at 10:44:40AM -0700, Stephen Hemminger wrote:
> >> >> >> On Mon, 23 Apr 2018 20:24:56 +0300
> >> >> >> "Michael S. Tsirkin" <mst@redhat.com> wrote:
> >> >> >>
> >> >> >> > On Mon, Apr 23, 2018 at 10:04:06AM -0700, Stephen Hemminger wrote:
> >> >> >> > > > >
> >> >> >> > > > >I will NAK patches to change to common code for netvsc especially the
> >> >> >> > > > >three device model. MS worked hard with distro vendors to support transparent
> >> >> >> > > > >mode, ans we really can't have a new model; or do backport.
> >> >> >> > > > >
> >> >> >> > > > >Plus, DPDK is now dependent on existing model.
> >> >> >> > > >
> >> >> >> > > > Sorry, but nobody here cares about dpdk or other similar oddities.
> >> >> >> > >
> >> >> >> > > The network device model is a userspace API, and DPDK is a userspace application.
> >> >> >> >
> >> >> >> > It is userspace but are you sure dpdk is actually poking at netdevs?
> >> >> >> > AFAIK it's normally banging device registers directly.
> >> >> >> >
> >> >> >> > > You can't go breaking userspace even if you don't like the application.
> >> >> >> >
> >> >> >> > Could you please explain how is the proposed patchset breaking
> >> >> >> > userspace? Ignoring DPDK for now, I don't think it changes the userspace
> >> >> >> > API at all.
> >> >> >> >
> >> >> >>
> >> >> >> The DPDK has a device driver vdev_netvsc which scans the Linux network devices
> >> >> >> to look for Linux netvsc device and the paired VF device and setup the
> >> >> >> DPDK environment. This setup creates a DPDK failsafe (bondingish) instance
> >> >> >> and sets up TAP support over the Linux netvsc device as well as the Mellanox
> >> >> >> VF device.
> >> >> >>
> >> >> >> So it depends on existing 2 device model. You can't go to a 3 device model
> >> >> >> or start hiding devices from userspace.
> >> >> >
> >> >> > Okay so how does the existing patch break that? IIUC does not go to
> >> >> > a 3 device model since netvsc calls failover_register directly.
> >> >> >
> >> >> >> Also, I am working on associating netvsc and VF device based on serial number
> >> >> >> rather than MAC address. The serial number is how Windows works now, and it makes
> >> >> >> sense for Linux and Windows to use the same mechanism if possible.
> >> >> >
> >> >> > Maybe we should support same for virtio ...
> >> >> > Which serial do you mean? From vpd?
> >> >> >
> >> >> > I guess you will want to keep supporting MAC for old hypervisors?
> >> >> >
> >> >> > It all seems like a reasonable thing to support in the generic core.
> >> >>
> >> >> That's the reason why I chose explicit identifier rather than rely on
> >> >> MAC address to bind/pair a device. MAC address can change. Even if it
> >> >> can't, malicious guest user can fake MAC address to skip binding.
> >> >>
> >> >> -Siwei
> >> >
> >> > Address should be sampled at device creation to prevent this
> >> > kind of hack. Not that it buys the malicious user much:
> >> > if you can poke at MAC addresses you probably already can
> >> > break networking.
> >>
> >> I don't understand why poking at MAC address may potentially break
> >> networking.
> >
> > Set a MAC address to match another device on the same LAN,
> > packets will stop reaching that MAC.
>
> What I meant was guest users may create a virtual link, say veth that
> has exactly the same MAC address as that for the VF, which can easily
> get around of the binding procedure.
This patchset limits binding to PCI devices so it won't be affected
by any hacks around virtual devices.
> There's no explicit flag to
> identify a VF or pass-through device AFAIK. And sometimes this happens
> maybe due to user misconfiguring the link. This process should be
> hardened to avoid from any potential configuration errors.
They are still PCI devices though.
> >
> >> Unlike VF, passthrough PCI endpoint device has its freedom
> >> to change the MAC address. Even on a VF setup it's not neccessarily
> >> always safe to assume the VF's MAC address cannot or shouldn't be
> >> changed. That depends on the specific need whether the host admin
> >> wants to restrict guest from changing the MAC address, although in
> >> most cases it's true.
> >>
> >> I understand we can use the perm_addr to distinguish. But as said,
> >> this will pose limitation of flexible configuration where one can
> >> assign VFs with identical MAC address at all while each VF belongs to
> >> different PF and/or different subnet for e.g. load balancing.
> >> And
> >> furthermore, the QEMU device model never uses MAC address to be
> >> interpreted as an identifier, which requires to be unique per VM
> >> instance. Why we're introducing this inconsistency?
> >>
> >> -Siwei
> >
> > Because it addresses most of the issues and is simple. That's already
> > much better than what we have now which is nothing unless guest
> > configures things manually.
>
> Did you see my QEMU patch for using BDF as the grouping identifier?
Yes. And I don't think it can work because bus numbers are
guest specified.
> And there can be others like what you suggested, but the point is that
> it's requried to support explicit grouping mechanism from day one,
> before the backup property cast into stones.
Let's start with addressing simple configs with just two NICs.
Down the road I can see possible extensions that can work: for example,
require that devices are on the same pci bridge. Or we could even make
the virtio device actually include a pci bridge (as part of same
or a child function), the PT would have to be
behind it.
As long as we are not breaking anything, adding more flags to fix
non-working configurations is always fair game.
> This is orthogonal to
> device model being proposed, be it 1-netdev or not. Delaying it would
> just mean support and compatibility burden, appearing more like a
> design flaw rather than a feature to add later on.
Well it's mostly myself who gets to support it, and I see the device
model as much more fundamental as userspace will come to depend
on it. So I'm not too worried, let's take this one step at a time.
> >
> > I think ideally the infrastructure should suppport flexible matching of
> > NICs - netvsc is already reported to be moving to some kind of serial
> > address.
> >
> As Stephen said, Hyper-V supports the serial UUID thing from day-one.
> It's just the Linux netvsc guest driver itself does not leverage that
> ID from the very beginging.
>
> Regards,
> -Siwei
We could add something like this, too. For example,
we could add a virtual VPD capability with a UUID.
Do you know how exactly does hyperv pass the UUID for NICs?
> >
> >> >
> >> >
> >> >
> >> >
> >> >>
> >> >> >
> >> >> > --
> >> >> > MST
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 net-next 4/4] netvsc: refactor notifier/event handling code to use the failover framework
2018-04-25 22:57 ` [virtio-dev] " Siwei Liu
` (2 preceding siblings ...)
(?)
@ 2018-04-26 2:28 ` Michael S. Tsirkin
-1 siblings, 0 replies; 114+ messages in thread
From: Michael S. Tsirkin @ 2018-04-26 2:28 UTC (permalink / raw)
To: Siwei Liu
Cc: Alexander Duyck, virtio-dev, Jiri Pirko, Jakub Kicinski,
Sridhar Samudrala, virtualization, Netdev, David Miller
On Wed, Apr 25, 2018 at 03:57:57PM -0700, Siwei Liu wrote:
> On Wed, Apr 25, 2018 at 3:22 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
> > On Wed, Apr 25, 2018 at 02:38:57PM -0700, Siwei Liu wrote:
> >> On Mon, Apr 23, 2018 at 1:06 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
> >> > On Mon, Apr 23, 2018 at 12:44:39PM -0700, Siwei Liu wrote:
> >> >> On Mon, Apr 23, 2018 at 10:56 AM, Michael S. Tsirkin <mst@redhat.com> wrote:
> >> >> > On Mon, Apr 23, 2018 at 10:44:40AM -0700, Stephen Hemminger wrote:
> >> >> >> On Mon, 23 Apr 2018 20:24:56 +0300
> >> >> >> "Michael S. Tsirkin" <mst@redhat.com> wrote:
> >> >> >>
> >> >> >> > On Mon, Apr 23, 2018 at 10:04:06AM -0700, Stephen Hemminger wrote:
> >> >> >> > > > >
> >> >> >> > > > >I will NAK patches to change to common code for netvsc especially the
> >> >> >> > > > >three device model. MS worked hard with distro vendors to support transparent
> >> >> >> > > > >mode, ans we really can't have a new model; or do backport.
> >> >> >> > > > >
> >> >> >> > > > >Plus, DPDK is now dependent on existing model.
> >> >> >> > > >
> >> >> >> > > > Sorry, but nobody here cares about dpdk or other similar oddities.
> >> >> >> > >
> >> >> >> > > The network device model is a userspace API, and DPDK is a userspace application.
> >> >> >> >
> >> >> >> > It is userspace but are you sure dpdk is actually poking at netdevs?
> >> >> >> > AFAIK it's normally banging device registers directly.
> >> >> >> >
> >> >> >> > > You can't go breaking userspace even if you don't like the application.
> >> >> >> >
> >> >> >> > Could you please explain how is the proposed patchset breaking
> >> >> >> > userspace? Ignoring DPDK for now, I don't think it changes the userspace
> >> >> >> > API at all.
> >> >> >> >
> >> >> >>
> >> >> >> The DPDK has a device driver vdev_netvsc which scans the Linux network devices
> >> >> >> to look for Linux netvsc device and the paired VF device and setup the
> >> >> >> DPDK environment. This setup creates a DPDK failsafe (bondingish) instance
> >> >> >> and sets up TAP support over the Linux netvsc device as well as the Mellanox
> >> >> >> VF device.
> >> >> >>
> >> >> >> So it depends on existing 2 device model. You can't go to a 3 device model
> >> >> >> or start hiding devices from userspace.
> >> >> >
> >> >> > Okay so how does the existing patch break that? IIUC does not go to
> >> >> > a 3 device model since netvsc calls failover_register directly.
> >> >> >
> >> >> >> Also, I am working on associating netvsc and VF device based on serial number
> >> >> >> rather than MAC address. The serial number is how Windows works now, and it makes
> >> >> >> sense for Linux and Windows to use the same mechanism if possible.
> >> >> >
> >> >> > Maybe we should support same for virtio ...
> >> >> > Which serial do you mean? From vpd?
> >> >> >
> >> >> > I guess you will want to keep supporting MAC for old hypervisors?
> >> >> >
> >> >> > It all seems like a reasonable thing to support in the generic core.
> >> >>
> >> >> That's the reason why I chose explicit identifier rather than rely on
> >> >> MAC address to bind/pair a device. MAC address can change. Even if it
> >> >> can't, malicious guest user can fake MAC address to skip binding.
> >> >>
> >> >> -Siwei
> >> >
> >> > Address should be sampled at device creation to prevent this
> >> > kind of hack. Not that it buys the malicious user much:
> >> > if you can poke at MAC addresses you probably already can
> >> > break networking.
> >>
> >> I don't understand why poking at MAC address may potentially break
> >> networking.
> >
> > Set a MAC address to match another device on the same LAN,
> > packets will stop reaching that MAC.
>
> What I meant was guest users may create a virtual link, say veth that
> has exactly the same MAC address as that for the VF, which can easily
> get around of the binding procedure.
This patchset limits binding to PCI devices so it won't be affected
by any hacks around virtual devices.
> There's no explicit flag to
> identify a VF or pass-through device AFAIK. And sometimes this happens
> maybe due to user misconfiguring the link. This process should be
> hardened to avoid from any potential configuration errors.
They are still PCI devices though.
> >
> >> Unlike VF, passthrough PCI endpoint device has its freedom
> >> to change the MAC address. Even on a VF setup it's not neccessarily
> >> always safe to assume the VF's MAC address cannot or shouldn't be
> >> changed. That depends on the specific need whether the host admin
> >> wants to restrict guest from changing the MAC address, although in
> >> most cases it's true.
> >>
> >> I understand we can use the perm_addr to distinguish. But as said,
> >> this will pose limitation of flexible configuration where one can
> >> assign VFs with identical MAC address at all while each VF belongs to
> >> different PF and/or different subnet for e.g. load balancing.
> >> And
> >> furthermore, the QEMU device model never uses MAC address to be
> >> interpreted as an identifier, which requires to be unique per VM
> >> instance. Why we're introducing this inconsistency?
> >>
> >> -Siwei
> >
> > Because it addresses most of the issues and is simple. That's already
> > much better than what we have now which is nothing unless guest
> > configures things manually.
>
> Did you see my QEMU patch for using BDF as the grouping identifier?
Yes. And I don't think it can work because bus numbers are
guest specified.
> And there can be others like what you suggested, but the point is that
> it's requried to support explicit grouping mechanism from day one,
> before the backup property cast into stones.
Let's start with addressing simple configs with just two NICs.
Down the road I can see possible extensions that can work: for example,
require that devices are on the same pci bridge. Or we could even make
the virtio device actually include a pci bridge (as part of same
or a child function), the PT would have to be
behind it.
As long as we are not breaking anything, adding more flags to fix
non-working configurations is always fair game.
> This is orthogonal to
> device model being proposed, be it 1-netdev or not. Delaying it would
> just mean support and compatibility burden, appearing more like a
> design flaw rather than a feature to add later on.
Well it's mostly myself who gets to support it, and I see the device
model as much more fundamental as userspace will come to depend
on it. So I'm not too worried, let's take this one step at a time.
> >
> > I think ideally the infrastructure should suppport flexible matching of
> > NICs - netvsc is already reported to be moving to some kind of serial
> > address.
> >
> As Stephen said, Hyper-V supports the serial UUID thing from day-one.
> It's just the Linux netvsc guest driver itself does not leverage that
> ID from the very beginging.
>
> Regards,
> -Siwei
We could add something like this, too. For example,
we could add a virtual VPD capability with a UUID.
Do you know how exactly does hyperv pass the UUID for NICs?
> >
> >> >
> >> >
> >> >
> >> >
> >> >>
> >> >> >
> >> >> > --
> >> >> > MST
^ permalink raw reply [flat|nested] 114+ messages in thread
* [virtio-dev] Re: [PATCH v7 net-next 4/4] netvsc: refactor notifier/event handling code to use the failover framework
@ 2018-04-26 2:28 ` Michael S. Tsirkin
0 siblings, 0 replies; 114+ messages in thread
From: Michael S. Tsirkin @ 2018-04-26 2:28 UTC (permalink / raw)
To: Siwei Liu
Cc: Stephen Hemminger, Jiri Pirko, Sridhar Samudrala, David Miller,
Netdev, virtualization, virtio-dev, Brandeburg, Jesse,
Alexander Duyck, Jakub Kicinski, Jason Wang
On Wed, Apr 25, 2018 at 03:57:57PM -0700, Siwei Liu wrote:
> On Wed, Apr 25, 2018 at 3:22 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
> > On Wed, Apr 25, 2018 at 02:38:57PM -0700, Siwei Liu wrote:
> >> On Mon, Apr 23, 2018 at 1:06 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
> >> > On Mon, Apr 23, 2018 at 12:44:39PM -0700, Siwei Liu wrote:
> >> >> On Mon, Apr 23, 2018 at 10:56 AM, Michael S. Tsirkin <mst@redhat.com> wrote:
> >> >> > On Mon, Apr 23, 2018 at 10:44:40AM -0700, Stephen Hemminger wrote:
> >> >> >> On Mon, 23 Apr 2018 20:24:56 +0300
> >> >> >> "Michael S. Tsirkin" <mst@redhat.com> wrote:
> >> >> >>
> >> >> >> > On Mon, Apr 23, 2018 at 10:04:06AM -0700, Stephen Hemminger wrote:
> >> >> >> > > > >
> >> >> >> > > > >I will NAK patches to change to common code for netvsc especially the
> >> >> >> > > > >three device model. MS worked hard with distro vendors to support transparent
> >> >> >> > > > >mode, ans we really can't have a new model; or do backport.
> >> >> >> > > > >
> >> >> >> > > > >Plus, DPDK is now dependent on existing model.
> >> >> >> > > >
> >> >> >> > > > Sorry, but nobody here cares about dpdk or other similar oddities.
> >> >> >> > >
> >> >> >> > > The network device model is a userspace API, and DPDK is a userspace application.
> >> >> >> >
> >> >> >> > It is userspace but are you sure dpdk is actually poking at netdevs?
> >> >> >> > AFAIK it's normally banging device registers directly.
> >> >> >> >
> >> >> >> > > You can't go breaking userspace even if you don't like the application.
> >> >> >> >
> >> >> >> > Could you please explain how is the proposed patchset breaking
> >> >> >> > userspace? Ignoring DPDK for now, I don't think it changes the userspace
> >> >> >> > API at all.
> >> >> >> >
> >> >> >>
> >> >> >> The DPDK has a device driver vdev_netvsc which scans the Linux network devices
> >> >> >> to look for Linux netvsc device and the paired VF device and setup the
> >> >> >> DPDK environment. This setup creates a DPDK failsafe (bondingish) instance
> >> >> >> and sets up TAP support over the Linux netvsc device as well as the Mellanox
> >> >> >> VF device.
> >> >> >>
> >> >> >> So it depends on existing 2 device model. You can't go to a 3 device model
> >> >> >> or start hiding devices from userspace.
> >> >> >
> >> >> > Okay so how does the existing patch break that? IIUC does not go to
> >> >> > a 3 device model since netvsc calls failover_register directly.
> >> >> >
> >> >> >> Also, I am working on associating netvsc and VF device based on serial number
> >> >> >> rather than MAC address. The serial number is how Windows works now, and it makes
> >> >> >> sense for Linux and Windows to use the same mechanism if possible.
> >> >> >
> >> >> > Maybe we should support same for virtio ...
> >> >> > Which serial do you mean? From vpd?
> >> >> >
> >> >> > I guess you will want to keep supporting MAC for old hypervisors?
> >> >> >
> >> >> > It all seems like a reasonable thing to support in the generic core.
> >> >>
> >> >> That's the reason why I chose explicit identifier rather than rely on
> >> >> MAC address to bind/pair a device. MAC address can change. Even if it
> >> >> can't, malicious guest user can fake MAC address to skip binding.
> >> >>
> >> >> -Siwei
> >> >
> >> > Address should be sampled at device creation to prevent this
> >> > kind of hack. Not that it buys the malicious user much:
> >> > if you can poke at MAC addresses you probably already can
> >> > break networking.
> >>
> >> I don't understand why poking at MAC address may potentially break
> >> networking.
> >
> > Set a MAC address to match another device on the same LAN,
> > packets will stop reaching that MAC.
>
> What I meant was guest users may create a virtual link, say veth that
> has exactly the same MAC address as that for the VF, which can easily
> get around of the binding procedure.
This patchset limits binding to PCI devices so it won't be affected
by any hacks around virtual devices.
> There's no explicit flag to
> identify a VF or pass-through device AFAIK. And sometimes this happens
> maybe due to user misconfiguring the link. This process should be
> hardened to avoid from any potential configuration errors.
They are still PCI devices though.
> >
> >> Unlike VF, passthrough PCI endpoint device has its freedom
> >> to change the MAC address. Even on a VF setup it's not neccessarily
> >> always safe to assume the VF's MAC address cannot or shouldn't be
> >> changed. That depends on the specific need whether the host admin
> >> wants to restrict guest from changing the MAC address, although in
> >> most cases it's true.
> >>
> >> I understand we can use the perm_addr to distinguish. But as said,
> >> this will pose limitation of flexible configuration where one can
> >> assign VFs with identical MAC address at all while each VF belongs to
> >> different PF and/or different subnet for e.g. load balancing.
> >> And
> >> furthermore, the QEMU device model never uses MAC address to be
> >> interpreted as an identifier, which requires to be unique per VM
> >> instance. Why we're introducing this inconsistency?
> >>
> >> -Siwei
> >
> > Because it addresses most of the issues and is simple. That's already
> > much better than what we have now which is nothing unless guest
> > configures things manually.
>
> Did you see my QEMU patch for using BDF as the grouping identifier?
Yes. And I don't think it can work because bus numbers are
guest specified.
> And there can be others like what you suggested, but the point is that
> it's requried to support explicit grouping mechanism from day one,
> before the backup property cast into stones.
Let's start with addressing simple configs with just two NICs.
Down the road I can see possible extensions that can work: for example,
require that devices are on the same pci bridge. Or we could even make
the virtio device actually include a pci bridge (as part of same
or a child function), the PT would have to be
behind it.
As long as we are not breaking anything, adding more flags to fix
non-working configurations is always fair game.
> This is orthogonal to
> device model being proposed, be it 1-netdev or not. Delaying it would
> just mean support and compatibility burden, appearing more like a
> design flaw rather than a feature to add later on.
Well it's mostly myself who gets to support it, and I see the device
model as much more fundamental as userspace will come to depend
on it. So I'm not too worried, let's take this one step at a time.
> >
> > I think ideally the infrastructure should suppport flexible matching of
> > NICs - netvsc is already reported to be moving to some kind of serial
> > address.
> >
> As Stephen said, Hyper-V supports the serial UUID thing from day-one.
> It's just the Linux netvsc guest driver itself does not leverage that
> ID from the very beginging.
>
> Regards,
> -Siwei
We could add something like this, too. For example,
we could add a virtual VPD capability with a UUID.
Do you know how exactly does hyperv pass the UUID for NICs?
> >
> >> >
> >> >
> >> >
> >> >
> >> >>
> >> >> >
> >> >> > --
> >> >> > MST
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 net-next 4/4] netvsc: refactor notifier/event handling code to use the failover framework
2018-04-26 0:18 ` Stephen Hemminger
@ 2018-04-26 2:43 ` Michael S. Tsirkin
2018-04-26 2:43 ` [virtio-dev] " Michael S. Tsirkin
1 sibling, 0 replies; 114+ messages in thread
From: Michael S. Tsirkin @ 2018-04-26 2:43 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Siwei Liu, Jiri Pirko, Sridhar Samudrala, David Miller, Netdev,
virtualization, virtio-dev, Brandeburg, Jesse, Alexander Duyck,
Jakub Kicinski, Jason Wang
On Wed, Apr 25, 2018 at 05:18:31PM -0700, Stephen Hemminger wrote:
> On Wed, 25 Apr 2018 15:57:57 -0700
> Siwei Liu <loseweigh@gmail.com> wrote:
>
> > >
> > > I think ideally the infrastructure should suppport flexible matching of
> > > NICs - netvsc is already reported to be moving to some kind of serial
> > > address.
> > >
> > As Stephen said, Hyper-V supports the serial UUID thing from day-one.
> > It's just the Linux netvsc guest driver itself does not leverage that
> > ID from the very beginging.
> >
> > Regards,
> > -Siwei
>
> I am working on that. The problem is that it requires some messy work
> to go from VF netdevice back to PCI device and from there to the PCI hyperv
> host infrastructure to find the serial number.
>
> I was hoping that the serial number would also match the concept of PCI Express
> device serial number. But that is a completely different ID :-(
> The PCI-E serial number is a hardware serial number more like MAC address.
> The Hyper-V serial number is more like PCI slot value.
Asuming you mean the Device Serial Number Capability,
I did consider this, and
we could use that, changing the UUID to one matching the
PV device, but I'm not sure no drivers will get confused
suddenly seeing the UUID of another company there.
If we are going the UUID route, a better idea might be to
specify the UUID of the PCI port into which the PT device is
being hotplugged. This is PCI-Express specific, but presumably
legacy PCI/PCI-X devices aren't common enough to bother about
this for now.
--
MST
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 net-next 4/4] netvsc: refactor notifier/event handling code to use the failover framework
2018-04-26 0:18 ` Stephen Hemminger
@ 2018-04-26 2:43 ` Michael S. Tsirkin
2018-04-26 2:43 ` [virtio-dev] " Michael S. Tsirkin
1 sibling, 0 replies; 114+ messages in thread
From: Michael S. Tsirkin @ 2018-04-26 2:43 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Alexander Duyck, virtio-dev, Jiri Pirko, Jakub Kicinski, Netdev,
virtualization, Siwei Liu, Sridhar Samudrala, David Miller
On Wed, Apr 25, 2018 at 05:18:31PM -0700, Stephen Hemminger wrote:
> On Wed, 25 Apr 2018 15:57:57 -0700
> Siwei Liu <loseweigh@gmail.com> wrote:
>
> > >
> > > I think ideally the infrastructure should suppport flexible matching of
> > > NICs - netvsc is already reported to be moving to some kind of serial
> > > address.
> > >
> > As Stephen said, Hyper-V supports the serial UUID thing from day-one.
> > It's just the Linux netvsc guest driver itself does not leverage that
> > ID from the very beginging.
> >
> > Regards,
> > -Siwei
>
> I am working on that. The problem is that it requires some messy work
> to go from VF netdevice back to PCI device and from there to the PCI hyperv
> host infrastructure to find the serial number.
>
> I was hoping that the serial number would also match the concept of PCI Express
> device serial number. But that is a completely different ID :-(
> The PCI-E serial number is a hardware serial number more like MAC address.
> The Hyper-V serial number is more like PCI slot value.
Asuming you mean the Device Serial Number Capability,
I did consider this, and
we could use that, changing the UUID to one matching the
PV device, but I'm not sure no drivers will get confused
suddenly seeing the UUID of another company there.
If we are going the UUID route, a better idea might be to
specify the UUID of the PCI port into which the PT device is
being hotplugged. This is PCI-Express specific, but presumably
legacy PCI/PCI-X devices aren't common enough to bother about
this for now.
--
MST
^ permalink raw reply [flat|nested] 114+ messages in thread
* [virtio-dev] Re: [PATCH v7 net-next 4/4] netvsc: refactor notifier/event handling code to use the failover framework
@ 2018-04-26 2:43 ` Michael S. Tsirkin
0 siblings, 0 replies; 114+ messages in thread
From: Michael S. Tsirkin @ 2018-04-26 2:43 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Siwei Liu, Jiri Pirko, Sridhar Samudrala, David Miller, Netdev,
virtualization, virtio-dev, Brandeburg, Jesse, Alexander Duyck,
Jakub Kicinski, Jason Wang
On Wed, Apr 25, 2018 at 05:18:31PM -0700, Stephen Hemminger wrote:
> On Wed, 25 Apr 2018 15:57:57 -0700
> Siwei Liu <loseweigh@gmail.com> wrote:
>
> > >
> > > I think ideally the infrastructure should suppport flexible matching of
> > > NICs - netvsc is already reported to be moving to some kind of serial
> > > address.
> > >
> > As Stephen said, Hyper-V supports the serial UUID thing from day-one.
> > It's just the Linux netvsc guest driver itself does not leverage that
> > ID from the very beginging.
> >
> > Regards,
> > -Siwei
>
> I am working on that. The problem is that it requires some messy work
> to go from VF netdevice back to PCI device and from there to the PCI hyperv
> host infrastructure to find the serial number.
>
> I was hoping that the serial number would also match the concept of PCI Express
> device serial number. But that is a completely different ID :-(
> The PCI-E serial number is a hardware serial number more like MAC address.
> The Hyper-V serial number is more like PCI slot value.
Asuming you mean the Device Serial Number Capability,
I did consider this, and
we could use that, changing the UUID to one matching the
PV device, but I'm not sure no drivers will get confused
suddenly seeing the UUID of another company there.
If we are going the UUID route, a better idea might be to
specify the UUID of the PCI port into which the PT device is
being hotplugged. This is PCI-Express specific, but presumably
legacy PCI/PCI-X devices aren't common enough to bother about
this for now.
--
MST
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 net-next 4/4] netvsc: refactor notifier/event handling code to use the failover framework
2018-04-26 2:28 ` [virtio-dev] " Michael S. Tsirkin
@ 2018-04-26 22:14 ` Siwei Liu
-1 siblings, 0 replies; 114+ messages in thread
From: Siwei Liu @ 2018-04-26 22:14 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Stephen Hemminger, Jiri Pirko, Sridhar Samudrala, David Miller,
Netdev, virtualization, virtio-dev, Brandeburg, Jesse,
Alexander Duyck, Jakub Kicinski, Jason Wang
On Wed, Apr 25, 2018 at 7:28 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
> On Wed, Apr 25, 2018 at 03:57:57PM -0700, Siwei Liu wrote:
>> On Wed, Apr 25, 2018 at 3:22 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
>> > On Wed, Apr 25, 2018 at 02:38:57PM -0700, Siwei Liu wrote:
>> >> On Mon, Apr 23, 2018 at 1:06 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
>> >> > On Mon, Apr 23, 2018 at 12:44:39PM -0700, Siwei Liu wrote:
>> >> >> On Mon, Apr 23, 2018 at 10:56 AM, Michael S. Tsirkin <mst@redhat.com> wrote:
>> >> >> > On Mon, Apr 23, 2018 at 10:44:40AM -0700, Stephen Hemminger wrote:
>> >> >> >> On Mon, 23 Apr 2018 20:24:56 +0300
>> >> >> >> "Michael S. Tsirkin" <mst@redhat.com> wrote:
>> >> >> >>
>> >> >> >> > On Mon, Apr 23, 2018 at 10:04:06AM -0700, Stephen Hemminger wrote:
>> >> >> >> > > > >
>> >> >> >> > > > >I will NAK patches to change to common code for netvsc especially the
>> >> >> >> > > > >three device model. MS worked hard with distro vendors to support transparent
>> >> >> >> > > > >mode, ans we really can't have a new model; or do backport.
>> >> >> >> > > > >
>> >> >> >> > > > >Plus, DPDK is now dependent on existing model.
>> >> >> >> > > >
>> >> >> >> > > > Sorry, but nobody here cares about dpdk or other similar oddities.
>> >> >> >> > >
>> >> >> >> > > The network device model is a userspace API, and DPDK is a userspace application.
>> >> >> >> >
>> >> >> >> > It is userspace but are you sure dpdk is actually poking at netdevs?
>> >> >> >> > AFAIK it's normally banging device registers directly.
>> >> >> >> >
>> >> >> >> > > You can't go breaking userspace even if you don't like the application.
>> >> >> >> >
>> >> >> >> > Could you please explain how is the proposed patchset breaking
>> >> >> >> > userspace? Ignoring DPDK for now, I don't think it changes the userspace
>> >> >> >> > API at all.
>> >> >> >> >
>> >> >> >>
>> >> >> >> The DPDK has a device driver vdev_netvsc which scans the Linux network devices
>> >> >> >> to look for Linux netvsc device and the paired VF device and setup the
>> >> >> >> DPDK environment. This setup creates a DPDK failsafe (bondingish) instance
>> >> >> >> and sets up TAP support over the Linux netvsc device as well as the Mellanox
>> >> >> >> VF device.
>> >> >> >>
>> >> >> >> So it depends on existing 2 device model. You can't go to a 3 device model
>> >> >> >> or start hiding devices from userspace.
>> >> >> >
>> >> >> > Okay so how does the existing patch break that? IIUC does not go to
>> >> >> > a 3 device model since netvsc calls failover_register directly.
>> >> >> >
>> >> >> >> Also, I am working on associating netvsc and VF device based on serial number
>> >> >> >> rather than MAC address. The serial number is how Windows works now, and it makes
>> >> >> >> sense for Linux and Windows to use the same mechanism if possible.
>> >> >> >
>> >> >> > Maybe we should support same for virtio ...
>> >> >> > Which serial do you mean? From vpd?
>> >> >> >
>> >> >> > I guess you will want to keep supporting MAC for old hypervisors?
>> >> >> >
>> >> >> > It all seems like a reasonable thing to support in the generic core.
>> >> >>
>> >> >> That's the reason why I chose explicit identifier rather than rely on
>> >> >> MAC address to bind/pair a device. MAC address can change. Even if it
>> >> >> can't, malicious guest user can fake MAC address to skip binding.
>> >> >>
>> >> >> -Siwei
>> >> >
>> >> > Address should be sampled at device creation to prevent this
>> >> > kind of hack. Not that it buys the malicious user much:
>> >> > if you can poke at MAC addresses you probably already can
>> >> > break networking.
>> >>
>> >> I don't understand why poking at MAC address may potentially break
>> >> networking.
>> >
>> > Set a MAC address to match another device on the same LAN,
>> > packets will stop reaching that MAC.
>>
>> What I meant was guest users may create a virtual link, say veth that
>> has exactly the same MAC address as that for the VF, which can easily
>> get around of the binding procedure.
>
> This patchset limits binding to PCI devices so it won't be affected
> by any hacks around virtual devices.
Wait, I vaguely recall you seemed to like to generalize this feature
to non-PCI device. But now you're saying it should stick to PCI. It's
not that I'm reluctant with sticking to PCI. The fact is that I don't
think we can go with implementation until the semantics of the
so-called _F_STANDBY feature can be clearly defined into the spec.
Previously the boundary of using MAC address as the identifier for
bonding was quite confusing to me. And now PCI adds to the matrix.
However it still does not gurantee uniqueness I think. It's almost
incorrect of choosing MAC address as the ID in the beginning since
that has the implication of breaking existing configs. I don't think
libvirt or QEMU today retricts the MAC address to be unique per VM
instance. Neither the virtio spec mentions that.
In addition, it's difficult to fake PCI device on Linux does not mean
the same applies to other OSes that is going to implement this VirtIO
feature. It's a fragile assumption IMHO.
>
>> There's no explicit flag to
>> identify a VF or pass-through device AFAIK. And sometimes this happens
>> maybe due to user misconfiguring the link. This process should be
>> hardened to avoid from any potential configuration errors.
>
> They are still PCI devices though.
>
>> >
>> >> Unlike VF, passthrough PCI endpoint device has its freedom
>> >> to change the MAC address. Even on a VF setup it's not neccessarily
>> >> always safe to assume the VF's MAC address cannot or shouldn't be
>> >> changed. That depends on the specific need whether the host admin
>> >> wants to restrict guest from changing the MAC address, although in
>> >> most cases it's true.
>> >>
>> >> I understand we can use the perm_addr to distinguish. But as said,
>> >> this will pose limitation of flexible configuration where one can
>> >> assign VFs with identical MAC address at all while each VF belongs to
>> >> different PF and/or different subnet for e.g. load balancing.
>> >> And
>> >> furthermore, the QEMU device model never uses MAC address to be
>> >> interpreted as an identifier, which requires to be unique per VM
>> >> instance. Why we're introducing this inconsistency?
>> >>
>> >> -Siwei
>> >
>> > Because it addresses most of the issues and is simple. That's already
>> > much better than what we have now which is nothing unless guest
>> > configures things manually.
>>
>> Did you see my QEMU patch for using BDF as the grouping identifier?
>
> Yes. And I don't think it can work because bus numbers are
> guest specified.
I know it's not ideal but perhaps its the best one can do in the KVM
world without adding complex config e.g. PCI bridge. Even if bus
number is guest specified, it's readily available in the guest and
recognizable by any OS, while on the QEMU configuration users specify
an id instead of the bus number. Unlike Hyper-V PCI bus, I don't think
there exists a para-virtual PCI bus in QEMU backend to expose VPD
capability to a passthrough device.
>
>> And there can be others like what you suggested, but the point is that
>> it's requried to support explicit grouping mechanism from day one,
>> before the backup property cast into stones.
>
> Let's start with addressing simple configs with just two NICs.
>
> Down the road I can see possible extensions that can work: for example,
> require that devices are on the same pci bridge. Or we could even make
> the virtio device actually include a pci bridge (as part of same
> or a child function), the PT would have to be
> behind it.
>
> As long as we are not breaking anything, adding more flags to fix
> non-working configurations is always fair game.
While it may work, the PCI bridge has NUMA and IOMMU implications that
would restrict the current flexibility to group devices. I'm not sure
if vIOMMU would have to be introduced inadvertently for
isolation/protection of devices under the PCI bridge which may cause
negative performance impact on the VF.
>
>> This is orthogonal to
>> device model being proposed, be it 1-netdev or not. Delaying it would
>> just mean support and compatibility burden, appearing more like a
>> design flaw rather than a feature to add later on.
>
> Well it's mostly myself who gets to support it, and I see the device
> model as much more fundamental as userspace will come to depend
> on it. So I'm not too worried, let's take this one step at a time.
>
>> >
>> > I think ideally the infrastructure should suppport flexible matching of
>> > NICs - netvsc is already reported to be moving to some kind of serial
>> > address.
>> >
>> As Stephen said, Hyper-V supports the serial UUID thing from day-one.
>> It's just the Linux netvsc guest driver itself does not leverage that
>> ID from the very beginging.
>>
>> Regards,
>> -Siwei
>
> We could add something like this, too. For example,
> we could add a virtual VPD capability with a UUID.
I'm not an expert on that and wonder how you could do this (add a
virtual VPD capability with a UUID to passthrough device) with
existing QEMU emulation model and native PCI bus.
>
> Do you know how exactly does hyperv pass the UUID for NICs?
Stephen might know it more and can correct me. But my personal
interpretation is that the SN is a host generated 32 bit sequence
number which is unique per VM instance and gets propogated to guest
via the para-virtual Hyper-V PCI bus.
Regards,
-Siwei
>
>> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >>
>> >> >> >
>> >> >> > --
>> >> >> > MST
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 net-next 4/4] netvsc: refactor notifier/event handling code to use the failover framework
2018-04-26 2:28 ` [virtio-dev] " Michael S. Tsirkin
(?)
(?)
@ 2018-04-26 22:14 ` Siwei Liu
-1 siblings, 0 replies; 114+ messages in thread
From: Siwei Liu @ 2018-04-26 22:14 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Alexander Duyck, virtio-dev, Jiri Pirko, Jakub Kicinski,
Sridhar Samudrala, virtualization, Netdev, David Miller
On Wed, Apr 25, 2018 at 7:28 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
> On Wed, Apr 25, 2018 at 03:57:57PM -0700, Siwei Liu wrote:
>> On Wed, Apr 25, 2018 at 3:22 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
>> > On Wed, Apr 25, 2018 at 02:38:57PM -0700, Siwei Liu wrote:
>> >> On Mon, Apr 23, 2018 at 1:06 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
>> >> > On Mon, Apr 23, 2018 at 12:44:39PM -0700, Siwei Liu wrote:
>> >> >> On Mon, Apr 23, 2018 at 10:56 AM, Michael S. Tsirkin <mst@redhat.com> wrote:
>> >> >> > On Mon, Apr 23, 2018 at 10:44:40AM -0700, Stephen Hemminger wrote:
>> >> >> >> On Mon, 23 Apr 2018 20:24:56 +0300
>> >> >> >> "Michael S. Tsirkin" <mst@redhat.com> wrote:
>> >> >> >>
>> >> >> >> > On Mon, Apr 23, 2018 at 10:04:06AM -0700, Stephen Hemminger wrote:
>> >> >> >> > > > >
>> >> >> >> > > > >I will NAK patches to change to common code for netvsc especially the
>> >> >> >> > > > >three device model. MS worked hard with distro vendors to support transparent
>> >> >> >> > > > >mode, ans we really can't have a new model; or do backport.
>> >> >> >> > > > >
>> >> >> >> > > > >Plus, DPDK is now dependent on existing model.
>> >> >> >> > > >
>> >> >> >> > > > Sorry, but nobody here cares about dpdk or other similar oddities.
>> >> >> >> > >
>> >> >> >> > > The network device model is a userspace API, and DPDK is a userspace application.
>> >> >> >> >
>> >> >> >> > It is userspace but are you sure dpdk is actually poking at netdevs?
>> >> >> >> > AFAIK it's normally banging device registers directly.
>> >> >> >> >
>> >> >> >> > > You can't go breaking userspace even if you don't like the application.
>> >> >> >> >
>> >> >> >> > Could you please explain how is the proposed patchset breaking
>> >> >> >> > userspace? Ignoring DPDK for now, I don't think it changes the userspace
>> >> >> >> > API at all.
>> >> >> >> >
>> >> >> >>
>> >> >> >> The DPDK has a device driver vdev_netvsc which scans the Linux network devices
>> >> >> >> to look for Linux netvsc device and the paired VF device and setup the
>> >> >> >> DPDK environment. This setup creates a DPDK failsafe (bondingish) instance
>> >> >> >> and sets up TAP support over the Linux netvsc device as well as the Mellanox
>> >> >> >> VF device.
>> >> >> >>
>> >> >> >> So it depends on existing 2 device model. You can't go to a 3 device model
>> >> >> >> or start hiding devices from userspace.
>> >> >> >
>> >> >> > Okay so how does the existing patch break that? IIUC does not go to
>> >> >> > a 3 device model since netvsc calls failover_register directly.
>> >> >> >
>> >> >> >> Also, I am working on associating netvsc and VF device based on serial number
>> >> >> >> rather than MAC address. The serial number is how Windows works now, and it makes
>> >> >> >> sense for Linux and Windows to use the same mechanism if possible.
>> >> >> >
>> >> >> > Maybe we should support same for virtio ...
>> >> >> > Which serial do you mean? From vpd?
>> >> >> >
>> >> >> > I guess you will want to keep supporting MAC for old hypervisors?
>> >> >> >
>> >> >> > It all seems like a reasonable thing to support in the generic core.
>> >> >>
>> >> >> That's the reason why I chose explicit identifier rather than rely on
>> >> >> MAC address to bind/pair a device. MAC address can change. Even if it
>> >> >> can't, malicious guest user can fake MAC address to skip binding.
>> >> >>
>> >> >> -Siwei
>> >> >
>> >> > Address should be sampled at device creation to prevent this
>> >> > kind of hack. Not that it buys the malicious user much:
>> >> > if you can poke at MAC addresses you probably already can
>> >> > break networking.
>> >>
>> >> I don't understand why poking at MAC address may potentially break
>> >> networking.
>> >
>> > Set a MAC address to match another device on the same LAN,
>> > packets will stop reaching that MAC.
>>
>> What I meant was guest users may create a virtual link, say veth that
>> has exactly the same MAC address as that for the VF, which can easily
>> get around of the binding procedure.
>
> This patchset limits binding to PCI devices so it won't be affected
> by any hacks around virtual devices.
Wait, I vaguely recall you seemed to like to generalize this feature
to non-PCI device. But now you're saying it should stick to PCI. It's
not that I'm reluctant with sticking to PCI. The fact is that I don't
think we can go with implementation until the semantics of the
so-called _F_STANDBY feature can be clearly defined into the spec.
Previously the boundary of using MAC address as the identifier for
bonding was quite confusing to me. And now PCI adds to the matrix.
However it still does not gurantee uniqueness I think. It's almost
incorrect of choosing MAC address as the ID in the beginning since
that has the implication of breaking existing configs. I don't think
libvirt or QEMU today retricts the MAC address to be unique per VM
instance. Neither the virtio spec mentions that.
In addition, it's difficult to fake PCI device on Linux does not mean
the same applies to other OSes that is going to implement this VirtIO
feature. It's a fragile assumption IMHO.
>
>> There's no explicit flag to
>> identify a VF or pass-through device AFAIK. And sometimes this happens
>> maybe due to user misconfiguring the link. This process should be
>> hardened to avoid from any potential configuration errors.
>
> They are still PCI devices though.
>
>> >
>> >> Unlike VF, passthrough PCI endpoint device has its freedom
>> >> to change the MAC address. Even on a VF setup it's not neccessarily
>> >> always safe to assume the VF's MAC address cannot or shouldn't be
>> >> changed. That depends on the specific need whether the host admin
>> >> wants to restrict guest from changing the MAC address, although in
>> >> most cases it's true.
>> >>
>> >> I understand we can use the perm_addr to distinguish. But as said,
>> >> this will pose limitation of flexible configuration where one can
>> >> assign VFs with identical MAC address at all while each VF belongs to
>> >> different PF and/or different subnet for e.g. load balancing.
>> >> And
>> >> furthermore, the QEMU device model never uses MAC address to be
>> >> interpreted as an identifier, which requires to be unique per VM
>> >> instance. Why we're introducing this inconsistency?
>> >>
>> >> -Siwei
>> >
>> > Because it addresses most of the issues and is simple. That's already
>> > much better than what we have now which is nothing unless guest
>> > configures things manually.
>>
>> Did you see my QEMU patch for using BDF as the grouping identifier?
>
> Yes. And I don't think it can work because bus numbers are
> guest specified.
I know it's not ideal but perhaps its the best one can do in the KVM
world without adding complex config e.g. PCI bridge. Even if bus
number is guest specified, it's readily available in the guest and
recognizable by any OS, while on the QEMU configuration users specify
an id instead of the bus number. Unlike Hyper-V PCI bus, I don't think
there exists a para-virtual PCI bus in QEMU backend to expose VPD
capability to a passthrough device.
>
>> And there can be others like what you suggested, but the point is that
>> it's requried to support explicit grouping mechanism from day one,
>> before the backup property cast into stones.
>
> Let's start with addressing simple configs with just two NICs.
>
> Down the road I can see possible extensions that can work: for example,
> require that devices are on the same pci bridge. Or we could even make
> the virtio device actually include a pci bridge (as part of same
> or a child function), the PT would have to be
> behind it.
>
> As long as we are not breaking anything, adding more flags to fix
> non-working configurations is always fair game.
While it may work, the PCI bridge has NUMA and IOMMU implications that
would restrict the current flexibility to group devices. I'm not sure
if vIOMMU would have to be introduced inadvertently for
isolation/protection of devices under the PCI bridge which may cause
negative performance impact on the VF.
>
>> This is orthogonal to
>> device model being proposed, be it 1-netdev or not. Delaying it would
>> just mean support and compatibility burden, appearing more like a
>> design flaw rather than a feature to add later on.
>
> Well it's mostly myself who gets to support it, and I see the device
> model as much more fundamental as userspace will come to depend
> on it. So I'm not too worried, let's take this one step at a time.
>
>> >
>> > I think ideally the infrastructure should suppport flexible matching of
>> > NICs - netvsc is already reported to be moving to some kind of serial
>> > address.
>> >
>> As Stephen said, Hyper-V supports the serial UUID thing from day-one.
>> It's just the Linux netvsc guest driver itself does not leverage that
>> ID from the very beginging.
>>
>> Regards,
>> -Siwei
>
> We could add something like this, too. For example,
> we could add a virtual VPD capability with a UUID.
I'm not an expert on that and wonder how you could do this (add a
virtual VPD capability with a UUID to passthrough device) with
existing QEMU emulation model and native PCI bus.
>
> Do you know how exactly does hyperv pass the UUID for NICs?
Stephen might know it more and can correct me. But my personal
interpretation is that the SN is a host generated 32 bit sequence
number which is unique per VM instance and gets propogated to guest
via the para-virtual Hyper-V PCI bus.
Regards,
-Siwei
>
>> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >>
>> >> >> >
>> >> >> > --
>> >> >> > MST
^ permalink raw reply [flat|nested] 114+ messages in thread
* [virtio-dev] Re: [PATCH v7 net-next 4/4] netvsc: refactor notifier/event handling code to use the failover framework
@ 2018-04-26 22:14 ` Siwei Liu
0 siblings, 0 replies; 114+ messages in thread
From: Siwei Liu @ 2018-04-26 22:14 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Stephen Hemminger, Jiri Pirko, Sridhar Samudrala, David Miller,
Netdev, virtualization, virtio-dev, Brandeburg, Jesse,
Alexander Duyck, Jakub Kicinski, Jason Wang
On Wed, Apr 25, 2018 at 7:28 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
> On Wed, Apr 25, 2018 at 03:57:57PM -0700, Siwei Liu wrote:
>> On Wed, Apr 25, 2018 at 3:22 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
>> > On Wed, Apr 25, 2018 at 02:38:57PM -0700, Siwei Liu wrote:
>> >> On Mon, Apr 23, 2018 at 1:06 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
>> >> > On Mon, Apr 23, 2018 at 12:44:39PM -0700, Siwei Liu wrote:
>> >> >> On Mon, Apr 23, 2018 at 10:56 AM, Michael S. Tsirkin <mst@redhat.com> wrote:
>> >> >> > On Mon, Apr 23, 2018 at 10:44:40AM -0700, Stephen Hemminger wrote:
>> >> >> >> On Mon, 23 Apr 2018 20:24:56 +0300
>> >> >> >> "Michael S. Tsirkin" <mst@redhat.com> wrote:
>> >> >> >>
>> >> >> >> > On Mon, Apr 23, 2018 at 10:04:06AM -0700, Stephen Hemminger wrote:
>> >> >> >> > > > >
>> >> >> >> > > > >I will NAK patches to change to common code for netvsc especially the
>> >> >> >> > > > >three device model. MS worked hard with distro vendors to support transparent
>> >> >> >> > > > >mode, ans we really can't have a new model; or do backport.
>> >> >> >> > > > >
>> >> >> >> > > > >Plus, DPDK is now dependent on existing model.
>> >> >> >> > > >
>> >> >> >> > > > Sorry, but nobody here cares about dpdk or other similar oddities.
>> >> >> >> > >
>> >> >> >> > > The network device model is a userspace API, and DPDK is a userspace application.
>> >> >> >> >
>> >> >> >> > It is userspace but are you sure dpdk is actually poking at netdevs?
>> >> >> >> > AFAIK it's normally banging device registers directly.
>> >> >> >> >
>> >> >> >> > > You can't go breaking userspace even if you don't like the application.
>> >> >> >> >
>> >> >> >> > Could you please explain how is the proposed patchset breaking
>> >> >> >> > userspace? Ignoring DPDK for now, I don't think it changes the userspace
>> >> >> >> > API at all.
>> >> >> >> >
>> >> >> >>
>> >> >> >> The DPDK has a device driver vdev_netvsc which scans the Linux network devices
>> >> >> >> to look for Linux netvsc device and the paired VF device and setup the
>> >> >> >> DPDK environment. This setup creates a DPDK failsafe (bondingish) instance
>> >> >> >> and sets up TAP support over the Linux netvsc device as well as the Mellanox
>> >> >> >> VF device.
>> >> >> >>
>> >> >> >> So it depends on existing 2 device model. You can't go to a 3 device model
>> >> >> >> or start hiding devices from userspace.
>> >> >> >
>> >> >> > Okay so how does the existing patch break that? IIUC does not go to
>> >> >> > a 3 device model since netvsc calls failover_register directly.
>> >> >> >
>> >> >> >> Also, I am working on associating netvsc and VF device based on serial number
>> >> >> >> rather than MAC address. The serial number is how Windows works now, and it makes
>> >> >> >> sense for Linux and Windows to use the same mechanism if possible.
>> >> >> >
>> >> >> > Maybe we should support same for virtio ...
>> >> >> > Which serial do you mean? From vpd?
>> >> >> >
>> >> >> > I guess you will want to keep supporting MAC for old hypervisors?
>> >> >> >
>> >> >> > It all seems like a reasonable thing to support in the generic core.
>> >> >>
>> >> >> That's the reason why I chose explicit identifier rather than rely on
>> >> >> MAC address to bind/pair a device. MAC address can change. Even if it
>> >> >> can't, malicious guest user can fake MAC address to skip binding.
>> >> >>
>> >> >> -Siwei
>> >> >
>> >> > Address should be sampled at device creation to prevent this
>> >> > kind of hack. Not that it buys the malicious user much:
>> >> > if you can poke at MAC addresses you probably already can
>> >> > break networking.
>> >>
>> >> I don't understand why poking at MAC address may potentially break
>> >> networking.
>> >
>> > Set a MAC address to match another device on the same LAN,
>> > packets will stop reaching that MAC.
>>
>> What I meant was guest users may create a virtual link, say veth that
>> has exactly the same MAC address as that for the VF, which can easily
>> get around of the binding procedure.
>
> This patchset limits binding to PCI devices so it won't be affected
> by any hacks around virtual devices.
Wait, I vaguely recall you seemed to like to generalize this feature
to non-PCI device. But now you're saying it should stick to PCI. It's
not that I'm reluctant with sticking to PCI. The fact is that I don't
think we can go with implementation until the semantics of the
so-called _F_STANDBY feature can be clearly defined into the spec.
Previously the boundary of using MAC address as the identifier for
bonding was quite confusing to me. And now PCI adds to the matrix.
However it still does not gurantee uniqueness I think. It's almost
incorrect of choosing MAC address as the ID in the beginning since
that has the implication of breaking existing configs. I don't think
libvirt or QEMU today retricts the MAC address to be unique per VM
instance. Neither the virtio spec mentions that.
In addition, it's difficult to fake PCI device on Linux does not mean
the same applies to other OSes that is going to implement this VirtIO
feature. It's a fragile assumption IMHO.
>
>> There's no explicit flag to
>> identify a VF or pass-through device AFAIK. And sometimes this happens
>> maybe due to user misconfiguring the link. This process should be
>> hardened to avoid from any potential configuration errors.
>
> They are still PCI devices though.
>
>> >
>> >> Unlike VF, passthrough PCI endpoint device has its freedom
>> >> to change the MAC address. Even on a VF setup it's not neccessarily
>> >> always safe to assume the VF's MAC address cannot or shouldn't be
>> >> changed. That depends on the specific need whether the host admin
>> >> wants to restrict guest from changing the MAC address, although in
>> >> most cases it's true.
>> >>
>> >> I understand we can use the perm_addr to distinguish. But as said,
>> >> this will pose limitation of flexible configuration where one can
>> >> assign VFs with identical MAC address at all while each VF belongs to
>> >> different PF and/or different subnet for e.g. load balancing.
>> >> And
>> >> furthermore, the QEMU device model never uses MAC address to be
>> >> interpreted as an identifier, which requires to be unique per VM
>> >> instance. Why we're introducing this inconsistency?
>> >>
>> >> -Siwei
>> >
>> > Because it addresses most of the issues and is simple. That's already
>> > much better than what we have now which is nothing unless guest
>> > configures things manually.
>>
>> Did you see my QEMU patch for using BDF as the grouping identifier?
>
> Yes. And I don't think it can work because bus numbers are
> guest specified.
I know it's not ideal but perhaps its the best one can do in the KVM
world without adding complex config e.g. PCI bridge. Even if bus
number is guest specified, it's readily available in the guest and
recognizable by any OS, while on the QEMU configuration users specify
an id instead of the bus number. Unlike Hyper-V PCI bus, I don't think
there exists a para-virtual PCI bus in QEMU backend to expose VPD
capability to a passthrough device.
>
>> And there can be others like what you suggested, but the point is that
>> it's requried to support explicit grouping mechanism from day one,
>> before the backup property cast into stones.
>
> Let's start with addressing simple configs with just two NICs.
>
> Down the road I can see possible extensions that can work: for example,
> require that devices are on the same pci bridge. Or we could even make
> the virtio device actually include a pci bridge (as part of same
> or a child function), the PT would have to be
> behind it.
>
> As long as we are not breaking anything, adding more flags to fix
> non-working configurations is always fair game.
While it may work, the PCI bridge has NUMA and IOMMU implications that
would restrict the current flexibility to group devices. I'm not sure
if vIOMMU would have to be introduced inadvertently for
isolation/protection of devices under the PCI bridge which may cause
negative performance impact on the VF.
>
>> This is orthogonal to
>> device model being proposed, be it 1-netdev or not. Delaying it would
>> just mean support and compatibility burden, appearing more like a
>> design flaw rather than a feature to add later on.
>
> Well it's mostly myself who gets to support it, and I see the device
> model as much more fundamental as userspace will come to depend
> on it. So I'm not too worried, let's take this one step at a time.
>
>> >
>> > I think ideally the infrastructure should suppport flexible matching of
>> > NICs - netvsc is already reported to be moving to some kind of serial
>> > address.
>> >
>> As Stephen said, Hyper-V supports the serial UUID thing from day-one.
>> It's just the Linux netvsc guest driver itself does not leverage that
>> ID from the very beginging.
>>
>> Regards,
>> -Siwei
>
> We could add something like this, too. For example,
> we could add a virtual VPD capability with a UUID.
I'm not an expert on that and wonder how you could do this (add a
virtual VPD capability with a UUID to passthrough device) with
existing QEMU emulation model and native PCI bus.
>
> Do you know how exactly does hyperv pass the UUID for NICs?
Stephen might know it more and can correct me. But my personal
interpretation is that the SN is a host generated 32 bit sequence
number which is unique per VM instance and gets propogated to guest
via the para-virtual Hyper-V PCI bus.
Regards,
-Siwei
>
>> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >>
>> >> >> >
>> >> >> > --
>> >> >> > MST
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 net-next 4/4] netvsc: refactor notifier/event handling code to use the failover framework
2018-04-26 22:14 ` [virtio-dev] " Siwei Liu
@ 2018-04-26 23:42 ` Michael S. Tsirkin
-1 siblings, 0 replies; 114+ messages in thread
From: Michael S. Tsirkin @ 2018-04-26 23:42 UTC (permalink / raw)
To: Siwei Liu
Cc: Stephen Hemminger, Jiri Pirko, Sridhar Samudrala, David Miller,
Netdev, virtualization, virtio-dev, Brandeburg, Jesse,
Alexander Duyck, Jakub Kicinski, Jason Wang
On Thu, Apr 26, 2018 at 03:14:46PM -0700, Siwei Liu wrote:
> On Wed, Apr 25, 2018 at 7:28 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
> > On Wed, Apr 25, 2018 at 03:57:57PM -0700, Siwei Liu wrote:
> >> On Wed, Apr 25, 2018 at 3:22 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
> >> > On Wed, Apr 25, 2018 at 02:38:57PM -0700, Siwei Liu wrote:
> >> >> On Mon, Apr 23, 2018 at 1:06 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
> >> >> > On Mon, Apr 23, 2018 at 12:44:39PM -0700, Siwei Liu wrote:
> >> >> >> On Mon, Apr 23, 2018 at 10:56 AM, Michael S. Tsirkin <mst@redhat.com> wrote:
> >> >> >> > On Mon, Apr 23, 2018 at 10:44:40AM -0700, Stephen Hemminger wrote:
> >> >> >> >> On Mon, 23 Apr 2018 20:24:56 +0300
> >> >> >> >> "Michael S. Tsirkin" <mst@redhat.com> wrote:
> >> >> >> >>
> >> >> >> >> > On Mon, Apr 23, 2018 at 10:04:06AM -0700, Stephen Hemminger wrote:
> >> >> >> >> > > > >
> >> >> >> >> > > > >I will NAK patches to change to common code for netvsc especially the
> >> >> >> >> > > > >three device model. MS worked hard with distro vendors to support transparent
> >> >> >> >> > > > >mode, ans we really can't have a new model; or do backport.
> >> >> >> >> > > > >
> >> >> >> >> > > > >Plus, DPDK is now dependent on existing model.
> >> >> >> >> > > >
> >> >> >> >> > > > Sorry, but nobody here cares about dpdk or other similar oddities.
> >> >> >> >> > >
> >> >> >> >> > > The network device model is a userspace API, and DPDK is a userspace application.
> >> >> >> >> >
> >> >> >> >> > It is userspace but are you sure dpdk is actually poking at netdevs?
> >> >> >> >> > AFAIK it's normally banging device registers directly.
> >> >> >> >> >
> >> >> >> >> > > You can't go breaking userspace even if you don't like the application.
> >> >> >> >> >
> >> >> >> >> > Could you please explain how is the proposed patchset breaking
> >> >> >> >> > userspace? Ignoring DPDK for now, I don't think it changes the userspace
> >> >> >> >> > API at all.
> >> >> >> >> >
> >> >> >> >>
> >> >> >> >> The DPDK has a device driver vdev_netvsc which scans the Linux network devices
> >> >> >> >> to look for Linux netvsc device and the paired VF device and setup the
> >> >> >> >> DPDK environment. This setup creates a DPDK failsafe (bondingish) instance
> >> >> >> >> and sets up TAP support over the Linux netvsc device as well as the Mellanox
> >> >> >> >> VF device.
> >> >> >> >>
> >> >> >> >> So it depends on existing 2 device model. You can't go to a 3 device model
> >> >> >> >> or start hiding devices from userspace.
> >> >> >> >
> >> >> >> > Okay so how does the existing patch break that? IIUC does not go to
> >> >> >> > a 3 device model since netvsc calls failover_register directly.
> >> >> >> >
> >> >> >> >> Also, I am working on associating netvsc and VF device based on serial number
> >> >> >> >> rather than MAC address. The serial number is how Windows works now, and it makes
> >> >> >> >> sense for Linux and Windows to use the same mechanism if possible.
> >> >> >> >
> >> >> >> > Maybe we should support same for virtio ...
> >> >> >> > Which serial do you mean? From vpd?
> >> >> >> >
> >> >> >> > I guess you will want to keep supporting MAC for old hypervisors?
> >> >> >> >
> >> >> >> > It all seems like a reasonable thing to support in the generic core.
> >> >> >>
> >> >> >> That's the reason why I chose explicit identifier rather than rely on
> >> >> >> MAC address to bind/pair a device. MAC address can change. Even if it
> >> >> >> can't, malicious guest user can fake MAC address to skip binding.
> >> >> >>
> >> >> >> -Siwei
> >> >> >
> >> >> > Address should be sampled at device creation to prevent this
> >> >> > kind of hack. Not that it buys the malicious user much:
> >> >> > if you can poke at MAC addresses you probably already can
> >> >> > break networking.
> >> >>
> >> >> I don't understand why poking at MAC address may potentially break
> >> >> networking.
> >> >
> >> > Set a MAC address to match another device on the same LAN,
> >> > packets will stop reaching that MAC.
> >>
> >> What I meant was guest users may create a virtual link, say veth that
> >> has exactly the same MAC address as that for the VF, which can easily
> >> get around of the binding procedure.
> >
> > This patchset limits binding to PCI devices so it won't be affected
> > by any hacks around virtual devices.
>
> Wait, I vaguely recall you seemed to like to generalize this feature
> to non-PCI device.
It's purely a layering thing. It is cleaner not to have PCI specific
data in the device-specific transport-independent section of the virtio
spec.
> But now you're saying it should stick to PCI. It's
> not that I'm reluctant with sticking to PCI. The fact is that I don't
> think we can go with implementation until the semantics of the
> so-called _F_STANDBY feature can be clearly defined into the spec.
> Previously the boundary of using MAC address as the identifier for
> bonding was quite confusing to me. And now PCI adds to the matrix.
PCI is simply one way to exclude software NICs. It's not the most
elegant one, but it will cover many setups. We can add more types, but
we do want to exclude software devices since these have
not been supplied by the hypervisor.
> However it still does not gurantee uniqueness I think. It's almost
> incorrect of choosing MAC address as the ID in the beginning since
> that has the implication of breaking existing configs.
IMO there's no chance it will break any existing config since
no existing config sets _F_STANDBY.
> I don't think
> libvirt or QEMU today retricts the MAC address to be unique per VM
> instance. Neither the virtio spec mentions that.
You really don't have to.
> In addition, it's difficult to fake PCI device on Linux does not mean
> the same applies to other OSes that is going to implement this VirtIO
> feature. It's a fragile assumption IMHO.
What an OS does internally is its own business.
What we are telling the guest here is simply that the virtio NIC is
actually the same device as some other NIC. At this point we do not
specify this other NIC in any way. So how do you find it? Well it has
to have the same MAC clearly.
You point out that there could be multiple NICs with the same
MAC in theory. It's a broken config generally but since it
kind of works in some setups maybe it's worth supporting.
If so we can look for ways to make the matching more specific by e.g.
adding more flags but I see that as a separate issue,
and pretty narrow in scope.
> >
> >> There's no explicit flag to
> >> identify a VF or pass-through device AFAIK. And sometimes this happens
> >> maybe due to user misconfiguring the link. This process should be
> >> hardened to avoid from any potential configuration errors.
> >
> > They are still PCI devices though.
> >
> >> >
> >> >> Unlike VF, passthrough PCI endpoint device has its freedom
> >> >> to change the MAC address. Even on a VF setup it's not neccessarily
> >> >> always safe to assume the VF's MAC address cannot or shouldn't be
> >> >> changed. That depends on the specific need whether the host admin
> >> >> wants to restrict guest from changing the MAC address, although in
> >> >> most cases it's true.
> >> >>
> >> >> I understand we can use the perm_addr to distinguish. But as said,
> >> >> this will pose limitation of flexible configuration where one can
> >> >> assign VFs with identical MAC address at all while each VF belongs to
> >> >> different PF and/or different subnet for e.g. load balancing.
> >> >> And
> >> >> furthermore, the QEMU device model never uses MAC address to be
> >> >> interpreted as an identifier, which requires to be unique per VM
> >> >> instance. Why we're introducing this inconsistency?
> >> >>
> >> >> -Siwei
> >> >
> >> > Because it addresses most of the issues and is simple. That's already
> >> > much better than what we have now which is nothing unless guest
> >> > configures things manually.
> >>
> >> Did you see my QEMU patch for using BDF as the grouping identifier?
> >
> > Yes. And I don't think it can work because bus numbers are
> > guest specified.
>
> I know it's not ideal but perhaps its the best one can do in the KVM
> world without adding complex config e.g. PCI bridge.
KVM is just a VMX/SVM driver. I think you mean QEMU. And well -
"best one can do" is a high bar to clear.
> Even if bus
> number is guest specified, it's readily available in the guest and
> recognizable by any OS, while on the QEMU configuration users specify
> an id instead of the bus number. Unlike Hyper-V PCI bus, I don't think
> there exists a para-virtual PCI bus in QEMU backend to expose VPD
> capability to a passthrough device.
We can always add more interfaces if we need them. But let's be clear
that we are adding an interface and what are we trying to fix by doing
it. Let's not mix it as part of the failover discussion.
> >
> >> And there can be others like what you suggested, but the point is that
> >> it's requried to support explicit grouping mechanism from day one,
> >> before the backup property cast into stones.
> >
> > Let's start with addressing simple configs with just two NICs.
> >
> > Down the road I can see possible extensions that can work: for example,
> > require that devices are on the same pci bridge. Or we could even make
> > the virtio device actually include a pci bridge (as part of same
> > or a child function), the PT would have to be
> > behind it.
> >
> > As long as we are not breaking anything, adding more flags to fix
> > non-working configurations is always fair game.
>
> While it may work, the PCI bridge has NUMA and IOMMU implications that
> would restrict the current flexibility to group devices.
It's interesting you should mention that.
If you want to be flexible in placing the primary device WRT NUMA and
IOMMU, and given that both IOMMU and NUMA are keyed by the bus address,
then doesn't this completely break the idea of passing
the bus address to the guest?
> I'm not sure
> if vIOMMU would have to be introduced inadvertently for
> isolation/protection of devices under the PCI bridge which may cause
> negative performance impact on the VF.
No idea how do you introduce an IOMMU inadvertently.
> >
> >> This is orthogonal to
> >> device model being proposed, be it 1-netdev or not. Delaying it would
> >> just mean support and compatibility burden, appearing more like a
> >> design flaw rather than a feature to add later on.
> >
> > Well it's mostly myself who gets to support it, and I see the device
> > model as much more fundamental as userspace will come to depend
> > on it. So I'm not too worried, let's take this one step at a time.
> >
> >> >
> >> > I think ideally the infrastructure should suppport flexible matching of
> >> > NICs - netvsc is already reported to be moving to some kind of serial
> >> > address.
> >> >
> >> As Stephen said, Hyper-V supports the serial UUID thing from day-one.
> >> It's just the Linux netvsc guest driver itself does not leverage that
> >> ID from the very beginging.
> >>
> >> Regards,
> >> -Siwei
> >
> > We could add something like this, too. For example,
> > we could add a virtual VPD capability with a UUID.
>
> I'm not an expert on that and wonder how you could do this (add a
> virtual VPD capability with a UUID to passthrough device) with
> existing QEMU emulation model and native PCI bus.
I think I see an elegant way to do that.
You could put it in the port where you want to stick you PT device.
Here's how it could work then:
- standby virtio device is tied to a pci bridge.
Tied how? Well it could be
- behind this bridge
- include a bridge internally
- have the bridge as a PCI function
- include a bridge and the bridge as a PCI function
- have a VPD or serial capability with same UUID as the bridge
- primary passthrough device is placed behind a bridge
*with the same ID*
- either simply behind the same bridge
- or behind another bridge with the same UUID.
The treatment could also be limited just to bridges which have a
specific vendor/device id (maybe a good idea), or in any other arbitrary
way.
> >
> > Do you know how exactly does hyperv pass the UUID for NICs?
>
> Stephen might know it more and can correct me. But my personal
> interpretation is that the SN is a host generated 32 bit sequence
> number which is unique per VM instance and gets propogated to guest
> via the para-virtual Hyper-V PCI bus.
>
> Regards,
> -Siwei
Ah, so it's a Hyper-V thing.
> >
> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> >>
> >> >> >> >
> >> >> >> > --
> >> >> >> > MST
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 net-next 4/4] netvsc: refactor notifier/event handling code to use the failover framework
2018-04-26 22:14 ` [virtio-dev] " Siwei Liu
(?)
(?)
@ 2018-04-26 23:42 ` Michael S. Tsirkin
-1 siblings, 0 replies; 114+ messages in thread
From: Michael S. Tsirkin @ 2018-04-26 23:42 UTC (permalink / raw)
To: Siwei Liu
Cc: Alexander Duyck, virtio-dev, Jiri Pirko, Jakub Kicinski,
Sridhar Samudrala, virtualization, Netdev, David Miller
On Thu, Apr 26, 2018 at 03:14:46PM -0700, Siwei Liu wrote:
> On Wed, Apr 25, 2018 at 7:28 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
> > On Wed, Apr 25, 2018 at 03:57:57PM -0700, Siwei Liu wrote:
> >> On Wed, Apr 25, 2018 at 3:22 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
> >> > On Wed, Apr 25, 2018 at 02:38:57PM -0700, Siwei Liu wrote:
> >> >> On Mon, Apr 23, 2018 at 1:06 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
> >> >> > On Mon, Apr 23, 2018 at 12:44:39PM -0700, Siwei Liu wrote:
> >> >> >> On Mon, Apr 23, 2018 at 10:56 AM, Michael S. Tsirkin <mst@redhat.com> wrote:
> >> >> >> > On Mon, Apr 23, 2018 at 10:44:40AM -0700, Stephen Hemminger wrote:
> >> >> >> >> On Mon, 23 Apr 2018 20:24:56 +0300
> >> >> >> >> "Michael S. Tsirkin" <mst@redhat.com> wrote:
> >> >> >> >>
> >> >> >> >> > On Mon, Apr 23, 2018 at 10:04:06AM -0700, Stephen Hemminger wrote:
> >> >> >> >> > > > >
> >> >> >> >> > > > >I will NAK patches to change to common code for netvsc especially the
> >> >> >> >> > > > >three device model. MS worked hard with distro vendors to support transparent
> >> >> >> >> > > > >mode, ans we really can't have a new model; or do backport.
> >> >> >> >> > > > >
> >> >> >> >> > > > >Plus, DPDK is now dependent on existing model.
> >> >> >> >> > > >
> >> >> >> >> > > > Sorry, but nobody here cares about dpdk or other similar oddities.
> >> >> >> >> > >
> >> >> >> >> > > The network device model is a userspace API, and DPDK is a userspace application.
> >> >> >> >> >
> >> >> >> >> > It is userspace but are you sure dpdk is actually poking at netdevs?
> >> >> >> >> > AFAIK it's normally banging device registers directly.
> >> >> >> >> >
> >> >> >> >> > > You can't go breaking userspace even if you don't like the application.
> >> >> >> >> >
> >> >> >> >> > Could you please explain how is the proposed patchset breaking
> >> >> >> >> > userspace? Ignoring DPDK for now, I don't think it changes the userspace
> >> >> >> >> > API at all.
> >> >> >> >> >
> >> >> >> >>
> >> >> >> >> The DPDK has a device driver vdev_netvsc which scans the Linux network devices
> >> >> >> >> to look for Linux netvsc device and the paired VF device and setup the
> >> >> >> >> DPDK environment. This setup creates a DPDK failsafe (bondingish) instance
> >> >> >> >> and sets up TAP support over the Linux netvsc device as well as the Mellanox
> >> >> >> >> VF device.
> >> >> >> >>
> >> >> >> >> So it depends on existing 2 device model. You can't go to a 3 device model
> >> >> >> >> or start hiding devices from userspace.
> >> >> >> >
> >> >> >> > Okay so how does the existing patch break that? IIUC does not go to
> >> >> >> > a 3 device model since netvsc calls failover_register directly.
> >> >> >> >
> >> >> >> >> Also, I am working on associating netvsc and VF device based on serial number
> >> >> >> >> rather than MAC address. The serial number is how Windows works now, and it makes
> >> >> >> >> sense for Linux and Windows to use the same mechanism if possible.
> >> >> >> >
> >> >> >> > Maybe we should support same for virtio ...
> >> >> >> > Which serial do you mean? From vpd?
> >> >> >> >
> >> >> >> > I guess you will want to keep supporting MAC for old hypervisors?
> >> >> >> >
> >> >> >> > It all seems like a reasonable thing to support in the generic core.
> >> >> >>
> >> >> >> That's the reason why I chose explicit identifier rather than rely on
> >> >> >> MAC address to bind/pair a device. MAC address can change. Even if it
> >> >> >> can't, malicious guest user can fake MAC address to skip binding.
> >> >> >>
> >> >> >> -Siwei
> >> >> >
> >> >> > Address should be sampled at device creation to prevent this
> >> >> > kind of hack. Not that it buys the malicious user much:
> >> >> > if you can poke at MAC addresses you probably already can
> >> >> > break networking.
> >> >>
> >> >> I don't understand why poking at MAC address may potentially break
> >> >> networking.
> >> >
> >> > Set a MAC address to match another device on the same LAN,
> >> > packets will stop reaching that MAC.
> >>
> >> What I meant was guest users may create a virtual link, say veth that
> >> has exactly the same MAC address as that for the VF, which can easily
> >> get around of the binding procedure.
> >
> > This patchset limits binding to PCI devices so it won't be affected
> > by any hacks around virtual devices.
>
> Wait, I vaguely recall you seemed to like to generalize this feature
> to non-PCI device.
It's purely a layering thing. It is cleaner not to have PCI specific
data in the device-specific transport-independent section of the virtio
spec.
> But now you're saying it should stick to PCI. It's
> not that I'm reluctant with sticking to PCI. The fact is that I don't
> think we can go with implementation until the semantics of the
> so-called _F_STANDBY feature can be clearly defined into the spec.
> Previously the boundary of using MAC address as the identifier for
> bonding was quite confusing to me. And now PCI adds to the matrix.
PCI is simply one way to exclude software NICs. It's not the most
elegant one, but it will cover many setups. We can add more types, but
we do want to exclude software devices since these have
not been supplied by the hypervisor.
> However it still does not gurantee uniqueness I think. It's almost
> incorrect of choosing MAC address as the ID in the beginning since
> that has the implication of breaking existing configs.
IMO there's no chance it will break any existing config since
no existing config sets _F_STANDBY.
> I don't think
> libvirt or QEMU today retricts the MAC address to be unique per VM
> instance. Neither the virtio spec mentions that.
You really don't have to.
> In addition, it's difficult to fake PCI device on Linux does not mean
> the same applies to other OSes that is going to implement this VirtIO
> feature. It's a fragile assumption IMHO.
What an OS does internally is its own business.
What we are telling the guest here is simply that the virtio NIC is
actually the same device as some other NIC. At this point we do not
specify this other NIC in any way. So how do you find it? Well it has
to have the same MAC clearly.
You point out that there could be multiple NICs with the same
MAC in theory. It's a broken config generally but since it
kind of works in some setups maybe it's worth supporting.
If so we can look for ways to make the matching more specific by e.g.
adding more flags but I see that as a separate issue,
and pretty narrow in scope.
> >
> >> There's no explicit flag to
> >> identify a VF or pass-through device AFAIK. And sometimes this happens
> >> maybe due to user misconfiguring the link. This process should be
> >> hardened to avoid from any potential configuration errors.
> >
> > They are still PCI devices though.
> >
> >> >
> >> >> Unlike VF, passthrough PCI endpoint device has its freedom
> >> >> to change the MAC address. Even on a VF setup it's not neccessarily
> >> >> always safe to assume the VF's MAC address cannot or shouldn't be
> >> >> changed. That depends on the specific need whether the host admin
> >> >> wants to restrict guest from changing the MAC address, although in
> >> >> most cases it's true.
> >> >>
> >> >> I understand we can use the perm_addr to distinguish. But as said,
> >> >> this will pose limitation of flexible configuration where one can
> >> >> assign VFs with identical MAC address at all while each VF belongs to
> >> >> different PF and/or different subnet for e.g. load balancing.
> >> >> And
> >> >> furthermore, the QEMU device model never uses MAC address to be
> >> >> interpreted as an identifier, which requires to be unique per VM
> >> >> instance. Why we're introducing this inconsistency?
> >> >>
> >> >> -Siwei
> >> >
> >> > Because it addresses most of the issues and is simple. That's already
> >> > much better than what we have now which is nothing unless guest
> >> > configures things manually.
> >>
> >> Did you see my QEMU patch for using BDF as the grouping identifier?
> >
> > Yes. And I don't think it can work because bus numbers are
> > guest specified.
>
> I know it's not ideal but perhaps its the best one can do in the KVM
> world without adding complex config e.g. PCI bridge.
KVM is just a VMX/SVM driver. I think you mean QEMU. And well -
"best one can do" is a high bar to clear.
> Even if bus
> number is guest specified, it's readily available in the guest and
> recognizable by any OS, while on the QEMU configuration users specify
> an id instead of the bus number. Unlike Hyper-V PCI bus, I don't think
> there exists a para-virtual PCI bus in QEMU backend to expose VPD
> capability to a passthrough device.
We can always add more interfaces if we need them. But let's be clear
that we are adding an interface and what are we trying to fix by doing
it. Let's not mix it as part of the failover discussion.
> >
> >> And there can be others like what you suggested, but the point is that
> >> it's requried to support explicit grouping mechanism from day one,
> >> before the backup property cast into stones.
> >
> > Let's start with addressing simple configs with just two NICs.
> >
> > Down the road I can see possible extensions that can work: for example,
> > require that devices are on the same pci bridge. Or we could even make
> > the virtio device actually include a pci bridge (as part of same
> > or a child function), the PT would have to be
> > behind it.
> >
> > As long as we are not breaking anything, adding more flags to fix
> > non-working configurations is always fair game.
>
> While it may work, the PCI bridge has NUMA and IOMMU implications that
> would restrict the current flexibility to group devices.
It's interesting you should mention that.
If you want to be flexible in placing the primary device WRT NUMA and
IOMMU, and given that both IOMMU and NUMA are keyed by the bus address,
then doesn't this completely break the idea of passing
the bus address to the guest?
> I'm not sure
> if vIOMMU would have to be introduced inadvertently for
> isolation/protection of devices under the PCI bridge which may cause
> negative performance impact on the VF.
No idea how do you introduce an IOMMU inadvertently.
> >
> >> This is orthogonal to
> >> device model being proposed, be it 1-netdev or not. Delaying it would
> >> just mean support and compatibility burden, appearing more like a
> >> design flaw rather than a feature to add later on.
> >
> > Well it's mostly myself who gets to support it, and I see the device
> > model as much more fundamental as userspace will come to depend
> > on it. So I'm not too worried, let's take this one step at a time.
> >
> >> >
> >> > I think ideally the infrastructure should suppport flexible matching of
> >> > NICs - netvsc is already reported to be moving to some kind of serial
> >> > address.
> >> >
> >> As Stephen said, Hyper-V supports the serial UUID thing from day-one.
> >> It's just the Linux netvsc guest driver itself does not leverage that
> >> ID from the very beginging.
> >>
> >> Regards,
> >> -Siwei
> >
> > We could add something like this, too. For example,
> > we could add a virtual VPD capability with a UUID.
>
> I'm not an expert on that and wonder how you could do this (add a
> virtual VPD capability with a UUID to passthrough device) with
> existing QEMU emulation model and native PCI bus.
I think I see an elegant way to do that.
You could put it in the port where you want to stick you PT device.
Here's how it could work then:
- standby virtio device is tied to a pci bridge.
Tied how? Well it could be
- behind this bridge
- include a bridge internally
- have the bridge as a PCI function
- include a bridge and the bridge as a PCI function
- have a VPD or serial capability with same UUID as the bridge
- primary passthrough device is placed behind a bridge
*with the same ID*
- either simply behind the same bridge
- or behind another bridge with the same UUID.
The treatment could also be limited just to bridges which have a
specific vendor/device id (maybe a good idea), or in any other arbitrary
way.
> >
> > Do you know how exactly does hyperv pass the UUID for NICs?
>
> Stephen might know it more and can correct me. But my personal
> interpretation is that the SN is a host generated 32 bit sequence
> number which is unique per VM instance and gets propogated to guest
> via the para-virtual Hyper-V PCI bus.
>
> Regards,
> -Siwei
Ah, so it's a Hyper-V thing.
> >
> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> >>
> >> >> >> >
> >> >> >> > --
> >> >> >> > MST
^ permalink raw reply [flat|nested] 114+ messages in thread
* [virtio-dev] Re: [PATCH v7 net-next 4/4] netvsc: refactor notifier/event handling code to use the failover framework
@ 2018-04-26 23:42 ` Michael S. Tsirkin
0 siblings, 0 replies; 114+ messages in thread
From: Michael S. Tsirkin @ 2018-04-26 23:42 UTC (permalink / raw)
To: Siwei Liu
Cc: Stephen Hemminger, Jiri Pirko, Sridhar Samudrala, David Miller,
Netdev, virtualization, virtio-dev, Brandeburg, Jesse,
Alexander Duyck, Jakub Kicinski, Jason Wang
On Thu, Apr 26, 2018 at 03:14:46PM -0700, Siwei Liu wrote:
> On Wed, Apr 25, 2018 at 7:28 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
> > On Wed, Apr 25, 2018 at 03:57:57PM -0700, Siwei Liu wrote:
> >> On Wed, Apr 25, 2018 at 3:22 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
> >> > On Wed, Apr 25, 2018 at 02:38:57PM -0700, Siwei Liu wrote:
> >> >> On Mon, Apr 23, 2018 at 1:06 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
> >> >> > On Mon, Apr 23, 2018 at 12:44:39PM -0700, Siwei Liu wrote:
> >> >> >> On Mon, Apr 23, 2018 at 10:56 AM, Michael S. Tsirkin <mst@redhat.com> wrote:
> >> >> >> > On Mon, Apr 23, 2018 at 10:44:40AM -0700, Stephen Hemminger wrote:
> >> >> >> >> On Mon, 23 Apr 2018 20:24:56 +0300
> >> >> >> >> "Michael S. Tsirkin" <mst@redhat.com> wrote:
> >> >> >> >>
> >> >> >> >> > On Mon, Apr 23, 2018 at 10:04:06AM -0700, Stephen Hemminger wrote:
> >> >> >> >> > > > >
> >> >> >> >> > > > >I will NAK patches to change to common code for netvsc especially the
> >> >> >> >> > > > >three device model. MS worked hard with distro vendors to support transparent
> >> >> >> >> > > > >mode, ans we really can't have a new model; or do backport.
> >> >> >> >> > > > >
> >> >> >> >> > > > >Plus, DPDK is now dependent on existing model.
> >> >> >> >> > > >
> >> >> >> >> > > > Sorry, but nobody here cares about dpdk or other similar oddities.
> >> >> >> >> > >
> >> >> >> >> > > The network device model is a userspace API, and DPDK is a userspace application.
> >> >> >> >> >
> >> >> >> >> > It is userspace but are you sure dpdk is actually poking at netdevs?
> >> >> >> >> > AFAIK it's normally banging device registers directly.
> >> >> >> >> >
> >> >> >> >> > > You can't go breaking userspace even if you don't like the application.
> >> >> >> >> >
> >> >> >> >> > Could you please explain how is the proposed patchset breaking
> >> >> >> >> > userspace? Ignoring DPDK for now, I don't think it changes the userspace
> >> >> >> >> > API at all.
> >> >> >> >> >
> >> >> >> >>
> >> >> >> >> The DPDK has a device driver vdev_netvsc which scans the Linux network devices
> >> >> >> >> to look for Linux netvsc device and the paired VF device and setup the
> >> >> >> >> DPDK environment. This setup creates a DPDK failsafe (bondingish) instance
> >> >> >> >> and sets up TAP support over the Linux netvsc device as well as the Mellanox
> >> >> >> >> VF device.
> >> >> >> >>
> >> >> >> >> So it depends on existing 2 device model. You can't go to a 3 device model
> >> >> >> >> or start hiding devices from userspace.
> >> >> >> >
> >> >> >> > Okay so how does the existing patch break that? IIUC does not go to
> >> >> >> > a 3 device model since netvsc calls failover_register directly.
> >> >> >> >
> >> >> >> >> Also, I am working on associating netvsc and VF device based on serial number
> >> >> >> >> rather than MAC address. The serial number is how Windows works now, and it makes
> >> >> >> >> sense for Linux and Windows to use the same mechanism if possible.
> >> >> >> >
> >> >> >> > Maybe we should support same for virtio ...
> >> >> >> > Which serial do you mean? From vpd?
> >> >> >> >
> >> >> >> > I guess you will want to keep supporting MAC for old hypervisors?
> >> >> >> >
> >> >> >> > It all seems like a reasonable thing to support in the generic core.
> >> >> >>
> >> >> >> That's the reason why I chose explicit identifier rather than rely on
> >> >> >> MAC address to bind/pair a device. MAC address can change. Even if it
> >> >> >> can't, malicious guest user can fake MAC address to skip binding.
> >> >> >>
> >> >> >> -Siwei
> >> >> >
> >> >> > Address should be sampled at device creation to prevent this
> >> >> > kind of hack. Not that it buys the malicious user much:
> >> >> > if you can poke at MAC addresses you probably already can
> >> >> > break networking.
> >> >>
> >> >> I don't understand why poking at MAC address may potentially break
> >> >> networking.
> >> >
> >> > Set a MAC address to match another device on the same LAN,
> >> > packets will stop reaching that MAC.
> >>
> >> What I meant was guest users may create a virtual link, say veth that
> >> has exactly the same MAC address as that for the VF, which can easily
> >> get around of the binding procedure.
> >
> > This patchset limits binding to PCI devices so it won't be affected
> > by any hacks around virtual devices.
>
> Wait, I vaguely recall you seemed to like to generalize this feature
> to non-PCI device.
It's purely a layering thing. It is cleaner not to have PCI specific
data in the device-specific transport-independent section of the virtio
spec.
> But now you're saying it should stick to PCI. It's
> not that I'm reluctant with sticking to PCI. The fact is that I don't
> think we can go with implementation until the semantics of the
> so-called _F_STANDBY feature can be clearly defined into the spec.
> Previously the boundary of using MAC address as the identifier for
> bonding was quite confusing to me. And now PCI adds to the matrix.
PCI is simply one way to exclude software NICs. It's not the most
elegant one, but it will cover many setups. We can add more types, but
we do want to exclude software devices since these have
not been supplied by the hypervisor.
> However it still does not gurantee uniqueness I think. It's almost
> incorrect of choosing MAC address as the ID in the beginning since
> that has the implication of breaking existing configs.
IMO there's no chance it will break any existing config since
no existing config sets _F_STANDBY.
> I don't think
> libvirt or QEMU today retricts the MAC address to be unique per VM
> instance. Neither the virtio spec mentions that.
You really don't have to.
> In addition, it's difficult to fake PCI device on Linux does not mean
> the same applies to other OSes that is going to implement this VirtIO
> feature. It's a fragile assumption IMHO.
What an OS does internally is its own business.
What we are telling the guest here is simply that the virtio NIC is
actually the same device as some other NIC. At this point we do not
specify this other NIC in any way. So how do you find it? Well it has
to have the same MAC clearly.
You point out that there could be multiple NICs with the same
MAC in theory. It's a broken config generally but since it
kind of works in some setups maybe it's worth supporting.
If so we can look for ways to make the matching more specific by e.g.
adding more flags but I see that as a separate issue,
and pretty narrow in scope.
> >
> >> There's no explicit flag to
> >> identify a VF or pass-through device AFAIK. And sometimes this happens
> >> maybe due to user misconfiguring the link. This process should be
> >> hardened to avoid from any potential configuration errors.
> >
> > They are still PCI devices though.
> >
> >> >
> >> >> Unlike VF, passthrough PCI endpoint device has its freedom
> >> >> to change the MAC address. Even on a VF setup it's not neccessarily
> >> >> always safe to assume the VF's MAC address cannot or shouldn't be
> >> >> changed. That depends on the specific need whether the host admin
> >> >> wants to restrict guest from changing the MAC address, although in
> >> >> most cases it's true.
> >> >>
> >> >> I understand we can use the perm_addr to distinguish. But as said,
> >> >> this will pose limitation of flexible configuration where one can
> >> >> assign VFs with identical MAC address at all while each VF belongs to
> >> >> different PF and/or different subnet for e.g. load balancing.
> >> >> And
> >> >> furthermore, the QEMU device model never uses MAC address to be
> >> >> interpreted as an identifier, which requires to be unique per VM
> >> >> instance. Why we're introducing this inconsistency?
> >> >>
> >> >> -Siwei
> >> >
> >> > Because it addresses most of the issues and is simple. That's already
> >> > much better than what we have now which is nothing unless guest
> >> > configures things manually.
> >>
> >> Did you see my QEMU patch for using BDF as the grouping identifier?
> >
> > Yes. And I don't think it can work because bus numbers are
> > guest specified.
>
> I know it's not ideal but perhaps its the best one can do in the KVM
> world without adding complex config e.g. PCI bridge.
KVM is just a VMX/SVM driver. I think you mean QEMU. And well -
"best one can do" is a high bar to clear.
> Even if bus
> number is guest specified, it's readily available in the guest and
> recognizable by any OS, while on the QEMU configuration users specify
> an id instead of the bus number. Unlike Hyper-V PCI bus, I don't think
> there exists a para-virtual PCI bus in QEMU backend to expose VPD
> capability to a passthrough device.
We can always add more interfaces if we need them. But let's be clear
that we are adding an interface and what are we trying to fix by doing
it. Let's not mix it as part of the failover discussion.
> >
> >> And there can be others like what you suggested, but the point is that
> >> it's requried to support explicit grouping mechanism from day one,
> >> before the backup property cast into stones.
> >
> > Let's start with addressing simple configs with just two NICs.
> >
> > Down the road I can see possible extensions that can work: for example,
> > require that devices are on the same pci bridge. Or we could even make
> > the virtio device actually include a pci bridge (as part of same
> > or a child function), the PT would have to be
> > behind it.
> >
> > As long as we are not breaking anything, adding more flags to fix
> > non-working configurations is always fair game.
>
> While it may work, the PCI bridge has NUMA and IOMMU implications that
> would restrict the current flexibility to group devices.
It's interesting you should mention that.
If you want to be flexible in placing the primary device WRT NUMA and
IOMMU, and given that both IOMMU and NUMA are keyed by the bus address,
then doesn't this completely break the idea of passing
the bus address to the guest?
> I'm not sure
> if vIOMMU would have to be introduced inadvertently for
> isolation/protection of devices under the PCI bridge which may cause
> negative performance impact on the VF.
No idea how do you introduce an IOMMU inadvertently.
> >
> >> This is orthogonal to
> >> device model being proposed, be it 1-netdev or not. Delaying it would
> >> just mean support and compatibility burden, appearing more like a
> >> design flaw rather than a feature to add later on.
> >
> > Well it's mostly myself who gets to support it, and I see the device
> > model as much more fundamental as userspace will come to depend
> > on it. So I'm not too worried, let's take this one step at a time.
> >
> >> >
> >> > I think ideally the infrastructure should suppport flexible matching of
> >> > NICs - netvsc is already reported to be moving to some kind of serial
> >> > address.
> >> >
> >> As Stephen said, Hyper-V supports the serial UUID thing from day-one.
> >> It's just the Linux netvsc guest driver itself does not leverage that
> >> ID from the very beginging.
> >>
> >> Regards,
> >> -Siwei
> >
> > We could add something like this, too. For example,
> > we could add a virtual VPD capability with a UUID.
>
> I'm not an expert on that and wonder how you could do this (add a
> virtual VPD capability with a UUID to passthrough device) with
> existing QEMU emulation model and native PCI bus.
I think I see an elegant way to do that.
You could put it in the port where you want to stick you PT device.
Here's how it could work then:
- standby virtio device is tied to a pci bridge.
Tied how? Well it could be
- behind this bridge
- include a bridge internally
- have the bridge as a PCI function
- include a bridge and the bridge as a PCI function
- have a VPD or serial capability with same UUID as the bridge
- primary passthrough device is placed behind a bridge
*with the same ID*
- either simply behind the same bridge
- or behind another bridge with the same UUID.
The treatment could also be limited just to bridges which have a
specific vendor/device id (maybe a good idea), or in any other arbitrary
way.
> >
> > Do you know how exactly does hyperv pass the UUID for NICs?
>
> Stephen might know it more and can correct me. But my personal
> interpretation is that the SN is a host generated 32 bit sequence
> number which is unique per VM instance and gets propogated to guest
> via the para-virtual Hyper-V PCI bus.
>
> Regards,
> -Siwei
Ah, so it's a Hyper-V thing.
> >
> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> >>
> >> >> >> >
> >> >> >> > --
> >> >> >> > MST
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 net-next 4/4] netvsc: refactor notifier/event handling code to use the failover framework
2018-04-26 23:42 ` [virtio-dev] " Michael S. Tsirkin
@ 2018-04-28 0:43 ` Siwei Liu
-1 siblings, 0 replies; 114+ messages in thread
From: Siwei Liu @ 2018-04-28 0:43 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Stephen Hemminger, Jiri Pirko, Sridhar Samudrala, David Miller,
Netdev, virtualization, virtio-dev, Brandeburg, Jesse,
Alexander Duyck, Jakub Kicinski, Jason Wang
On Thu, Apr 26, 2018 at 4:42 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
> On Thu, Apr 26, 2018 at 03:14:46PM -0700, Siwei Liu wrote:
>> On Wed, Apr 25, 2018 at 7:28 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
>> > On Wed, Apr 25, 2018 at 03:57:57PM -0700, Siwei Liu wrote:
>> >> On Wed, Apr 25, 2018 at 3:22 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
>> >> > On Wed, Apr 25, 2018 at 02:38:57PM -0700, Siwei Liu wrote:
>> >> >> On Mon, Apr 23, 2018 at 1:06 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
>> >> >> > On Mon, Apr 23, 2018 at 12:44:39PM -0700, Siwei Liu wrote:
>> >> >> >> On Mon, Apr 23, 2018 at 10:56 AM, Michael S. Tsirkin <mst@redhat.com> wrote:
>> >> >> >> > On Mon, Apr 23, 2018 at 10:44:40AM -0700, Stephen Hemminger wrote:
>> >> >> >> >> On Mon, 23 Apr 2018 20:24:56 +0300
>> >> >> >> >> "Michael S. Tsirkin" <mst@redhat.com> wrote:
>> >> >> >> >>
>> >> >> >> >> > On Mon, Apr 23, 2018 at 10:04:06AM -0700, Stephen Hemminger wrote:
>> >> >> >> >> > > > >
>> >> >> >> >> > > > >I will NAK patches to change to common code for netvsc especially the
>> >> >> >> >> > > > >three device model. MS worked hard with distro vendors to support transparent
>> >> >> >> >> > > > >mode, ans we really can't have a new model; or do backport.
>> >> >> >> >> > > > >
>> >> >> >> >> > > > >Plus, DPDK is now dependent on existing model.
>> >> >> >> >> > > >
>> >> >> >> >> > > > Sorry, but nobody here cares about dpdk or other similar oddities.
>> >> >> >> >> > >
>> >> >> >> >> > > The network device model is a userspace API, and DPDK is a userspace application.
>> >> >> >> >> >
>> >> >> >> >> > It is userspace but are you sure dpdk is actually poking at netdevs?
>> >> >> >> >> > AFAIK it's normally banging device registers directly.
>> >> >> >> >> >
>> >> >> >> >> > > You can't go breaking userspace even if you don't like the application.
>> >> >> >> >> >
>> >> >> >> >> > Could you please explain how is the proposed patchset breaking
>> >> >> >> >> > userspace? Ignoring DPDK for now, I don't think it changes the userspace
>> >> >> >> >> > API at all.
>> >> >> >> >> >
>> >> >> >> >>
>> >> >> >> >> The DPDK has a device driver vdev_netvsc which scans the Linux network devices
>> >> >> >> >> to look for Linux netvsc device and the paired VF device and setup the
>> >> >> >> >> DPDK environment. This setup creates a DPDK failsafe (bondingish) instance
>> >> >> >> >> and sets up TAP support over the Linux netvsc device as well as the Mellanox
>> >> >> >> >> VF device.
>> >> >> >> >>
>> >> >> >> >> So it depends on existing 2 device model. You can't go to a 3 device model
>> >> >> >> >> or start hiding devices from userspace.
>> >> >> >> >
>> >> >> >> > Okay so how does the existing patch break that? IIUC does not go to
>> >> >> >> > a 3 device model since netvsc calls failover_register directly.
>> >> >> >> >
>> >> >> >> >> Also, I am working on associating netvsc and VF device based on serial number
>> >> >> >> >> rather than MAC address. The serial number is how Windows works now, and it makes
>> >> >> >> >> sense for Linux and Windows to use the same mechanism if possible.
>> >> >> >> >
>> >> >> >> > Maybe we should support same for virtio ...
>> >> >> >> > Which serial do you mean? From vpd?
>> >> >> >> >
>> >> >> >> > I guess you will want to keep supporting MAC for old hypervisors?
>> >> >> >> >
>> >> >> >> > It all seems like a reasonable thing to support in the generic core.
>> >> >> >>
>> >> >> >> That's the reason why I chose explicit identifier rather than rely on
>> >> >> >> MAC address to bind/pair a device. MAC address can change. Even if it
>> >> >> >> can't, malicious guest user can fake MAC address to skip binding.
>> >> >> >>
>> >> >> >> -Siwei
>> >> >> >
>> >> >> > Address should be sampled at device creation to prevent this
>> >> >> > kind of hack. Not that it buys the malicious user much:
>> >> >> > if you can poke at MAC addresses you probably already can
>> >> >> > break networking.
>> >> >>
>> >> >> I don't understand why poking at MAC address may potentially break
>> >> >> networking.
>> >> >
>> >> > Set a MAC address to match another device on the same LAN,
>> >> > packets will stop reaching that MAC.
>> >>
>> >> What I meant was guest users may create a virtual link, say veth that
>> >> has exactly the same MAC address as that for the VF, which can easily
>> >> get around of the binding procedure.
>> >
>> > This patchset limits binding to PCI devices so it won't be affected
>> > by any hacks around virtual devices.
>>
>> Wait, I vaguely recall you seemed to like to generalize this feature
>> to non-PCI device.
>
> It's purely a layering thing. It is cleaner not to have PCI specific
> data in the device-specific transport-independent section of the virtio
> spec.
>
OK. So looks like you think it's okay to include PCI specific concept
but not the data? Like a feature indicating the virtio device is
behind a (external) PCI bridge, and perhaps also includes the data
present in the PCI bridge/function's capability?
Sorry for asking tough questions. I still need to understand and
digest the boundary of this layering thing.
>
>> But now you're saying it should stick to PCI. It's
>> not that I'm reluctant with sticking to PCI. The fact is that I don't
>> think we can go with implementation until the semantics of the
>> so-called _F_STANDBY feature can be clearly defined into the spec.
>> Previously the boundary of using MAC address as the identifier for
>> bonding was quite confusing to me. And now PCI adds to the matrix.
>
> PCI is simply one way to exclude software NICs. It's not the most
> elegant one, but it will cover many setups. We can add more types, but
> we do want to exclude software devices since these have
> not been supplied by the hypervisor.
I'm afraid it's a loose end. The real thing is there's no way to
indicate VF or passthrough device on Linux, even true on some other
OS. There's no such flag exists yet. Even the emulated e1000 and
rltk8139 device looks the same as PCI device. And as part of the
requirements of being a spec, the behaviour and expectation need to be
precisely described for implementations to follow. There's no point to
assume just one OS will implement this feature so it needs to depend
on specifics of that OS.
>
>> However it still does not gurantee uniqueness I think. It's almost
>> incorrect of choosing MAC address as the ID in the beginning since
>> that has the implication of breaking existing configs.
>
> IMO there's no chance it will break any existing config since
> no existing config sets _F_STANDBY.
True, but it breaks people's expectation that it has to rely on MAC
address being unique when turning it on for live migration, and once
it happens some configs with same MAC address would break (for e.g.
bonding setup can have it for cross subnet failover and site
replication). Unless this limitation is clearly documented in the spec
I don't think people will notice that until it breaks.
>
>> I don't think
>> libvirt or QEMU today retricts the MAC address to be unique per VM
>> instance. Neither the virtio spec mentions that.
>
> You really don't have to.
>
>> In addition, it's difficult to fake PCI device on Linux does not mean
>> the same applies to other OSes that is going to implement this VirtIO
>> feature. It's a fragile assumption IMHO.
>
> What an OS does internally is its own business.
>
> What we are telling the guest here is simply that the virtio NIC is
> actually the same device as some other NIC. At this point we do not
> specify this other NIC in any way. So how do you find it? Well it has
> to have the same MAC clearly.
Well this condition is absolutely neccessary but not sufficient. There
should be some other unique key to help find the NIC as the MAC cannot
be unique as what people generally thought it be.
>
> You point out that there could be multiple NICs with the same
> MAC in theory. It's a broken config generally but since it
> kind of works in some setups maybe it's worth supporting.
> If so we can look for ways to make the matching more specific by e.g.
> adding more flags but I see that as a separate issue,
> and pretty narrow in scope.
Well there are precedents that people thought something broken but
soon find out users already depends on the "broken" behaviour.
Nowadays widely use of virtualization technology make MAC address
duplication really cheap. It's not that uncommon as one might think.
Unless the expectation can be explicitly documented in the spec, I
don't feel it's something users can easily infer from what the new
feature should target - live migration.
>
>> >
>> >> There's no explicit flag to
>> >> identify a VF or pass-through device AFAIK. And sometimes this happens
>> >> maybe due to user misconfiguring the link. This process should be
>> >> hardened to avoid from any potential configuration errors.
>> >
>> > They are still PCI devices though.
>> >
>> >> >
>> >> >> Unlike VF, passthrough PCI endpoint device has its freedom
>> >> >> to change the MAC address. Even on a VF setup it's not neccessarily
>> >> >> always safe to assume the VF's MAC address cannot or shouldn't be
>> >> >> changed. That depends on the specific need whether the host admin
>> >> >> wants to restrict guest from changing the MAC address, although in
>> >> >> most cases it's true.
>> >> >>
>> >> >> I understand we can use the perm_addr to distinguish. But as said,
>> >> >> this will pose limitation of flexible configuration where one can
>> >> >> assign VFs with identical MAC address at all while each VF belongs to
>> >> >> different PF and/or different subnet for e.g. load balancing.
>> >> >> And
>> >> >> furthermore, the QEMU device model never uses MAC address to be
>> >> >> interpreted as an identifier, which requires to be unique per VM
>> >> >> instance. Why we're introducing this inconsistency?
>> >> >>
>> >> >> -Siwei
>> >> >
>> >> > Because it addresses most of the issues and is simple. That's already
>> >> > much better than what we have now which is nothing unless guest
>> >> > configures things manually.
>> >>
>> >> Did you see my QEMU patch for using BDF as the grouping identifier?
>> >
>> > Yes. And I don't think it can work because bus numbers are
>> > guest specified.
>>
>> I know it's not ideal but perhaps its the best one can do in the KVM
>> world without adding complex config e.g. PCI bridge.
>
> KVM is just a VMX/SVM driver. I think you mean QEMU. And well -
> "best one can do" is a high bar to clear.
>
>
Glad you'd have to admit that there's no better way *without
introducing complex PCI bridge setup* in the KVM, oops, QEMU without
KVM? err, QEMU with KVM world.
>> Even if bus
>> number is guest specified, it's readily available in the guest and
>> recognizable by any OS, while on the QEMU configuration users specify
>> an id instead of the bus number. Unlike Hyper-V PCI bus, I don't think
>> there exists a para-virtual PCI bus in QEMU backend to expose VPD
>> capability to a passthrough device.
>
> We can always add more interfaces if we need them. But let's be clear
> that we are adding an interface and what are we trying to fix by doing
> it. Let's not mix it as part of the failover discussion.
I'm sorry, I don't understand why this should not be part of the
failover discussion.
There's a lot of ambiguity about the semantics and the expectation of
the _F_STANDBY feature, and that should be recorded in virtio-dev. If
you think we should run it with a different thread, I can definitely
fork a new thread to continue.
As you may wonder, the other aspects unclear to me now are:
- does this feature imply the device model already? The 3-netdev?
- should clear the feature bit upon unsuccessful creation of the
failover interface or failure to enslave the VF?
- does the feature bit indicate migratability status for the
corresponding VF/PT device?
- does the feature expect automatic bonding by default or always?
- does the guest user have the freedom to disable/re-enable the
automatic bonding? such that they can use raw VF for DPDK or RDMA
after the migration
- ...
I hope the answer won't just be to look at what the current
implementation is doing. The discussion will be helpful, at least not
harmful, for people to understand the intention and definition
clearly, since live migration itself is just too complicated.
>
>> >
>> >> And there can be others like what you suggested, but the point is that
>> >> it's requried to support explicit grouping mechanism from day one,
>> >> before the backup property cast into stones.
>> >
>> > Let's start with addressing simple configs with just two NICs.
>> >
>> > Down the road I can see possible extensions that can work: for example,
>> > require that devices are on the same pci bridge. Or we could even make
>> > the virtio device actually include a pci bridge (as part of same
>> > or a child function), the PT would have to be
>> > behind it.
>> >
>> > As long as we are not breaking anything, adding more flags to fix
>> > non-working configurations is always fair game.
>>
>> While it may work, the PCI bridge has NUMA and IOMMU implications that
>> would restrict the current flexibility to group devices.
>
> It's interesting you should mention that.
>
> If you want to be flexible in placing the primary device WRT NUMA and
> IOMMU, and given that both IOMMU and NUMA are keyed by the bus address,
> then doesn't this completely break the idea of passing
> the bus address to the guest?
I'm confused. Isn't the NUMA and IOMMU disposition host admin should
explicitly define? In that case it's assumed that s/he understand the
implication and the bus address doesn't restrict the host admin from
placing the device according to the NUMA or IOMMU
consideration/constrait.
>
>> I'm not sure
>> if vIOMMU would have to be introduced inadvertently for
>> isolation/protection of devices under the PCI bridge which may cause
>> negative performance impact on the VF.
>
> No idea how do you introduce an IOMMU inadvertently.
If the virtio has to be behind a different bridge thus IOMMU domain
than that for VF (which does not actually need a guest IOMMU) then
your former proposal of grouping them *under the same bridge* would
come across hurtles.
>
>> >
>> >> This is orthogonal to
>> >> device model being proposed, be it 1-netdev or not. Delaying it would
>> >> just mean support and compatibility burden, appearing more like a
>> >> design flaw rather than a feature to add later on.
>> >
>> > Well it's mostly myself who gets to support it, and I see the device
>> > model as much more fundamental as userspace will come to depend
>> > on it. So I'm not too worried, let's take this one step at a time.
>> >
>> >> >
>> >> > I think ideally the infrastructure should suppport flexible matching of
>> >> > NICs - netvsc is already reported to be moving to some kind of serial
>> >> > address.
>> >> >
>> >> As Stephen said, Hyper-V supports the serial UUID thing from day-one.
>> >> It's just the Linux netvsc guest driver itself does not leverage that
>> >> ID from the very beginging.
>> >>
>> >> Regards,
>> >> -Siwei
>> >
>> > We could add something like this, too. For example,
>> > we could add a virtual VPD capability with a UUID.
>>
>> I'm not an expert on that and wonder how you could do this (add a
>> virtual VPD capability with a UUID to passthrough device) with
>> existing QEMU emulation model and native PCI bus.
>
>
> I think I see an elegant way to do that.
>
> You could put it in the port where you want to stick you PT device.
>
> Here's how it could work then:
>
>
> - standby virtio device is tied to a pci bridge.
>
> Tied how? Well it could be
> - behind this bridge
An external PCI bridge? This gets back to the first question I ask.
It's interesting a virtio feature should reference an externel object
which seems more like a layering problem at least to me.
> - include a bridge internally
This internal one being a native PCI bridge or VirtIO PCI bridge? I'm
almost cerntain it should be the latter down the road. That determines
where the VPD or SN capability should reside.
> - have the bridge as a PCI function
> - include a bridge and the bridge as a PCI function
> - have a VPD or serial capability with same UUID as the bridge
>
> - primary passthrough device is placed behind a bridge
> *with the same ID*
>
> - either simply behind the same bridge
> - or behind another bridge with the same UUID.
>
Good. Decouple the concept of grouping to rely on same PCI bridge, and
another bridge with same UUID seems more flexible and promissing.
>
> The treatment could also be limited just to bridges which have a
> specific vendor/device id (maybe a good idea), or in any other arbitrary
> way.
I'd think anway VirtIO spec revision is unavoidable if you have to
involve PCI bridge. Not so complicated?
Regards,
-Siwei
>
>
>
>
>> >
>> > Do you know how exactly does hyperv pass the UUID for NICs?
>>
>> Stephen might know it more and can correct me. But my personal
>> interpretation is that the SN is a host generated 32 bit sequence
>> number which is unique per VM instance and gets propogated to guest
>> via the para-virtual Hyper-V PCI bus.
>>
>> Regards,
>> -Siwei
>
> Ah, so it's a Hyper-V thing.
>
>
>
>
>> >
>> >> >
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >>
>> >> >> >> >
>> >> >> >> > --
>> >> >> >> > MST
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 net-next 4/4] netvsc: refactor notifier/event handling code to use the failover framework
2018-04-26 23:42 ` [virtio-dev] " Michael S. Tsirkin
(?)
@ 2018-04-28 0:43 ` Siwei Liu
-1 siblings, 0 replies; 114+ messages in thread
From: Siwei Liu @ 2018-04-28 0:43 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Alexander Duyck, virtio-dev, Jiri Pirko, Jakub Kicinski,
Sridhar Samudrala, virtualization, Netdev, David Miller
On Thu, Apr 26, 2018 at 4:42 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
> On Thu, Apr 26, 2018 at 03:14:46PM -0700, Siwei Liu wrote:
>> On Wed, Apr 25, 2018 at 7:28 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
>> > On Wed, Apr 25, 2018 at 03:57:57PM -0700, Siwei Liu wrote:
>> >> On Wed, Apr 25, 2018 at 3:22 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
>> >> > On Wed, Apr 25, 2018 at 02:38:57PM -0700, Siwei Liu wrote:
>> >> >> On Mon, Apr 23, 2018 at 1:06 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
>> >> >> > On Mon, Apr 23, 2018 at 12:44:39PM -0700, Siwei Liu wrote:
>> >> >> >> On Mon, Apr 23, 2018 at 10:56 AM, Michael S. Tsirkin <mst@redhat.com> wrote:
>> >> >> >> > On Mon, Apr 23, 2018 at 10:44:40AM -0700, Stephen Hemminger wrote:
>> >> >> >> >> On Mon, 23 Apr 2018 20:24:56 +0300
>> >> >> >> >> "Michael S. Tsirkin" <mst@redhat.com> wrote:
>> >> >> >> >>
>> >> >> >> >> > On Mon, Apr 23, 2018 at 10:04:06AM -0700, Stephen Hemminger wrote:
>> >> >> >> >> > > > >
>> >> >> >> >> > > > >I will NAK patches to change to common code for netvsc especially the
>> >> >> >> >> > > > >three device model. MS worked hard with distro vendors to support transparent
>> >> >> >> >> > > > >mode, ans we really can't have a new model; or do backport.
>> >> >> >> >> > > > >
>> >> >> >> >> > > > >Plus, DPDK is now dependent on existing model.
>> >> >> >> >> > > >
>> >> >> >> >> > > > Sorry, but nobody here cares about dpdk or other similar oddities.
>> >> >> >> >> > >
>> >> >> >> >> > > The network device model is a userspace API, and DPDK is a userspace application.
>> >> >> >> >> >
>> >> >> >> >> > It is userspace but are you sure dpdk is actually poking at netdevs?
>> >> >> >> >> > AFAIK it's normally banging device registers directly.
>> >> >> >> >> >
>> >> >> >> >> > > You can't go breaking userspace even if you don't like the application.
>> >> >> >> >> >
>> >> >> >> >> > Could you please explain how is the proposed patchset breaking
>> >> >> >> >> > userspace? Ignoring DPDK for now, I don't think it changes the userspace
>> >> >> >> >> > API at all.
>> >> >> >> >> >
>> >> >> >> >>
>> >> >> >> >> The DPDK has a device driver vdev_netvsc which scans the Linux network devices
>> >> >> >> >> to look for Linux netvsc device and the paired VF device and setup the
>> >> >> >> >> DPDK environment. This setup creates a DPDK failsafe (bondingish) instance
>> >> >> >> >> and sets up TAP support over the Linux netvsc device as well as the Mellanox
>> >> >> >> >> VF device.
>> >> >> >> >>
>> >> >> >> >> So it depends on existing 2 device model. You can't go to a 3 device model
>> >> >> >> >> or start hiding devices from userspace.
>> >> >> >> >
>> >> >> >> > Okay so how does the existing patch break that? IIUC does not go to
>> >> >> >> > a 3 device model since netvsc calls failover_register directly.
>> >> >> >> >
>> >> >> >> >> Also, I am working on associating netvsc and VF device based on serial number
>> >> >> >> >> rather than MAC address. The serial number is how Windows works now, and it makes
>> >> >> >> >> sense for Linux and Windows to use the same mechanism if possible.
>> >> >> >> >
>> >> >> >> > Maybe we should support same for virtio ...
>> >> >> >> > Which serial do you mean? From vpd?
>> >> >> >> >
>> >> >> >> > I guess you will want to keep supporting MAC for old hypervisors?
>> >> >> >> >
>> >> >> >> > It all seems like a reasonable thing to support in the generic core.
>> >> >> >>
>> >> >> >> That's the reason why I chose explicit identifier rather than rely on
>> >> >> >> MAC address to bind/pair a device. MAC address can change. Even if it
>> >> >> >> can't, malicious guest user can fake MAC address to skip binding.
>> >> >> >>
>> >> >> >> -Siwei
>> >> >> >
>> >> >> > Address should be sampled at device creation to prevent this
>> >> >> > kind of hack. Not that it buys the malicious user much:
>> >> >> > if you can poke at MAC addresses you probably already can
>> >> >> > break networking.
>> >> >>
>> >> >> I don't understand why poking at MAC address may potentially break
>> >> >> networking.
>> >> >
>> >> > Set a MAC address to match another device on the same LAN,
>> >> > packets will stop reaching that MAC.
>> >>
>> >> What I meant was guest users may create a virtual link, say veth that
>> >> has exactly the same MAC address as that for the VF, which can easily
>> >> get around of the binding procedure.
>> >
>> > This patchset limits binding to PCI devices so it won't be affected
>> > by any hacks around virtual devices.
>>
>> Wait, I vaguely recall you seemed to like to generalize this feature
>> to non-PCI device.
>
> It's purely a layering thing. It is cleaner not to have PCI specific
> data in the device-specific transport-independent section of the virtio
> spec.
>
OK. So looks like you think it's okay to include PCI specific concept
but not the data? Like a feature indicating the virtio device is
behind a (external) PCI bridge, and perhaps also includes the data
present in the PCI bridge/function's capability?
Sorry for asking tough questions. I still need to understand and
digest the boundary of this layering thing.
>
>> But now you're saying it should stick to PCI. It's
>> not that I'm reluctant with sticking to PCI. The fact is that I don't
>> think we can go with implementation until the semantics of the
>> so-called _F_STANDBY feature can be clearly defined into the spec.
>> Previously the boundary of using MAC address as the identifier for
>> bonding was quite confusing to me. And now PCI adds to the matrix.
>
> PCI is simply one way to exclude software NICs. It's not the most
> elegant one, but it will cover many setups. We can add more types, but
> we do want to exclude software devices since these have
> not been supplied by the hypervisor.
I'm afraid it's a loose end. The real thing is there's no way to
indicate VF or passthrough device on Linux, even true on some other
OS. There's no such flag exists yet. Even the emulated e1000 and
rltk8139 device looks the same as PCI device. And as part of the
requirements of being a spec, the behaviour and expectation need to be
precisely described for implementations to follow. There's no point to
assume just one OS will implement this feature so it needs to depend
on specifics of that OS.
>
>> However it still does not gurantee uniqueness I think. It's almost
>> incorrect of choosing MAC address as the ID in the beginning since
>> that has the implication of breaking existing configs.
>
> IMO there's no chance it will break any existing config since
> no existing config sets _F_STANDBY.
True, but it breaks people's expectation that it has to rely on MAC
address being unique when turning it on for live migration, and once
it happens some configs with same MAC address would break (for e.g.
bonding setup can have it for cross subnet failover and site
replication). Unless this limitation is clearly documented in the spec
I don't think people will notice that until it breaks.
>
>> I don't think
>> libvirt or QEMU today retricts the MAC address to be unique per VM
>> instance. Neither the virtio spec mentions that.
>
> You really don't have to.
>
>> In addition, it's difficult to fake PCI device on Linux does not mean
>> the same applies to other OSes that is going to implement this VirtIO
>> feature. It's a fragile assumption IMHO.
>
> What an OS does internally is its own business.
>
> What we are telling the guest here is simply that the virtio NIC is
> actually the same device as some other NIC. At this point we do not
> specify this other NIC in any way. So how do you find it? Well it has
> to have the same MAC clearly.
Well this condition is absolutely neccessary but not sufficient. There
should be some other unique key to help find the NIC as the MAC cannot
be unique as what people generally thought it be.
>
> You point out that there could be multiple NICs with the same
> MAC in theory. It's a broken config generally but since it
> kind of works in some setups maybe it's worth supporting.
> If so we can look for ways to make the matching more specific by e.g.
> adding more flags but I see that as a separate issue,
> and pretty narrow in scope.
Well there are precedents that people thought something broken but
soon find out users already depends on the "broken" behaviour.
Nowadays widely use of virtualization technology make MAC address
duplication really cheap. It's not that uncommon as one might think.
Unless the expectation can be explicitly documented in the spec, I
don't feel it's something users can easily infer from what the new
feature should target - live migration.
>
>> >
>> >> There's no explicit flag to
>> >> identify a VF or pass-through device AFAIK. And sometimes this happens
>> >> maybe due to user misconfiguring the link. This process should be
>> >> hardened to avoid from any potential configuration errors.
>> >
>> > They are still PCI devices though.
>> >
>> >> >
>> >> >> Unlike VF, passthrough PCI endpoint device has its freedom
>> >> >> to change the MAC address. Even on a VF setup it's not neccessarily
>> >> >> always safe to assume the VF's MAC address cannot or shouldn't be
>> >> >> changed. That depends on the specific need whether the host admin
>> >> >> wants to restrict guest from changing the MAC address, although in
>> >> >> most cases it's true.
>> >> >>
>> >> >> I understand we can use the perm_addr to distinguish. But as said,
>> >> >> this will pose limitation of flexible configuration where one can
>> >> >> assign VFs with identical MAC address at all while each VF belongs to
>> >> >> different PF and/or different subnet for e.g. load balancing.
>> >> >> And
>> >> >> furthermore, the QEMU device model never uses MAC address to be
>> >> >> interpreted as an identifier, which requires to be unique per VM
>> >> >> instance. Why we're introducing this inconsistency?
>> >> >>
>> >> >> -Siwei
>> >> >
>> >> > Because it addresses most of the issues and is simple. That's already
>> >> > much better than what we have now which is nothing unless guest
>> >> > configures things manually.
>> >>
>> >> Did you see my QEMU patch for using BDF as the grouping identifier?
>> >
>> > Yes. And I don't think it can work because bus numbers are
>> > guest specified.
>>
>> I know it's not ideal but perhaps its the best one can do in the KVM
>> world without adding complex config e.g. PCI bridge.
>
> KVM is just a VMX/SVM driver. I think you mean QEMU. And well -
> "best one can do" is a high bar to clear.
>
>
Glad you'd have to admit that there's no better way *without
introducing complex PCI bridge setup* in the KVM, oops, QEMU without
KVM? err, QEMU with KVM world.
>> Even if bus
>> number is guest specified, it's readily available in the guest and
>> recognizable by any OS, while on the QEMU configuration users specify
>> an id instead of the bus number. Unlike Hyper-V PCI bus, I don't think
>> there exists a para-virtual PCI bus in QEMU backend to expose VPD
>> capability to a passthrough device.
>
> We can always add more interfaces if we need them. But let's be clear
> that we are adding an interface and what are we trying to fix by doing
> it. Let's not mix it as part of the failover discussion.
I'm sorry, I don't understand why this should not be part of the
failover discussion.
There's a lot of ambiguity about the semantics and the expectation of
the _F_STANDBY feature, and that should be recorded in virtio-dev. If
you think we should run it with a different thread, I can definitely
fork a new thread to continue.
As you may wonder, the other aspects unclear to me now are:
- does this feature imply the device model already? The 3-netdev?
- should clear the feature bit upon unsuccessful creation of the
failover interface or failure to enslave the VF?
- does the feature bit indicate migratability status for the
corresponding VF/PT device?
- does the feature expect automatic bonding by default or always?
- does the guest user have the freedom to disable/re-enable the
automatic bonding? such that they can use raw VF for DPDK or RDMA
after the migration
- ...
I hope the answer won't just be to look at what the current
implementation is doing. The discussion will be helpful, at least not
harmful, for people to understand the intention and definition
clearly, since live migration itself is just too complicated.
>
>> >
>> >> And there can be others like what you suggested, but the point is that
>> >> it's requried to support explicit grouping mechanism from day one,
>> >> before the backup property cast into stones.
>> >
>> > Let's start with addressing simple configs with just two NICs.
>> >
>> > Down the road I can see possible extensions that can work: for example,
>> > require that devices are on the same pci bridge. Or we could even make
>> > the virtio device actually include a pci bridge (as part of same
>> > or a child function), the PT would have to be
>> > behind it.
>> >
>> > As long as we are not breaking anything, adding more flags to fix
>> > non-working configurations is always fair game.
>>
>> While it may work, the PCI bridge has NUMA and IOMMU implications that
>> would restrict the current flexibility to group devices.
>
> It's interesting you should mention that.
>
> If you want to be flexible in placing the primary device WRT NUMA and
> IOMMU, and given that both IOMMU and NUMA are keyed by the bus address,
> then doesn't this completely break the idea of passing
> the bus address to the guest?
I'm confused. Isn't the NUMA and IOMMU disposition host admin should
explicitly define? In that case it's assumed that s/he understand the
implication and the bus address doesn't restrict the host admin from
placing the device according to the NUMA or IOMMU
consideration/constrait.
>
>> I'm not sure
>> if vIOMMU would have to be introduced inadvertently for
>> isolation/protection of devices under the PCI bridge which may cause
>> negative performance impact on the VF.
>
> No idea how do you introduce an IOMMU inadvertently.
If the virtio has to be behind a different bridge thus IOMMU domain
than that for VF (which does not actually need a guest IOMMU) then
your former proposal of grouping them *under the same bridge* would
come across hurtles.
>
>> >
>> >> This is orthogonal to
>> >> device model being proposed, be it 1-netdev or not. Delaying it would
>> >> just mean support and compatibility burden, appearing more like a
>> >> design flaw rather than a feature to add later on.
>> >
>> > Well it's mostly myself who gets to support it, and I see the device
>> > model as much more fundamental as userspace will come to depend
>> > on it. So I'm not too worried, let's take this one step at a time.
>> >
>> >> >
>> >> > I think ideally the infrastructure should suppport flexible matching of
>> >> > NICs - netvsc is already reported to be moving to some kind of serial
>> >> > address.
>> >> >
>> >> As Stephen said, Hyper-V supports the serial UUID thing from day-one.
>> >> It's just the Linux netvsc guest driver itself does not leverage that
>> >> ID from the very beginging.
>> >>
>> >> Regards,
>> >> -Siwei
>> >
>> > We could add something like this, too. For example,
>> > we could add a virtual VPD capability with a UUID.
>>
>> I'm not an expert on that and wonder how you could do this (add a
>> virtual VPD capability with a UUID to passthrough device) with
>> existing QEMU emulation model and native PCI bus.
>
>
> I think I see an elegant way to do that.
>
> You could put it in the port where you want to stick you PT device.
>
> Here's how it could work then:
>
>
> - standby virtio device is tied to a pci bridge.
>
> Tied how? Well it could be
> - behind this bridge
An external PCI bridge? This gets back to the first question I ask.
It's interesting a virtio feature should reference an externel object
which seems more like a layering problem at least to me.
> - include a bridge internally
This internal one being a native PCI bridge or VirtIO PCI bridge? I'm
almost cerntain it should be the latter down the road. That determines
where the VPD or SN capability should reside.
> - have the bridge as a PCI function
> - include a bridge and the bridge as a PCI function
> - have a VPD or serial capability with same UUID as the bridge
>
> - primary passthrough device is placed behind a bridge
> *with the same ID*
>
> - either simply behind the same bridge
> - or behind another bridge with the same UUID.
>
Good. Decouple the concept of grouping to rely on same PCI bridge, and
another bridge with same UUID seems more flexible and promissing.
>
> The treatment could also be limited just to bridges which have a
> specific vendor/device id (maybe a good idea), or in any other arbitrary
> way.
I'd think anway VirtIO spec revision is unavoidable if you have to
involve PCI bridge. Not so complicated?
Regards,
-Siwei
>
>
>
>
>> >
>> > Do you know how exactly does hyperv pass the UUID for NICs?
>>
>> Stephen might know it more and can correct me. But my personal
>> interpretation is that the SN is a host generated 32 bit sequence
>> number which is unique per VM instance and gets propogated to guest
>> via the para-virtual Hyper-V PCI bus.
>>
>> Regards,
>> -Siwei
>
> Ah, so it's a Hyper-V thing.
>
>
>
>
>> >
>> >> >
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >>
>> >> >> >> >
>> >> >> >> > --
>> >> >> >> > MST
^ permalink raw reply [flat|nested] 114+ messages in thread
* [virtio-dev] Re: [PATCH v7 net-next 4/4] netvsc: refactor notifier/event handling code to use the failover framework
@ 2018-04-28 0:43 ` Siwei Liu
0 siblings, 0 replies; 114+ messages in thread
From: Siwei Liu @ 2018-04-28 0:43 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Stephen Hemminger, Jiri Pirko, Sridhar Samudrala, David Miller,
Netdev, virtualization, virtio-dev, Brandeburg, Jesse,
Alexander Duyck, Jakub Kicinski, Jason Wang
On Thu, Apr 26, 2018 at 4:42 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
> On Thu, Apr 26, 2018 at 03:14:46PM -0700, Siwei Liu wrote:
>> On Wed, Apr 25, 2018 at 7:28 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
>> > On Wed, Apr 25, 2018 at 03:57:57PM -0700, Siwei Liu wrote:
>> >> On Wed, Apr 25, 2018 at 3:22 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
>> >> > On Wed, Apr 25, 2018 at 02:38:57PM -0700, Siwei Liu wrote:
>> >> >> On Mon, Apr 23, 2018 at 1:06 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
>> >> >> > On Mon, Apr 23, 2018 at 12:44:39PM -0700, Siwei Liu wrote:
>> >> >> >> On Mon, Apr 23, 2018 at 10:56 AM, Michael S. Tsirkin <mst@redhat.com> wrote:
>> >> >> >> > On Mon, Apr 23, 2018 at 10:44:40AM -0700, Stephen Hemminger wrote:
>> >> >> >> >> On Mon, 23 Apr 2018 20:24:56 +0300
>> >> >> >> >> "Michael S. Tsirkin" <mst@redhat.com> wrote:
>> >> >> >> >>
>> >> >> >> >> > On Mon, Apr 23, 2018 at 10:04:06AM -0700, Stephen Hemminger wrote:
>> >> >> >> >> > > > >
>> >> >> >> >> > > > >I will NAK patches to change to common code for netvsc especially the
>> >> >> >> >> > > > >three device model. MS worked hard with distro vendors to support transparent
>> >> >> >> >> > > > >mode, ans we really can't have a new model; or do backport.
>> >> >> >> >> > > > >
>> >> >> >> >> > > > >Plus, DPDK is now dependent on existing model.
>> >> >> >> >> > > >
>> >> >> >> >> > > > Sorry, but nobody here cares about dpdk or other similar oddities.
>> >> >> >> >> > >
>> >> >> >> >> > > The network device model is a userspace API, and DPDK is a userspace application.
>> >> >> >> >> >
>> >> >> >> >> > It is userspace but are you sure dpdk is actually poking at netdevs?
>> >> >> >> >> > AFAIK it's normally banging device registers directly.
>> >> >> >> >> >
>> >> >> >> >> > > You can't go breaking userspace even if you don't like the application.
>> >> >> >> >> >
>> >> >> >> >> > Could you please explain how is the proposed patchset breaking
>> >> >> >> >> > userspace? Ignoring DPDK for now, I don't think it changes the userspace
>> >> >> >> >> > API at all.
>> >> >> >> >> >
>> >> >> >> >>
>> >> >> >> >> The DPDK has a device driver vdev_netvsc which scans the Linux network devices
>> >> >> >> >> to look for Linux netvsc device and the paired VF device and setup the
>> >> >> >> >> DPDK environment. This setup creates a DPDK failsafe (bondingish) instance
>> >> >> >> >> and sets up TAP support over the Linux netvsc device as well as the Mellanox
>> >> >> >> >> VF device.
>> >> >> >> >>
>> >> >> >> >> So it depends on existing 2 device model. You can't go to a 3 device model
>> >> >> >> >> or start hiding devices from userspace.
>> >> >> >> >
>> >> >> >> > Okay so how does the existing patch break that? IIUC does not go to
>> >> >> >> > a 3 device model since netvsc calls failover_register directly.
>> >> >> >> >
>> >> >> >> >> Also, I am working on associating netvsc and VF device based on serial number
>> >> >> >> >> rather than MAC address. The serial number is how Windows works now, and it makes
>> >> >> >> >> sense for Linux and Windows to use the same mechanism if possible.
>> >> >> >> >
>> >> >> >> > Maybe we should support same for virtio ...
>> >> >> >> > Which serial do you mean? From vpd?
>> >> >> >> >
>> >> >> >> > I guess you will want to keep supporting MAC for old hypervisors?
>> >> >> >> >
>> >> >> >> > It all seems like a reasonable thing to support in the generic core.
>> >> >> >>
>> >> >> >> That's the reason why I chose explicit identifier rather than rely on
>> >> >> >> MAC address to bind/pair a device. MAC address can change. Even if it
>> >> >> >> can't, malicious guest user can fake MAC address to skip binding.
>> >> >> >>
>> >> >> >> -Siwei
>> >> >> >
>> >> >> > Address should be sampled at device creation to prevent this
>> >> >> > kind of hack. Not that it buys the malicious user much:
>> >> >> > if you can poke at MAC addresses you probably already can
>> >> >> > break networking.
>> >> >>
>> >> >> I don't understand why poking at MAC address may potentially break
>> >> >> networking.
>> >> >
>> >> > Set a MAC address to match another device on the same LAN,
>> >> > packets will stop reaching that MAC.
>> >>
>> >> What I meant was guest users may create a virtual link, say veth that
>> >> has exactly the same MAC address as that for the VF, which can easily
>> >> get around of the binding procedure.
>> >
>> > This patchset limits binding to PCI devices so it won't be affected
>> > by any hacks around virtual devices.
>>
>> Wait, I vaguely recall you seemed to like to generalize this feature
>> to non-PCI device.
>
> It's purely a layering thing. It is cleaner not to have PCI specific
> data in the device-specific transport-independent section of the virtio
> spec.
>
OK. So looks like you think it's okay to include PCI specific concept
but not the data? Like a feature indicating the virtio device is
behind a (external) PCI bridge, and perhaps also includes the data
present in the PCI bridge/function's capability?
Sorry for asking tough questions. I still need to understand and
digest the boundary of this layering thing.
>
>> But now you're saying it should stick to PCI. It's
>> not that I'm reluctant with sticking to PCI. The fact is that I don't
>> think we can go with implementation until the semantics of the
>> so-called _F_STANDBY feature can be clearly defined into the spec.
>> Previously the boundary of using MAC address as the identifier for
>> bonding was quite confusing to me. And now PCI adds to the matrix.
>
> PCI is simply one way to exclude software NICs. It's not the most
> elegant one, but it will cover many setups. We can add more types, but
> we do want to exclude software devices since these have
> not been supplied by the hypervisor.
I'm afraid it's a loose end. The real thing is there's no way to
indicate VF or passthrough device on Linux, even true on some other
OS. There's no such flag exists yet. Even the emulated e1000 and
rltk8139 device looks the same as PCI device. And as part of the
requirements of being a spec, the behaviour and expectation need to be
precisely described for implementations to follow. There's no point to
assume just one OS will implement this feature so it needs to depend
on specifics of that OS.
>
>> However it still does not gurantee uniqueness I think. It's almost
>> incorrect of choosing MAC address as the ID in the beginning since
>> that has the implication of breaking existing configs.
>
> IMO there's no chance it will break any existing config since
> no existing config sets _F_STANDBY.
True, but it breaks people's expectation that it has to rely on MAC
address being unique when turning it on for live migration, and once
it happens some configs with same MAC address would break (for e.g.
bonding setup can have it for cross subnet failover and site
replication). Unless this limitation is clearly documented in the spec
I don't think people will notice that until it breaks.
>
>> I don't think
>> libvirt or QEMU today retricts the MAC address to be unique per VM
>> instance. Neither the virtio spec mentions that.
>
> You really don't have to.
>
>> In addition, it's difficult to fake PCI device on Linux does not mean
>> the same applies to other OSes that is going to implement this VirtIO
>> feature. It's a fragile assumption IMHO.
>
> What an OS does internally is its own business.
>
> What we are telling the guest here is simply that the virtio NIC is
> actually the same device as some other NIC. At this point we do not
> specify this other NIC in any way. So how do you find it? Well it has
> to have the same MAC clearly.
Well this condition is absolutely neccessary but not sufficient. There
should be some other unique key to help find the NIC as the MAC cannot
be unique as what people generally thought it be.
>
> You point out that there could be multiple NICs with the same
> MAC in theory. It's a broken config generally but since it
> kind of works in some setups maybe it's worth supporting.
> If so we can look for ways to make the matching more specific by e.g.
> adding more flags but I see that as a separate issue,
> and pretty narrow in scope.
Well there are precedents that people thought something broken but
soon find out users already depends on the "broken" behaviour.
Nowadays widely use of virtualization technology make MAC address
duplication really cheap. It's not that uncommon as one might think.
Unless the expectation can be explicitly documented in the spec, I
don't feel it's something users can easily infer from what the new
feature should target - live migration.
>
>> >
>> >> There's no explicit flag to
>> >> identify a VF or pass-through device AFAIK. And sometimes this happens
>> >> maybe due to user misconfiguring the link. This process should be
>> >> hardened to avoid from any potential configuration errors.
>> >
>> > They are still PCI devices though.
>> >
>> >> >
>> >> >> Unlike VF, passthrough PCI endpoint device has its freedom
>> >> >> to change the MAC address. Even on a VF setup it's not neccessarily
>> >> >> always safe to assume the VF's MAC address cannot or shouldn't be
>> >> >> changed. That depends on the specific need whether the host admin
>> >> >> wants to restrict guest from changing the MAC address, although in
>> >> >> most cases it's true.
>> >> >>
>> >> >> I understand we can use the perm_addr to distinguish. But as said,
>> >> >> this will pose limitation of flexible configuration where one can
>> >> >> assign VFs with identical MAC address at all while each VF belongs to
>> >> >> different PF and/or different subnet for e.g. load balancing.
>> >> >> And
>> >> >> furthermore, the QEMU device model never uses MAC address to be
>> >> >> interpreted as an identifier, which requires to be unique per VM
>> >> >> instance. Why we're introducing this inconsistency?
>> >> >>
>> >> >> -Siwei
>> >> >
>> >> > Because it addresses most of the issues and is simple. That's already
>> >> > much better than what we have now which is nothing unless guest
>> >> > configures things manually.
>> >>
>> >> Did you see my QEMU patch for using BDF as the grouping identifier?
>> >
>> > Yes. And I don't think it can work because bus numbers are
>> > guest specified.
>>
>> I know it's not ideal but perhaps its the best one can do in the KVM
>> world without adding complex config e.g. PCI bridge.
>
> KVM is just a VMX/SVM driver. I think you mean QEMU. And well -
> "best one can do" is a high bar to clear.
>
>
Glad you'd have to admit that there's no better way *without
introducing complex PCI bridge setup* in the KVM, oops, QEMU without
KVM? err, QEMU with KVM world.
>> Even if bus
>> number is guest specified, it's readily available in the guest and
>> recognizable by any OS, while on the QEMU configuration users specify
>> an id instead of the bus number. Unlike Hyper-V PCI bus, I don't think
>> there exists a para-virtual PCI bus in QEMU backend to expose VPD
>> capability to a passthrough device.
>
> We can always add more interfaces if we need them. But let's be clear
> that we are adding an interface and what are we trying to fix by doing
> it. Let's not mix it as part of the failover discussion.
I'm sorry, I don't understand why this should not be part of the
failover discussion.
There's a lot of ambiguity about the semantics and the expectation of
the _F_STANDBY feature, and that should be recorded in virtio-dev. If
you think we should run it with a different thread, I can definitely
fork a new thread to continue.
As you may wonder, the other aspects unclear to me now are:
- does this feature imply the device model already? The 3-netdev?
- should clear the feature bit upon unsuccessful creation of the
failover interface or failure to enslave the VF?
- does the feature bit indicate migratability status for the
corresponding VF/PT device?
- does the feature expect automatic bonding by default or always?
- does the guest user have the freedom to disable/re-enable the
automatic bonding? such that they can use raw VF for DPDK or RDMA
after the migration
- ...
I hope the answer won't just be to look at what the current
implementation is doing. The discussion will be helpful, at least not
harmful, for people to understand the intention and definition
clearly, since live migration itself is just too complicated.
>
>> >
>> >> And there can be others like what you suggested, but the point is that
>> >> it's requried to support explicit grouping mechanism from day one,
>> >> before the backup property cast into stones.
>> >
>> > Let's start with addressing simple configs with just two NICs.
>> >
>> > Down the road I can see possible extensions that can work: for example,
>> > require that devices are on the same pci bridge. Or we could even make
>> > the virtio device actually include a pci bridge (as part of same
>> > or a child function), the PT would have to be
>> > behind it.
>> >
>> > As long as we are not breaking anything, adding more flags to fix
>> > non-working configurations is always fair game.
>>
>> While it may work, the PCI bridge has NUMA and IOMMU implications that
>> would restrict the current flexibility to group devices.
>
> It's interesting you should mention that.
>
> If you want to be flexible in placing the primary device WRT NUMA and
> IOMMU, and given that both IOMMU and NUMA are keyed by the bus address,
> then doesn't this completely break the idea of passing
> the bus address to the guest?
I'm confused. Isn't the NUMA and IOMMU disposition host admin should
explicitly define? In that case it's assumed that s/he understand the
implication and the bus address doesn't restrict the host admin from
placing the device according to the NUMA or IOMMU
consideration/constrait.
>
>> I'm not sure
>> if vIOMMU would have to be introduced inadvertently for
>> isolation/protection of devices under the PCI bridge which may cause
>> negative performance impact on the VF.
>
> No idea how do you introduce an IOMMU inadvertently.
If the virtio has to be behind a different bridge thus IOMMU domain
than that for VF (which does not actually need a guest IOMMU) then
your former proposal of grouping them *under the same bridge* would
come across hurtles.
>
>> >
>> >> This is orthogonal to
>> >> device model being proposed, be it 1-netdev or not. Delaying it would
>> >> just mean support and compatibility burden, appearing more like a
>> >> design flaw rather than a feature to add later on.
>> >
>> > Well it's mostly myself who gets to support it, and I see the device
>> > model as much more fundamental as userspace will come to depend
>> > on it. So I'm not too worried, let's take this one step at a time.
>> >
>> >> >
>> >> > I think ideally the infrastructure should suppport flexible matching of
>> >> > NICs - netvsc is already reported to be moving to some kind of serial
>> >> > address.
>> >> >
>> >> As Stephen said, Hyper-V supports the serial UUID thing from day-one.
>> >> It's just the Linux netvsc guest driver itself does not leverage that
>> >> ID from the very beginging.
>> >>
>> >> Regards,
>> >> -Siwei
>> >
>> > We could add something like this, too. For example,
>> > we could add a virtual VPD capability with a UUID.
>>
>> I'm not an expert on that and wonder how you could do this (add a
>> virtual VPD capability with a UUID to passthrough device) with
>> existing QEMU emulation model and native PCI bus.
>
>
> I think I see an elegant way to do that.
>
> You could put it in the port where you want to stick you PT device.
>
> Here's how it could work then:
>
>
> - standby virtio device is tied to a pci bridge.
>
> Tied how? Well it could be
> - behind this bridge
An external PCI bridge? This gets back to the first question I ask.
It's interesting a virtio feature should reference an externel object
which seems more like a layering problem at least to me.
> - include a bridge internally
This internal one being a native PCI bridge or VirtIO PCI bridge? I'm
almost cerntain it should be the latter down the road. That determines
where the VPD or SN capability should reside.
> - have the bridge as a PCI function
> - include a bridge and the bridge as a PCI function
> - have a VPD or serial capability with same UUID as the bridge
>
> - primary passthrough device is placed behind a bridge
> *with the same ID*
>
> - either simply behind the same bridge
> - or behind another bridge with the same UUID.
>
Good. Decouple the concept of grouping to rely on same PCI bridge, and
another bridge with same UUID seems more flexible and promissing.
>
> The treatment could also be limited just to bridges which have a
> specific vendor/device id (maybe a good idea), or in any other arbitrary
> way.
I'd think anway VirtIO spec revision is unavoidable if you have to
involve PCI bridge. Not so complicated?
Regards,
-Siwei
>
>
>
>
>> >
>> > Do you know how exactly does hyperv pass the UUID for NICs?
>>
>> Stephen might know it more and can correct me. But my personal
>> interpretation is that the SN is a host generated 32 bit sequence
>> number which is unique per VM instance and gets propogated to guest
>> via the para-virtual Hyper-V PCI bus.
>>
>> Regards,
>> -Siwei
>
> Ah, so it's a Hyper-V thing.
>
>
>
>
>> >
>> >> >
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >>
>> >> >> >> >
>> >> >> >> > --
>> >> >> >> > MST
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 114+ messages in thread
end of thread, other threads:[~2018-04-28 0:43 UTC | newest]
Thread overview: 114+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-04-20 1:42 [PATCH net-next v7 0/4] Enable virtio_net to act as a standby for a passthru device Sridhar Samudrala
2018-04-20 1:42 ` [virtio-dev] " Sridhar Samudrala
2018-04-20 1:42 ` [PATCH v7 net-next 1/4] virtio_net: Introduce VIRTIO_NET_F_STANDBY feature bit Sridhar Samudrala
2018-04-20 1:42 ` [virtio-dev] " Sridhar Samudrala
2018-04-20 1:42 ` Sridhar Samudrala
2018-04-20 1:42 ` [PATCH v7 net-next 2/4] net: Introduce generic failover module Sridhar Samudrala
2018-04-20 1:42 ` Sridhar Samudrala
2018-04-20 1:42 ` [virtio-dev] " Sridhar Samudrala
2018-04-20 2:44 ` Michael S. Tsirkin
2018-04-20 2:44 ` Michael S. Tsirkin
2018-04-20 2:44 ` [virtio-dev] " Michael S. Tsirkin
2018-04-20 15:21 ` Samudrala, Sridhar
2018-04-20 15:21 ` [virtio-dev] " Samudrala, Sridhar
2018-04-20 15:34 ` Michael S. Tsirkin
2018-04-20 15:34 ` Michael S. Tsirkin
2018-04-20 15:34 ` [virtio-dev] " Michael S. Tsirkin
2018-04-20 15:56 ` Alexander Duyck
2018-04-20 15:56 ` Alexander Duyck
2018-04-20 16:03 ` Michael S. Tsirkin
2018-04-20 16:03 ` Michael S. Tsirkin
2018-04-20 16:03 ` Michael S. Tsirkin
2018-04-20 15:56 ` Alexander Duyck
2018-04-20 15:21 ` Samudrala, Sridhar
2018-04-20 3:34 ` Michael S. Tsirkin
2018-04-20 3:34 ` [virtio-dev] " Michael S. Tsirkin
2018-04-20 3:34 ` Michael S. Tsirkin
2018-04-22 17:06 ` Michael S. Tsirkin
2018-04-22 17:06 ` Michael S. Tsirkin
2018-04-22 17:06 ` [virtio-dev] " Michael S. Tsirkin
2018-04-23 17:21 ` Samudrala, Sridhar
2018-04-23 17:21 ` [virtio-dev] " Samudrala, Sridhar
2018-04-22 18:29 ` kbuild test robot
2018-04-22 18:29 ` kbuild test robot
2018-04-20 1:42 ` [PATCH v7 net-next 3/4] virtio_net: Extend virtio to use VF datapath when available Sridhar Samudrala
2018-04-20 1:42 ` [virtio-dev] " Sridhar Samudrala
2018-04-20 2:46 ` Michael S. Tsirkin
2018-04-20 2:46 ` [virtio-dev] " Michael S. Tsirkin
2018-04-20 2:46 ` Michael S. Tsirkin
2018-04-22 15:41 ` kbuild test robot
2018-04-22 15:41 ` kbuild test robot
2018-04-22 15:41 ` kbuild test robot
2018-04-22 15:41 ` kbuild test robot
2018-04-20 1:42 ` Sridhar Samudrala
2018-04-20 1:42 ` [PATCH v7 net-next 4/4] netvsc: refactor notifier/event handling code to use the failover framework Sridhar Samudrala
2018-04-20 1:42 ` Sridhar Samudrala
2018-04-20 1:42 ` [virtio-dev] " Sridhar Samudrala
2018-04-20 15:28 ` Stephen Hemminger
2018-04-20 15:43 ` Michael S. Tsirkin
2018-04-20 15:43 ` Michael S. Tsirkin
2018-04-20 15:43 ` [virtio-dev] " Michael S. Tsirkin
2018-04-20 15:47 ` David Miller
2018-04-20 15:47 ` David Miller
2018-04-20 15:46 ` David Miller
2018-04-20 15:46 ` David Miller
2018-04-20 15:46 ` Samudrala, Sridhar
2018-04-20 15:46 ` Samudrala, Sridhar
2018-04-20 15:46 ` [virtio-dev] " Samudrala, Sridhar
2018-04-20 16:00 ` Jiri Pirko
2018-04-20 16:00 ` Jiri Pirko
2018-04-23 17:04 ` Stephen Hemminger
2018-04-23 17:24 ` Michael S. Tsirkin
2018-04-23 17:24 ` Michael S. Tsirkin
2018-04-23 17:24 ` [virtio-dev] " Michael S. Tsirkin
2018-04-23 17:44 ` Stephen Hemminger
2018-04-23 17:56 ` Michael S. Tsirkin
2018-04-23 17:56 ` Michael S. Tsirkin
2018-04-23 17:56 ` [virtio-dev] " Michael S. Tsirkin
2018-04-23 19:44 ` Siwei Liu
2018-04-23 19:44 ` Siwei Liu
2018-04-23 19:44 ` [virtio-dev] " Siwei Liu
2018-04-23 20:06 ` Michael S. Tsirkin
2018-04-23 20:06 ` Michael S. Tsirkin
2018-04-23 20:06 ` [virtio-dev] " Michael S. Tsirkin
2018-04-24 1:28 ` Stephen Hemminger
2018-04-24 1:28 ` Stephen Hemminger
2018-04-25 21:38 ` Siwei Liu
2018-04-25 21:38 ` [virtio-dev] " Siwei Liu
2018-04-25 22:22 ` Michael S. Tsirkin
2018-04-25 22:22 ` Michael S. Tsirkin
2018-04-25 22:22 ` [virtio-dev] " Michael S. Tsirkin
2018-04-25 22:57 ` Siwei Liu
2018-04-25 22:57 ` [virtio-dev] " Siwei Liu
2018-04-26 0:18 ` Stephen Hemminger
2018-04-26 0:18 ` Stephen Hemminger
2018-04-26 2:43 ` Michael S. Tsirkin
2018-04-26 2:43 ` Michael S. Tsirkin
2018-04-26 2:43 ` [virtio-dev] " Michael S. Tsirkin
2018-04-26 2:28 ` Michael S. Tsirkin
2018-04-26 2:28 ` Michael S. Tsirkin
2018-04-26 2:28 ` [virtio-dev] " Michael S. Tsirkin
2018-04-26 22:14 ` Siwei Liu
2018-04-26 22:14 ` [virtio-dev] " Siwei Liu
2018-04-26 23:42 ` Michael S. Tsirkin
2018-04-26 23:42 ` [virtio-dev] " Michael S. Tsirkin
2018-04-28 0:43 ` Siwei Liu
2018-04-28 0:43 ` Siwei Liu
2018-04-28 0:43 ` [virtio-dev] " Siwei Liu
2018-04-26 23:42 ` Michael S. Tsirkin
2018-04-26 22:14 ` Siwei Liu
2018-04-25 22:57 ` Siwei Liu
2018-04-24 1:25 ` Stephen Hemminger
2018-04-24 1:25 ` Stephen Hemminger
2018-04-24 1:42 ` Michael S. Tsirkin
2018-04-24 1:42 ` Michael S. Tsirkin
2018-04-24 1:42 ` [virtio-dev] " Michael S. Tsirkin
2018-04-24 5:07 ` Stephen Hemminger
2018-04-24 5:07 ` Stephen Hemminger
2018-04-23 17:44 ` Stephen Hemminger
2018-04-23 17:25 ` Jiri Pirko
2018-04-23 17:25 ` Jiri Pirko
2018-04-23 17:04 ` Stephen Hemminger
2018-04-20 15:28 ` Stephen Hemminger
2018-04-22 15:41 ` kbuild test robot
2018-04-22 15:41 ` kbuild test robot
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.