* [next-queue v3 PATCH 4/7] net: store port/representator id in metadata_dst
From: Sridhar Samudrala @ 2017-01-10 0:59 UTC (permalink / raw)
To: alexander.h.duyck, john.r.fastabend, anjali.singhai,
jakub.kicinski, davem, scott.d.peterson, gerlitz.or, jiri,
intel-wired-lan, netdev
In-Reply-To: <1484009990-3018-1-git-send-email-sridhar.samudrala@intel.com>
Switches and modern SR-IOV enabled NICs may multiplex traffic from Port
representators and control messages over single set of hardware queues.
Control messages and muxed traffic may need ordered delivery.
Those requirements make it hard to comfortably use TC infrastructure today
unless we have a way of attaching metadata to skbs at the upper device.
Because single set of queues is used for many netdevs stopping TC/sched queues
of all of them reliably is impossible and lower device has to retreat to
returning NETDEV_TX_BUSY and usually has to take extra locks on the fastpath.
This patch attempts to enable port/representative devs to attach metadata to
skbs which carry port id. This way representatives can be queueless and all
queuing can be performed at the lower netdev in the usual way.
Traffic arriving on the port/representative interfaces will be have metadata
attached and will subsequently be queued to the lower device for transmission.
The lower device should recognize the metadata and translate it to HW specific
format which is most likely either a special header inserted before the network
headers or descriptor/metadata fields.
Metadata is associated with the lower device by storing the netdev pointer along
with port id so that if TC decides to redirect or mirror the new netdev will not
try to interpret it.
This is mostly for SR-IOV devices since switches don't have lower netdevs today.
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Signed-off-by: Sridhar Samudrala <sridhar.samudrala@intel.com>
---
include/net/dst_metadata.h | 41 ++++++++++++++++++++++++++++++++---------
net/core/dst.c | 15 ++++++++++-----
net/core/filter.c | 1 +
net/ipv4/ip_tunnel_core.c | 6 ++++--
net/openvswitch/flow_netlink.c | 4 +++-
5 files changed, 50 insertions(+), 17 deletions(-)
diff --git a/include/net/dst_metadata.h b/include/net/dst_metadata.h
index 701fc81..a803129 100644
--- a/include/net/dst_metadata.h
+++ b/include/net/dst_metadata.h
@@ -5,10 +5,22 @@
#include <net/ip_tunnels.h>
#include <net/dst.h>
+enum metadata_type {
+ METADATA_IP_TUNNEL,
+ METADATA_HW_PORT_MUX,
+};
+
+struct hw_port_info {
+ struct net_device *lower_dev;
+ u32 port_id;
+};
+
struct metadata_dst {
struct dst_entry dst;
+ enum metadata_type type;
union {
struct ip_tunnel_info tun_info;
+ struct hw_port_info port_info;
} u;
};
@@ -27,7 +39,7 @@ static inline struct ip_tunnel_info *skb_tunnel_info(struct sk_buff *skb)
struct metadata_dst *md_dst = skb_metadata_dst(skb);
struct dst_entry *dst;
- if (md_dst)
+ if (md_dst && md_dst->type == METADATA_IP_TUNNEL)
return &md_dst->u.tun_info;
dst = skb_dst(skb);
@@ -55,22 +67,33 @@ static inline int skb_metadata_dst_cmp(const struct sk_buff *skb_a,
a = (const struct metadata_dst *) skb_dst(skb_a);
b = (const struct metadata_dst *) skb_dst(skb_b);
- if (!a != !b || a->u.tun_info.options_len != b->u.tun_info.options_len)
+ if (!a != !b || a->type != b->type)
return 1;
- return memcmp(&a->u.tun_info, &b->u.tun_info,
- sizeof(a->u.tun_info) + a->u.tun_info.options_len);
+ switch (a->type) {
+ case METADATA_HW_PORT_MUX:
+ return memcmp(&a->u.port_info, &b->u.port_info,
+ sizeof(a->u.port_info));
+ case METADATA_IP_TUNNEL:
+ return memcmp(&a->u.tun_info, &b->u.tun_info,
+ sizeof(a->u.tun_info) +
+ a->u.tun_info.options_len);
+ default:
+ return 1;
+ }
}
void metadata_dst_free(struct metadata_dst *);
-struct metadata_dst *metadata_dst_alloc(u8 optslen, gfp_t flags);
-struct metadata_dst __percpu *metadata_dst_alloc_percpu(u8 optslen, gfp_t flags);
+struct metadata_dst *metadata_dst_alloc(u8 optslen, enum metadata_type type,
+ gfp_t flags);
+struct metadata_dst __percpu *
+metadata_dst_alloc_percpu(u8 optslen, enum metadata_type type, gfp_t flags);
static inline struct metadata_dst *tun_rx_dst(int md_size)
{
struct metadata_dst *tun_dst;
- tun_dst = metadata_dst_alloc(md_size, GFP_ATOMIC);
+ tun_dst = metadata_dst_alloc(md_size, METADATA_IP_TUNNEL, GFP_ATOMIC);
if (!tun_dst)
return NULL;
@@ -85,11 +108,11 @@ static inline struct metadata_dst *tun_dst_unclone(struct sk_buff *skb)
int md_size;
struct metadata_dst *new_md;
- if (!md_dst)
+ if (!md_dst || md_dst->type != METADATA_IP_TUNNEL)
return ERR_PTR(-EINVAL);
md_size = md_dst->u.tun_info.options_len;
- new_md = metadata_dst_alloc(md_size, GFP_ATOMIC);
+ new_md = metadata_dst_alloc(md_size, METADATA_IP_TUNNEL, GFP_ATOMIC);
if (!new_md)
return ERR_PTR(-ENOMEM);
diff --git a/net/core/dst.c b/net/core/dst.c
index b5cbbe0..62dd4e4 100644
--- a/net/core/dst.c
+++ b/net/core/dst.c
@@ -367,7 +367,9 @@ static int dst_md_discard(struct sk_buff *skb)
return 0;
}
-static void __metadata_dst_init(struct metadata_dst *md_dst, u8 optslen)
+static void __metadata_dst_init(struct metadata_dst *md_dst,
+ enum metadata_type type, u8 optslen)
+
{
struct dst_entry *dst;
@@ -379,9 +381,11 @@ static void __metadata_dst_init(struct metadata_dst *md_dst, u8 optslen)
dst->output = dst_md_discard_out;
memset(dst + 1, 0, sizeof(*md_dst) + optslen - sizeof(*dst));
+ md_dst->type = type;
}
-struct metadata_dst *metadata_dst_alloc(u8 optslen, gfp_t flags)
+struct metadata_dst *metadata_dst_alloc(u8 optslen, enum metadata_type type,
+ gfp_t flags)
{
struct metadata_dst *md_dst;
@@ -389,7 +393,7 @@ struct metadata_dst *metadata_dst_alloc(u8 optslen, gfp_t flags)
if (!md_dst)
return NULL;
- __metadata_dst_init(md_dst, optslen);
+ __metadata_dst_init(md_dst, type, optslen);
return md_dst;
}
@@ -403,7 +407,8 @@ void metadata_dst_free(struct metadata_dst *md_dst)
kfree(md_dst);
}
-struct metadata_dst __percpu *metadata_dst_alloc_percpu(u8 optslen, gfp_t flags)
+struct metadata_dst __percpu *
+metadata_dst_alloc_percpu(u8 optslen, enum metadata_type type, gfp_t flags)
{
int cpu;
struct metadata_dst __percpu *md_dst;
@@ -414,7 +419,7 @@ struct metadata_dst __percpu *metadata_dst_alloc_percpu(u8 optslen, gfp_t flags)
return NULL;
for_each_possible_cpu(cpu)
- __metadata_dst_init(per_cpu_ptr(md_dst, cpu), optslen);
+ __metadata_dst_init(per_cpu_ptr(md_dst, cpu), type, optslen);
return md_dst;
}
diff --git a/net/core/filter.c b/net/core/filter.c
index 1969b3f..617ca0c 100644
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@ -2521,6 +2521,7 @@ bpf_get_skb_set_tunnel_proto(enum bpf_func_id which)
* that is holding verifier mutex.
*/
md_dst = metadata_dst_alloc_percpu(IP_TUNNEL_OPTS_MAX,
+ METADATA_IP_TUNNEL,
GFP_KERNEL);
if (!md_dst)
return NULL;
diff --git a/net/ipv4/ip_tunnel_core.c b/net/ipv4/ip_tunnel_core.c
index fed3d29..6b2dccd 100644
--- a/net/ipv4/ip_tunnel_core.c
+++ b/net/ipv4/ip_tunnel_core.c
@@ -134,10 +134,12 @@ struct metadata_dst *iptunnel_metadata_reply(struct metadata_dst *md,
struct metadata_dst *res;
struct ip_tunnel_info *dst, *src;
- if (!md || md->u.tun_info.mode & IP_TUNNEL_INFO_TX)
+ if (!md || md->type != METADATA_IP_TUNNEL ||
+ md->u.tun_info.mode & IP_TUNNEL_INFO_TX)
+
return NULL;
- res = metadata_dst_alloc(0, flags);
+ res = metadata_dst_alloc(0, METADATA_IP_TUNNEL, flags);
if (!res)
return NULL;
diff --git a/net/openvswitch/flow_netlink.c b/net/openvswitch/flow_netlink.c
index c87d359..164b4f1 100644
--- a/net/openvswitch/flow_netlink.c
+++ b/net/openvswitch/flow_netlink.c
@@ -2105,7 +2105,9 @@ static int validate_and_copy_set_tun(const struct nlattr *attr,
if (start < 0)
return start;
- tun_dst = metadata_dst_alloc(key.tun_opts_len, GFP_KERNEL);
+ tun_dst = metadata_dst_alloc(key.tun_opts_len, METADATA_IP_TUNNEL,
+ GFP_KERNEL);
+
if (!tun_dst)
return -ENOMEM;
--
2.5.5
^ permalink raw reply related
* [next-queue v3 PATCH 7/7] i40e: Add support to get switch id and port number for VFPR netdevs
From: Sridhar Samudrala @ 2017-01-10 0:59 UTC (permalink / raw)
To: alexander.h.duyck, john.r.fastabend, anjali.singhai,
jakub.kicinski, davem, scott.d.peterson, gerlitz.or, jiri,
intel-wired-lan, netdev
In-Reply-To: <1484009990-3018-1-git-send-email-sridhar.samudrala@intel.com>
Introduce switchdev_ops to PF and VFPR netdevs to return the switch id
via SWITCHDEV_ATTR_ID_PORT_PARENT_ID attribute.
Also, ndo_get_phys_port_name() support is added to VFPR netdevs to
return the port number.
PF: enp5s0f0, VFs: enp5s2,enp5s2f1 VFPRs:enp5s0f0-vf0, enp5s0f0-vf1
# rmmod i40e; modprobe i40e
# devlink dev eswitch set pci/0000:05:00.0 mode switchdev
# echo 2 > /sys/class/net/enp5s0f0/device/sriov_numvfs
# ip -d l show enp5s0f0
32: enp5s0f0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether 68:05:ca:2e:72:68 brd ff:ff:ff:ff:ff:ff promiscuity 0 addrgenmode eui64 numtxqueues 72 numrxqueues 72 gso_max_size 65536 gso_max_segs 65535 portid 6805ca2e7268 switchid 6805ca2e7268
vf 0 MAC 00:00:00:00:00:00, spoof checking on, link-state disable, trust off
vf 1 MAC 00:00:00:00:00:00, spoof checking on, link-state disable, trust off
# ip -d l show enp5s0f0-vf0
34: enp5s0f0-vf0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether 68:05:ca:2e:72:68 brd ff:ff:ff:ff:ff:ff promiscuity 0 addrgenmode eui64 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 portname 0 switchid 6805ca2e7268
# ip -d l show enp5s0f0-vf1
35: enp5s0f0-vf1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether 68:05:ca:2e:72:68 brd ff:ff:ff:ff:ff:ff promiscuity 0 addrgenmode eui64 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 portname 1 switchid 6805ca2e7268
Signed-off-by: Sridhar Samudrala <sridhar.samudrala@intel.com>
---
drivers/net/ethernet/intel/i40e/i40e.h | 1 +
drivers/net/ethernet/intel/i40e/i40e_main.c | 28 +++++++++++++++
drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c | 40 ++++++++++++++++++++++
3 files changed, 69 insertions(+)
diff --git a/drivers/net/ethernet/intel/i40e/i40e.h b/drivers/net/ethernet/intel/i40e/i40e.h
index d038bc1..09346a5 100644
--- a/drivers/net/ethernet/intel/i40e/i40e.h
+++ b/drivers/net/ethernet/intel/i40e/i40e.h
@@ -56,6 +56,7 @@
#include <linux/ptp_clock_kernel.h>
#include <net/devlink.h>
#include <net/dst_metadata.h>
+#include <net/switchdev.h>
#include "i40e_type.h"
#include "i40e_prototype.h"
diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c
index ac324e2..bb41fdc 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@ -9656,6 +9656,31 @@ static const struct net_device_ops i40e_netdev_ops = {
.ndo_xdp = i40e_xdp,
};
+static int i40e_pf_attr_get(struct net_device *dev, struct switchdev_attr *attr)
+{
+ struct i40e_netdev_priv *np = netdev_priv(dev);
+ struct i40e_vsi *vsi = np->vsi;
+ struct i40e_pf *pf = vsi->back;
+
+ if (pf->eswitch_mode == DEVLINK_ESWITCH_MODE_LEGACY)
+ return -EOPNOTSUPP;
+
+ switch (attr->id) {
+ case SWITCHDEV_ATTR_ID_PORT_PARENT_ID:
+ attr->u.ppid.id_len = ETH_ALEN;
+ ether_addr_copy(attr->u.ppid.id, dev->dev_addr);
+ break;
+ default:
+ return -EOPNOTSUPP;
+ }
+
+ return 0;
+}
+
+static const struct switchdev_ops i40e_pf_switchdev_ops = {
+ .switchdev_port_attr_get = i40e_pf_attr_get,
+};
+
/**
* i40e_config_netdev - Setup the netdev flags
* @vsi: the VSI being configured
@@ -9775,6 +9800,9 @@ static int i40e_config_netdev(struct i40e_vsi *vsi)
#ifdef I40E_FCOE
i40e_fcoe_config_netdev(netdev, vsi);
#endif
+#ifdef CONFIG_NET_SWITCHDEV
+ netdev->switchdev_ops = &i40e_pf_switchdev_ops;
+#endif
/* MTU range: 68 - 9706 */
netdev->min_mtu = ETH_MIN_MTU;
diff --git a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
index 5915280..2f84d70 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
@@ -1156,6 +1156,22 @@ i40e_vfpr_netdev_get_offload_stats(int attr_id, const struct net_device *dev,
return -EINVAL;
}
+static int
+i40e_vfpr_netdev_get_phys_port_name(struct net_device *dev, char *buf,
+ size_t len)
+{
+ struct i40e_vfpr_netdev_priv *priv = netdev_priv(dev);
+ struct i40e_vf *vf = priv->vf;
+
+ int ret;
+
+ ret = snprintf(buf, len, "%d", vf->vf_id);
+ if (ret >= len)
+ return -EOPNOTSUPP;
+
+ return 0;
+}
+
static const struct net_device_ops i40e_vfpr_netdev_ops = {
.ndo_open = i40e_vfpr_netdev_open,
.ndo_stop = i40e_vfpr_netdev_stop,
@@ -1163,6 +1179,26 @@ static const struct net_device_ops i40e_vfpr_netdev_ops = {
.ndo_get_stats64 = i40e_vfpr_netdev_get_stats64,
.ndo_has_offload_stats = i40e_vfpr_netdev_has_offload_stats,
.ndo_get_offload_stats = i40e_vfpr_netdev_get_offload_stats,
+ .ndo_get_phys_port_name = i40e_vfpr_netdev_get_phys_port_name,
+};
+
+static int i40e_vfpr_attr_get(struct net_device *dev,
+ struct switchdev_attr *attr)
+{
+ switch (attr->id) {
+ case SWITCHDEV_ATTR_ID_PORT_PARENT_ID:
+ attr->u.ppid.id_len = ETH_ALEN;
+ ether_addr_copy(attr->u.ppid.id, dev->dev_addr);
+ break;
+ default:
+ return -EOPNOTSUPP;
+ }
+
+ return 0;
+}
+
+static const struct switchdev_ops i40e_vfpr_switchdev_ops = {
+ .switchdev_port_attr_get = i40e_vfpr_attr_get,
};
/**
@@ -1237,6 +1273,10 @@ int i40e_alloc_vfpr_netdev(struct i40e_vf *vf, u16 vf_num)
vfpr_netdev->netdev_ops = &i40e_vfpr_netdev_ops;
eth_hw_addr_inherit(vfpr_netdev, vsi->netdev);
+#ifdef CONFIG_NET_SWITCHDEV
+ vfpr_netdev->switchdev_ops = &i40e_vfpr_switchdev_ops;
+#endif
+
netif_carrier_off(vfpr_netdev);
netif_tx_disable(vfpr_netdev);
--
2.5.5
^ permalink raw reply related
* linux-next: build failure after merge of the selinux tree
From: Stephen Rothwell @ 2017-01-10 1:27 UTC (permalink / raw)
To: Paul Moore, David Miller, Networking
Cc: linux-next, linux-kernel, Ursula Braun, Stephen Smalley
Hi Paul,
After merging the selinux tree, today's linux-next build (x86_64
allmodconfig) failed like this:
In file included from /home/sfr/next/next/security/selinux/avc.c:35:0:
/home/sfr/next/next/security/selinux/include/classmap.h:242:2: error: #error New address family defined, please update secclass_map.
#error New address family defined, please update secclass_map.
^
/home/sfr/next/next/security/selinux/hooks.c: In function 'socket_type_to_security_class':
/home/sfr/next/next/security/selinux/hooks.c:1409:2: error: #error New address family defined, please update this function.
Caused by commit
da69a5306ab9 ("selinux: support distinctions among all network address families")
interacting with commit
ac7138746e14 ("smc: establish new socket family")
from the net-next tree.
I added the following merge fix patch:
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 10 Jan 2017 12:22:21 +1100
Subject: [PATCH] selinux: merge fix for "smc: establish new socket family"
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
security/selinux/hooks.c | 4 +++-
security/selinux/include/classmap.h | 4 +++-
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index bada3cd42b9c..712fd0e7c91d 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -1405,7 +1405,9 @@ static inline u16 socket_type_to_security_class(int family, int type, int protoc
return SECCLASS_KCM_SOCKET;
case PF_QIPCRTR:
return SECCLASS_QIPCRTR_SOCKET;
-#if PF_MAX > 43
+ case PF_SMC:
+ return SECCLASS_SMC_SOCKET;
+#if PF_MAX > 44
#error New address family defined, please update this function.
#endif
}
diff --git a/security/selinux/include/classmap.h b/security/selinux/include/classmap.h
index 0dfd26d0b8d8..40f1d4f8bc2a 100644
--- a/security/selinux/include/classmap.h
+++ b/security/selinux/include/classmap.h
@@ -235,9 +235,11 @@ struct security_class_mapping secclass_map[] = {
{ COMMON_SOCK_PERMS, NULL } },
{ "qipcrtr_socket",
{ COMMON_SOCK_PERMS, NULL } },
+ { "smc_socket",
+ { COMMON_SOCK_PERMS, NULL } },
{ NULL }
};
-#if PF_MAX > 43
+#if PF_MAX > 44
#error New address family defined, please update secclass_map.
#endif
--
2.10.2
--
Cheers,
Stephen Rothwell
^ permalink raw reply related
* RE: Marvell Phy (1510) issue since v4.7 kernel
From: Kwok, WingMan @ 2017-01-10 1:37 UTC (permalink / raw)
To: Andrew Lunn; +Cc: Karicheri, Muralidharan, netdev@vger.kernel.org
In-Reply-To: <20170109235534.GH22820@lunn.ch>
> -----Original Message-----
> From: Andrew Lunn [mailto:andrew@lunn.ch]
> Sent: Monday, January 09, 2017 6:56 PM
> To: Kwok, WingMan
> Cc: Karicheri, Muralidharan; netdev@vger.kernel.org
> Subject: Re: Marvell Phy (1510) issue since v4.7 kernel
>
> > But when kernel is reboot into u-boot, "mii read 0 0" shows
> > 0x1000, ie. bit 11 is 0, and still the phy auto-nego times out.
>
> O.K, not so simple then.
>
> I suggest you dump all the registers, in both the good and bad state,
> and see how they differ.
>
> Andrew
From Marvell's brief description http://www.marvell.com/transceivers/alaska-gbe/,
it seems that 88E1510/1518 don't support fiber. Only 88E1512 does. In
that case, the fiber support patch is not applicable to 88E1510/1518.
I investigate a little more of the u-boot auto-nego time out
problem after reboot and found that the problem is caused by
marvell_read_status() which leaves the fiber page out because the
phydev->link is TRUE. But if fiber is not applicable to 88E1510/1518,
this is an invalid check.
Any suggestion?
WingMan
^ permalink raw reply
* Re: Marvell Phy (1510) issue since v4.7 kernel
From: Andrew Lunn @ 2017-01-10 1:53 UTC (permalink / raw)
To: Kwok, WingMan; +Cc: Karicheri, Muralidharan, netdev@vger.kernel.org
In-Reply-To: <230CBA6E4B6B6B418E8730AC28E6FC7E153545C9@DFLE11.ent.ti.com>
> From Marvell's brief description http://www.marvell.com/transceivers/alaska-gbe/,
> it seems that 88E1510/1518 don't support fiber. Only 88E1512 does. In
> that case, the fiber support patch is not applicable to 88E1510/1518.
O.K. That makes it easier.
Please add the relevant IDs to include/linux/marvell.h, and add
entries to driver/net/phy/marvell.c for 1512 with SUPPORTED_FIBRE and
1510 and 1518 without.
Andrew
^ permalink raw reply
* Re: [PATCH net-next] net: ipv6: put autoconf routes into per-interface tables
From: Lorenzo Colitti @ 2017-01-10 2:01 UTC (permalink / raw)
To: David Ahern
Cc: netdev@vger.kernel.org, Maciej Żenczykowski,
Hannes Frederic Sowa, Erik Kline, YOSHIFUJI Hideaki, David Miller,
Daniel Rosenberg
In-Reply-To: <37df3b18-d17b-5875-7b44-db40be7b459c@cumulusnetworks.com>
On Sun, Jan 8, 2017 at 1:24 PM, David Ahern <dsa@cumulusnetworks.com> wrote:
> Why not use the VRF capability then? create a VRF and assign the interface to it. End result is the same -- separate tables and the need to use a bind-to-device API to hit those routes.
Requiring that VRFs for this creates additional complexity, because
each network now requires its own VRF. That means that the connection
manager must create the VRF before the interface comes up and receives
the RA.
In some cases this might not be possible. For example, consider a tun
interface that's created by a different process such as a VPN client.
In this case the connection manager doesn't know the interface name,
and the VPN client doesn't know to create the VRF, so if the tun
interface gets an RA after the tun is created but
As others have mentioned, IPv6 on VRFs in client mode is also not
necessarily well-supported at the moment, and I don't know how long it
would take for it to be (assuming it can be made to work properly in
client mode without breaking the primary use cases for VRFs).
^ permalink raw reply
* Re: [PATCH net-next] net: ipv6: put autoconf routes into per-interface tables
From: David Ahern @ 2017-01-10 2:08 UTC (permalink / raw)
To: Lorenzo Colitti
Cc: netdev@vger.kernel.org, Maciej Żenczykowski,
Hannes Frederic Sowa, Erik Kline, YOSHIFUJI Hideaki, David Miller,
Daniel Rosenberg
In-Reply-To: <CAKD1Yr2U2Oh5yvHE7Znfc9mHzM4K6B_kU82Qctpcsmnt3y5GdQ@mail.gmail.com>
On 1/9/17 7:01 PM, Lorenzo Colitti wrote:
> As others have mentioned, IPv6 on VRFs in client mode is also not
> necessarily well-supported at the moment, and I don't know how long it
> would take for it to be (assuming it can be made to work properly in
> client mode without breaking the primary use cases for VRFs).
That's news to me. What about IPv6 and VRF is not working or well-supported?
^ permalink raw reply
* Re: [PATCH V4 net-next 1/3] vhost: better detection of available buffers
From: Jason Wang @ 2017-01-10 2:22 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: kvm, netdev, virtualization, wexu, stefanha
In-Reply-To: <20170110010957-mutt-send-email-mst@kernel.org>
On 2017年01月10日 07:10, Michael S. Tsirkin wrote:
> On Mon, Jan 09, 2017 at 10:59:16AM +0800, Jason Wang wrote:
>>
>> On 2017年01月07日 03:55, Michael S. Tsirkin wrote:
>>> On Fri, Jan 06, 2017 at 10:13:15AM +0800, Jason Wang wrote:
>>>> This patch tries to do several tweaks on vhost_vq_avail_empty() for a
>>>> better performance:
>>>>
>>>> - check cached avail index first which could avoid userspace memory access.
>>>> - using unlikely() for the failure of userspace access
>>>> - check vq->last_avail_idx instead of cached avail index as the last
>>>> step.
>>>>
>>>> This patch is need for batching supports which needs to peek whether
>>>> or not there's still available buffers in the ring.
>>>>
>>>> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
>>>> Signed-off-by: Jason Wang <jasowang@redhat.com>
>>>> ---
>>>> drivers/vhost/vhost.c | 8 ++++++--
>>>> 1 file changed, 6 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
>>>> index d643260..9f11838 100644
>>>> --- a/drivers/vhost/vhost.c
>>>> +++ b/drivers/vhost/vhost.c
>>>> @@ -2241,11 +2241,15 @@ bool vhost_vq_avail_empty(struct vhost_dev *dev, struct vhost_virtqueue *vq)
>>>> __virtio16 avail_idx;
>>>> int r;
>>>> + if (vq->avail_idx != vq->last_avail_idx)
>>>> + return false;
>>>> +
>>>> r = vhost_get_user(vq, avail_idx, &vq->avail->idx);
>>>> - if (r)
>>>> + if (unlikely(r))
>>>> return false;
>>>> + vq->avail_idx = vhost16_to_cpu(vq, avail_idx);
>>>> - return vhost16_to_cpu(vq, avail_idx) == vq->avail_idx;
>>>> + return vq->avail_idx == vq->last_avail_idx;
>>>> }
>>>> EXPORT_SYMBOL_GPL(vhost_vq_avail_empty);
>>> So again, this did not address the issue I pointed out in v1:
>>> if we have 1 buffer in RX queue and
>>> that is not enough to store the whole packet,
>>> vhost_vq_avail_empty returns false, then we re-read
>>> the descriptors again and again.
>>>
>>> You have saved a single index access but not the more expensive
>>> descriptor access.
>> Looks not, if I understand the code correctly, in this case, get_rx_bufs()
>> will return zero, and we will try to enable rx kick and exit the loop.
>>
>> Thanks
> I mean this:
>
> while (vhost_can_busy_poll(vq->dev, endtime) &&
> vhost_vq_avail_empty(vq->dev, vq))
> cpu_relax();
> preempt_enable();
> r = vhost_get_vq_desc(vq, vq->iov, ARRAY_SIZE(vq->iov),
> out_num, in_num, NULL, NULL);
>
>
> vhost_vq_avail_empty returns false so we break out of the loop
> and call vhost_get_vq_desc.
>
>
But this is the code for polling tx vq not rx I think?
Thanks
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [PATCH V4 net-next 3/3] tun: rx batching
From: Jason Wang @ 2017-01-10 2:24 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: kvm, netdev, virtualization, wexu, stefanha
In-Reply-To: <20170110011058-mutt-send-email-mst@kernel.org>
On 2017年01月10日 07:12, Michael S. Tsirkin wrote:
> On Mon, Jan 09, 2017 at 10:39:55AM +0800, Jason Wang wrote:
>> On 2017年01月07日 03:47, Michael S. Tsirkin wrote:
>>>> +static int tun_get_coalesce(struct net_device *dev,
>>>> + struct ethtool_coalesce *ec)
>>>> +{
>>>> + struct tun_struct *tun = netdev_priv(dev);
>>>> +
>>>> + ec->rx_max_coalesced_frames = tun->rx_batched;
>>>> +
>>>> + return 0;
>>>> +}
>>>> +
>>>> +static int tun_set_coalesce(struct net_device *dev,
>>>> + struct ethtool_coalesce *ec)
>>>> +{
>>>> + struct tun_struct *tun = netdev_priv(dev);
>>>> +
>>>> + if (ec->rx_max_coalesced_frames > NAPI_POLL_WEIGHT)
>>>> + return -EINVAL;
>>> So what should userspace do? Keep trying until it succeeds?
>>> I think it's better to just use NAPI_POLL_WEIGHT instead and DTRT here.
>>>
>> Well, looking at how set_coalesce is implemented in other drivers, -EINVAL
>> is usually used when user give a value that exceeds the limitation. For
>> tuntap, what missed here is probably just a documentation for coalescing in
>> tuntap.txt. (Or extend ethtool to return the max value). This seems much
>> better than silently reduce the value to the limitation.
>>
>> Thanks
> I don't think it's better, it's mostly that
> 1. there's a hardware limit so it does not change much
> 2. default is enabled and no one bothers changing
>
> I don't see how will tuntap.txt help if we want to change it
> in the future.
Ok, so I will limit it to NAPI_POLL_WEIGHT if user gives a value that is
greater than that.
Thanks
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [net PATCH] net: virtio: cap mtu when XDP programs are running
From: Jason Wang @ 2017-01-10 2:29 UTC (permalink / raw)
To: Michael S. Tsirkin, John Fastabend
Cc: john.r.fastabend, netdev, alexei.starovoitov, daniel
In-Reply-To: <20170110015759-mutt-send-email-mst@kernel.org>
On 2017年01月10日 07:58, Michael S. Tsirkin wrote:
> On Mon, Jan 09, 2017 at 03:49:27PM -0800, John Fastabend wrote:
>> On 17-01-09 03:24 PM, Michael S. Tsirkin wrote:
>>> On Mon, Jan 09, 2017 at 03:13:15PM -0800, John Fastabend wrote:
>>>> On 17-01-09 03:05 PM, Michael S. Tsirkin wrote:
>>>>> On Thu, Jan 05, 2017 at 11:09:14AM +0800, Jason Wang wrote:
>>>>>> On 2017年01月05日 02:57, John Fastabend wrote:
>>>>>>> [...]
>>>>>>>
>>>>>>>> On 2017年01月04日 00:48, John Fastabend wrote:
>>>>>>>>> On 17-01-02 10:14 PM, Jason Wang wrote:
>>>>>>>>>> On 2017年01月03日 06:30, John Fastabend wrote:
>>>>>>>>>>> XDP programs can not consume multiple pages so we cap the MTU to
>>>>>>>>>>> avoid this case. Virtio-net however only checks the MTU at XDP
>>>>>>>>>>> program load and does not block MTU changes after the program
>>>>>>>>>>> has loaded.
>>>>>>>>>>>
>>>>>>>>>>> This patch sets/clears the max_mtu value at XDP load/unload time.
>>>>>>>>>>>
>>>>>>>>>>> Signed-off-by: John Fastabend<john.r.fastabend@intel.com>
>>>>>>>>>>> ---
>>>>>>> [...]
>>>>>>>
>>>>>>>>> OK so this logic is a bit too simply. When it resets the max_mtu I guess it
>>>>>>>>> needs to read the mtu via
>>>>>>>>>
>>>>>>>>> virtio_cread16(vdev, ...)
>>>>>>>>>
>>>>>>>>> or we may break the negotiated mtu.
>>>>>>>> Yes, this is a problem (even use ETH_MAX_MTU). We may need a method to notify
>>>>>>>> the device about the mtu in this case which is not supported by virtio now.
>>>>>>> Note this is not really a XDP specific problem. The guest can change the MTU
>>>>>>> after init time even without XDP which I assume should ideally result in a
>>>>>>> notification if the MTU is negotiated.
>>>>>> Yes, Michael, do you think we need add some mechanism to notify host about
>>>>>> MTU change in this case?
>>>>>>
>>>>>> Thanks
>>>>> Why does host care?
>>>>>
>>>> Well the guest will drop packets after mtu has been reduced.
>>> I didn't know. What place in code does this?
>>>
>> hmm in many of the drivers it is convention to use the mtu to set the rx
>> buffer sizes and a receive side max length filter. For example in the Intel
>> drivers if a packet with length greater than MTU + some headroom is received we
>> drop it. I guess in the networking stack RX path though nothing forces this and
>> virtio doesn't have any code to drop packets on rx size.
>>
>> In virtio I don't see any existing case currently. In the XDP case though we
>> need to ensure packets fit in a page for the time being which is why I was
>> looking at this code and generated this patch.
> I'd say just look at the hardware max mtu. Ignore the configured mtu.
>
>
Does this work for small buffers consider it always allocate skb with
size of GOOD_PACKET_LEN? I think in any case, we should limit max_mtu to
GOOD_PACKET_LEN for small buffers.
Thanks
^ permalink raw reply
* Re: [PATCH net-next] net: ipv6: put autoconf routes into per-interface tables
From: Lorenzo Colitti @ 2017-01-10 2:29 UTC (permalink / raw)
To: David Ahern
Cc: netdev@vger.kernel.org, Maciej Żenczykowski,
Hannes Frederic Sowa, Erik Kline, YOSHIFUJI Hideaki, David Miller,
Daniel Rosenberg, temnota.am
In-Reply-To: <e282793e-4057-7fe6-8322-e1899d873ae2@cumulusnetworks.com>
On Tue, Jan 10, 2017 at 11:08 AM, David Ahern <dsa@cumulusnetworks.com> wrote:
> That's news to me. What about IPv6 and VRF is not working or well-supported?
I have no firsthand experience of this myself, but if the problems
that Andrey reports above in this thread are real, then those would
indicate that the code is not well-supported. Being unable to accept
DAD is a pretty serious issue. Andrey, what version of the kernel did
you see this on?
^ permalink raw reply
* Re: [PATCH] vhost: scsi: constify target_core_fabric_ops structures
From: Jason Wang @ 2017-01-10 2:50 UTC (permalink / raw)
To: Bhumika Goyal, julia.lawall, mst, kvm, virtualization, netdev,
linux-kernel
In-Reply-To: <1483975262-1260-1-git-send-email-bhumirks@gmail.com>
On 2017年01月09日 23:21, Bhumika Goyal wrote:
> Declare target_core_fabric_ops strucrues as const as they are only
> passed as an argument to the functions target_register_template and
> target_unregister_template. The arguments are of type const struct
> target_core_fabric_ops *, so target_core_fabric_ops structures having
> this property can be declared const.
> Done using Coccinelle:
>
> @r disable optional_qualifier@
> identifier i;
> position p;
> @@
> static struct target_core_fabric_ops i@p={...};
>
> @ok@
> position p;
> identifier r.i;
> @@
> (
> target_register_template(&i@p)
> |
> target_unregister_template(&i@p)
> )
> @bad@
> position p!={r.p,ok.p};
> identifier r.i;
> @@
> i@p
>
> @depends on !bad disable optional_qualifier@
> identifier r.i;
> @@
> +const
> struct target_core_fabric_ops i;
>
> File size before: drivers/vhost/scsi.o
> text data bss dec hex filename
> 18063 2985 40 21088 5260 drivers/vhost/scsi.o
>
> File size after: drivers/vhost/scsi.o
> text data bss dec hex filename
> 18479 2601 40 21120 5280 drivers/vhost/scsi.o
>
> Signed-off-by: Bhumika Goyal <bhumirks@gmail.com>
> ---
> drivers/vhost/scsi.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/vhost/scsi.c b/drivers/vhost/scsi.c
> index 253310c..620366d 100644
> --- a/drivers/vhost/scsi.c
> +++ b/drivers/vhost/scsi.c
> @@ -2087,7 +2087,7 @@ static void vhost_scsi_drop_tport(struct se_wwn *wwn)
> NULL,
> };
>
> -static struct target_core_fabric_ops vhost_scsi_ops = {
> +static const struct target_core_fabric_ops vhost_scsi_ops = {
> .module = THIS_MODULE,
> .name = "vhost",
> .get_fabric_name = vhost_scsi_get_fabric_name,
Acked-by: Jason Wang <jasowang@redhat.com>
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [net PATCH] net: virtio: cap mtu when XDP programs are running
From: Michael S. Tsirkin @ 2017-01-10 2:51 UTC (permalink / raw)
To: Jason Wang
Cc: John Fastabend, john.r.fastabend, netdev, alexei.starovoitov,
daniel
In-Reply-To: <9102bb4b-223a-d441-7546-8b4144d970fb@redhat.com>
On Tue, Jan 10, 2017 at 10:29:39AM +0800, Jason Wang wrote:
>
>
> On 2017年01月10日 07:58, Michael S. Tsirkin wrote:
> > On Mon, Jan 09, 2017 at 03:49:27PM -0800, John Fastabend wrote:
> > > On 17-01-09 03:24 PM, Michael S. Tsirkin wrote:
> > > > On Mon, Jan 09, 2017 at 03:13:15PM -0800, John Fastabend wrote:
> > > > > On 17-01-09 03:05 PM, Michael S. Tsirkin wrote:
> > > > > > On Thu, Jan 05, 2017 at 11:09:14AM +0800, Jason Wang wrote:
> > > > > > > On 2017年01月05日 02:57, John Fastabend wrote:
> > > > > > > > [...]
> > > > > > > >
> > > > > > > > > On 2017年01月04日 00:48, John Fastabend wrote:
> > > > > > > > > > On 17-01-02 10:14 PM, Jason Wang wrote:
> > > > > > > > > > > On 2017年01月03日 06:30, John Fastabend wrote:
> > > > > > > > > > > > XDP programs can not consume multiple pages so we cap the MTU to
> > > > > > > > > > > > avoid this case. Virtio-net however only checks the MTU at XDP
> > > > > > > > > > > > program load and does not block MTU changes after the program
> > > > > > > > > > > > has loaded.
> > > > > > > > > > > >
> > > > > > > > > > > > This patch sets/clears the max_mtu value at XDP load/unload time.
> > > > > > > > > > > >
> > > > > > > > > > > > Signed-off-by: John Fastabend<john.r.fastabend@intel.com>
> > > > > > > > > > > > ---
> > > > > > > > [...]
> > > > > > > >
> > > > > > > > > > OK so this logic is a bit too simply. When it resets the max_mtu I guess it
> > > > > > > > > > needs to read the mtu via
> > > > > > > > > >
> > > > > > > > > > virtio_cread16(vdev, ...)
> > > > > > > > > >
> > > > > > > > > > or we may break the negotiated mtu.
> > > > > > > > > Yes, this is a problem (even use ETH_MAX_MTU). We may need a method to notify
> > > > > > > > > the device about the mtu in this case which is not supported by virtio now.
> > > > > > > > Note this is not really a XDP specific problem. The guest can change the MTU
> > > > > > > > after init time even without XDP which I assume should ideally result in a
> > > > > > > > notification if the MTU is negotiated.
> > > > > > > Yes, Michael, do you think we need add some mechanism to notify host about
> > > > > > > MTU change in this case?
> > > > > > >
> > > > > > > Thanks
> > > > > > Why does host care?
> > > > > >
> > > > > Well the guest will drop packets after mtu has been reduced.
> > > > I didn't know. What place in code does this?
> > > >
> > > hmm in many of the drivers it is convention to use the mtu to set the rx
> > > buffer sizes and a receive side max length filter. For example in the Intel
> > > drivers if a packet with length greater than MTU + some headroom is received we
> > > drop it. I guess in the networking stack RX path though nothing forces this and
> > > virtio doesn't have any code to drop packets on rx size.
> > >
> > > In virtio I don't see any existing case currently. In the XDP case though we
> > > need to ensure packets fit in a page for the time being which is why I was
> > > looking at this code and generated this patch.
> > I'd say just look at the hardware max mtu. Ignore the configured mtu.
> >
> >
>
> Does this work for small buffers consider it always allocate skb with size
> of GOOD_PACKET_LEN?
Spec says hardware won't send in packets > max mtu in config space.
> I think in any case, we should limit max_mtu to
> GOOD_PACKET_LEN for small buffers.
>
> Thanks
XDP seems to have a bunch of weird restrictions, I just
do not like it that the logic spills out to all drivers.
What if someone decides to extend it to two pages in the future?
Recode it all in all drivers ...
Why can't net core enforce mtu?
--
MST
^ permalink raw reply
* linux-next: manual merge of the y2038 tree with the net-next tree
From: Stephen Rothwell @ 2017-01-10 2:52 UTC (permalink / raw)
To: Arnd Bergmann, David Miller, Networking
Cc: linux-next, linux-kernel, David Howells, Tina Ruchandani
Hi Arnd,
Today's linux-next merge of the y2038 tree got a conflict in:
fs/afs/main.c
between commit:
8e8d7f13b6d5 ("afs: Add some tracepoints")
from the net-next tree and commit:
549eb7b22e24 ("AFS: Correctly use 64-bit time for UUID")
from the y2038 tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc fs/afs/main.c
index f8188feb03ad,129ff432391c..000000000000
--- a/fs/afs/main.c
+++ b/fs/afs/main.c
@@@ -14,8 -14,7 +14,9 @@@
#include <linux/init.h>
#include <linux/completion.h>
#include <linux/sched.h>
+#include <linux/random.h>
+#define CREATE_TRACE_POINTS
+ #include <linux/ktime.h>
#include "internal.h"
MODULE_DESCRIPTION("AFS Client File System");
^ permalink raw reply
* [PATCH] net: ethernet: aquantia: fix semicolon.cocci warnings
From: kbuild test robot @ 2017-01-10 2:52 UTC (permalink / raw)
To: Alexander Loktionov
Cc: kbuild-all, netdev, David VomLehn, Simon Edelhaus,
Alexander Loktionov, Dmitrii Tarakanov, Pavel Belous
In-Reply-To: <66066b129bfac133b682dd4e4832004edf6615a0.1483999588.git.vomlehn@texas.net>
drivers/net/ethernet/aquantia/aq_nic.c:584:3-4: Unneeded semicolon
Remove unneeded semicolon.
Generated by: scripts/coccinelle/misc/semicolon.cocci
CC: David VomLehn <vomlehn@texas.net>
Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
---
aq_nic.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/ethernet/aquantia/aq_nic.c
+++ b/drivers/net/ethernet/aquantia/aq_nic.c
@@ -581,7 +581,7 @@ __acquires(&ring->lock)
aq_nic_ndev_queue_stop(self, ring->idx);
}
spin_unlock(&ring->lock);
- };
+ }
} while (--trys && !is_locked);
if (!is_locked)
^ permalink raw reply
* Re: [PATCH v2 13/13] net: ethernet: aquantia: Integrate AQtion 2.5/5 GB NIC driver
From: kbuild test robot @ 2017-01-10 2:52 UTC (permalink / raw)
To: Alexander Loktionov
Cc: kbuild-all, netdev, David VomLehn, Simon Edelhaus,
Alexander Loktionov, Dmitrii Tarakanov, Pavel Belous
In-Reply-To: <66066b129bfac133b682dd4e4832004edf6615a0.1483999588.git.vomlehn@texas.net>
[-- Attachment #1: Type: text/plain, Size: 980 bytes --]
Hi David,
[auto build test ERROR on net-next/master]
[also build test ERROR on v4.10-rc3 next-20170106]
[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/Alexander-Loktionov/net-ethernet-aquantia-Add-AQtion-2-5-5-GB-NIC-driver/20170110-084036
config: i386-allmodconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
>> ERROR: "__udivdi3" [drivers/net/ethernet/aquantia/atlantic.ko] undefined!
coccinelle warnings: (new ones prefixed by >>)
>> drivers/net/ethernet/aquantia/aq_nic.c:584:3-4: Unneeded semicolon
Please review and possibly fold the followup patch.
---
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: 57957 bytes --]
^ permalink raw reply
* Re: [PATCH V4 net-next 1/3] vhost: better detection of available buffers
From: Michael S. Tsirkin @ 2017-01-10 2:57 UTC (permalink / raw)
To: Jason Wang; +Cc: virtualization, netdev, kvm, stephen, wexu, stefanha
In-Reply-To: <5eb3b349-bbae-6438-d8ea-7df82a7babb4@redhat.com>
On Tue, Jan 10, 2017 at 10:22:42AM +0800, Jason Wang wrote:
>
>
> On 2017年01月10日 07:10, Michael S. Tsirkin wrote:
> > On Mon, Jan 09, 2017 at 10:59:16AM +0800, Jason Wang wrote:
> > >
> > > On 2017年01月07日 03:55, Michael S. Tsirkin wrote:
> > > > On Fri, Jan 06, 2017 at 10:13:15AM +0800, Jason Wang wrote:
> > > > > This patch tries to do several tweaks on vhost_vq_avail_empty() for a
> > > > > better performance:
> > > > >
> > > > > - check cached avail index first which could avoid userspace memory access.
> > > > > - using unlikely() for the failure of userspace access
> > > > > - check vq->last_avail_idx instead of cached avail index as the last
> > > > > step.
> > > > >
> > > > > This patch is need for batching supports which needs to peek whether
> > > > > or not there's still available buffers in the ring.
> > > > >
> > > > > Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
> > > > > Signed-off-by: Jason Wang <jasowang@redhat.com>
> > > > > ---
> > > > > drivers/vhost/vhost.c | 8 ++++++--
> > > > > 1 file changed, 6 insertions(+), 2 deletions(-)
> > > > >
> > > > > diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
> > > > > index d643260..9f11838 100644
> > > > > --- a/drivers/vhost/vhost.c
> > > > > +++ b/drivers/vhost/vhost.c
> > > > > @@ -2241,11 +2241,15 @@ bool vhost_vq_avail_empty(struct vhost_dev *dev, struct vhost_virtqueue *vq)
> > > > > __virtio16 avail_idx;
> > > > > int r;
> > > > > + if (vq->avail_idx != vq->last_avail_idx)
> > > > > + return false;
> > > > > +
> > > > > r = vhost_get_user(vq, avail_idx, &vq->avail->idx);
> > > > > - if (r)
> > > > > + if (unlikely(r))
> > > > > return false;
> > > > > + vq->avail_idx = vhost16_to_cpu(vq, avail_idx);
> > > > > - return vhost16_to_cpu(vq, avail_idx) == vq->avail_idx;
> > > > > + return vq->avail_idx == vq->last_avail_idx;
> > > > > }
> > > > > EXPORT_SYMBOL_GPL(vhost_vq_avail_empty);
> > > > So again, this did not address the issue I pointed out in v1:
> > > > if we have 1 buffer in RX queue and
> > > > that is not enough to store the whole packet,
> > > > vhost_vq_avail_empty returns false, then we re-read
> > > > the descriptors again and again.
> > > >
> > > > You have saved a single index access but not the more expensive
> > > > descriptor access.
> > > Looks not, if I understand the code correctly, in this case, get_rx_bufs()
> > > will return zero, and we will try to enable rx kick and exit the loop.
> > >
> > > Thanks
> > I mean this:
> >
> > while (vhost_can_busy_poll(vq->dev, endtime) &&
> > vhost_vq_avail_empty(vq->dev, vq))
> > cpu_relax();
> > preempt_enable();
> > r = vhost_get_vq_desc(vq, vq->iov, ARRAY_SIZE(vq->iov),
> > out_num, in_num, NULL, NULL);
> >
> >
> > vhost_vq_avail_empty returns false so we break out of the loop
> > and call vhost_get_vq_desc.
> >
> >
>
> But this is the code for polling tx vq not rx I think?
>
> Thanks
Oh, right.
I'll re-read this.
--
MST
^ permalink raw reply
* Re: [PATCH net-next] net: ipv6: put autoconf routes into per-interface tables
From: David Ahern @ 2017-01-10 3:04 UTC (permalink / raw)
To: Lorenzo Colitti
Cc: netdev@vger.kernel.org, Maciej Żenczykowski,
Hannes Frederic Sowa, Erik Kline, YOSHIFUJI Hideaki, David Miller,
Daniel Rosenberg, temnota.am
In-Reply-To: <CAKD1Yr21W2Ce6mhAqfz+mFUPTn+xn3K_Lz2q5LA27f6V=9tTSQ@mail.gmail.com>
On 1/9/17 7:29 PM, Lorenzo Colitti wrote:
> On Tue, Jan 10, 2017 at 11:08 AM, David Ahern <dsa@cumulusnetworks.com> wrote:
>> That's news to me. What about IPv6 and VRF is not working or well-supported?
>
> I have no firsthand experience of this myself, but if the problems
> that Andrey reports above in this thread are real, then those would
> indicate that the code is not well-supported. Being unable to accept
> DAD is a pretty serious issue. Andrey, what version of the kernel did
> you see this on?
>
Are you referencing an Android or google thread? This patch thread has not mentioned any IPv6 problems.
Just a day or so ago I did a dup address test on an interface in a vrf and it worked fine, but perhaps I missed something.
^ permalink raw reply
* Re: [net PATCH] net: virtio: cap mtu when XDP programs are running
From: John Fastabend @ 2017-01-10 3:30 UTC (permalink / raw)
To: Michael S. Tsirkin, Jason Wang
Cc: john.r.fastabend, netdev, alexei.starovoitov, daniel
In-Reply-To: <20170110044910-mutt-send-email-mst@kernel.org>
On 17-01-09 06:51 PM, Michael S. Tsirkin wrote:
> On Tue, Jan 10, 2017 at 10:29:39AM +0800, Jason Wang wrote:
>>
>>
>> On 2017年01月10日 07:58, Michael S. Tsirkin wrote:
>>> On Mon, Jan 09, 2017 at 03:49:27PM -0800, John Fastabend wrote:
>>>> On 17-01-09 03:24 PM, Michael S. Tsirkin wrote:
>>>>> On Mon, Jan 09, 2017 at 03:13:15PM -0800, John Fastabend wrote:
>>>>>> On 17-01-09 03:05 PM, Michael S. Tsirkin wrote:
>>>>>>> On Thu, Jan 05, 2017 at 11:09:14AM +0800, Jason Wang wrote:
>>>>>>>> On 2017年01月05日 02:57, John Fastabend wrote:
>>>>>>>>> [...]
>>>>>>>>>
>>>>>>>>>> On 2017年01月04日 00:48, John Fastabend wrote:
>>>>>>>>>>> On 17-01-02 10:14 PM, Jason Wang wrote:
>>>>>>>>>>>> On 2017年01月03日 06:30, John Fastabend wrote:
>>>>>>>>>>>>> XDP programs can not consume multiple pages so we cap the MTU to
>>>>>>>>>>>>> avoid this case. Virtio-net however only checks the MTU at XDP
>>>>>>>>>>>>> program load and does not block MTU changes after the program
>>>>>>>>>>>>> has loaded.
>>>>>>>>>>>>>
>>>>>>>>>>>>> This patch sets/clears the max_mtu value at XDP load/unload time.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Signed-off-by: John Fastabend<john.r.fastabend@intel.com>
>>>>>>>>>>>>> ---
>>>>>>>>> [...]
>>>>>>>>>
>>>>>>>>>>> OK so this logic is a bit too simply. When it resets the max_mtu I guess it
>>>>>>>>>>> needs to read the mtu via
>>>>>>>>>>>
>>>>>>>>>>> virtio_cread16(vdev, ...)
>>>>>>>>>>>
>>>>>>>>>>> or we may break the negotiated mtu.
>>>>>>>>>> Yes, this is a problem (even use ETH_MAX_MTU). We may need a method to notify
>>>>>>>>>> the device about the mtu in this case which is not supported by virtio now.
>>>>>>>>> Note this is not really a XDP specific problem. The guest can change the MTU
>>>>>>>>> after init time even without XDP which I assume should ideally result in a
>>>>>>>>> notification if the MTU is negotiated.
>>>>>>>> Yes, Michael, do you think we need add some mechanism to notify host about
>>>>>>>> MTU change in this case?
>>>>>>>>
>>>>>>>> Thanks
>>>>>>> Why does host care?
>>>>>>>
>>>>>> Well the guest will drop packets after mtu has been reduced.
>>>>> I didn't know. What place in code does this?
>>>>>
>>>> hmm in many of the drivers it is convention to use the mtu to set the rx
>>>> buffer sizes and a receive side max length filter. For example in the Intel
>>>> drivers if a packet with length greater than MTU + some headroom is received we
>>>> drop it. I guess in the networking stack RX path though nothing forces this and
>>>> virtio doesn't have any code to drop packets on rx size.
>>>>
>>>> In virtio I don't see any existing case currently. In the XDP case though we
>>>> need to ensure packets fit in a page for the time being which is why I was
>>>> looking at this code and generated this patch.
>>> I'd say just look at the hardware max mtu. Ignore the configured mtu.
>>>
>>>
>>
>> Does this work for small buffers consider it always allocate skb with size
>> of GOOD_PACKET_LEN?
>
> Spec says hardware won't send in packets > max mtu in config space.
>
>> I think in any case, we should limit max_mtu to
>> GOOD_PACKET_LEN for small buffers.
>>
>> Thanks
>
> XDP seems to have a bunch of weird restrictions, I just
> do not like it that the logic spills out to all drivers.
> What if someone decides to extend it to two pages in the future?
> Recode it all in all drivers ...
>
> Why can't net core enforce mtu?
>
OK I agree I'll put most the logic in rtnetlink.c when the program is added
or removed.
But, I'm looking at the non-XDP receive_small path now and wondering how does
multiple buffer receives work (e.g. packet larger than GOOD_PACKET_LEN?) I think
this is what Jason is looking at as well? The mergeable case clearly looks at
num_bufs in the descriptor to construct multi-buffer packets but nothing like
that exists in the small_receive path as best I can tell.
.John
^ permalink raw reply
* Re: [PATCH net-next] net: ipv6: put autoconf routes into per-interface tables
From: Lorenzo Colitti @ 2017-01-10 3:30 UTC (permalink / raw)
To: David Ahern
Cc: netdev@vger.kernel.org, Maciej Żenczykowski,
Hannes Frederic Sowa, Erik Kline, YOSHIFUJI Hideaki, David Miller,
Daniel Rosenberg, temnota.am
In-Reply-To: <161222cb-5c61-d016-bc0f-2453fb0408b7@cumulusnetworks.com>
On Tue, Jan 10, 2017 at 12:04 PM, David Ahern <dsa@cumulusnetworks.com> wrote:
> > I have no firsthand experience of this myself, but if the problems
> > that Andrey reports above in this thread are real, then those would
> > indicate that the code is not well-supported. Being unable to accept
> > DAD is a pretty serious issue. Andrey, what version of the kernel did
> > you see this on?
>
> Are you referencing an Android or google thread? This patch thread has not mentioned any IPv6 problems.
No, this thread. I see message-ID 8cddkd-etc.ln1@banana.localnet in
this thread. If you didn't get it, I also see it in the comments on
patchwork - https://patchwork.ozlabs.org/patch/711956/
^ permalink raw reply
* Re: [net PATCH] net: virtio: cap mtu when XDP programs are running
From: Jason Wang @ 2017-01-10 3:34 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: John Fastabend, john.r.fastabend, netdev, alexei.starovoitov,
daniel
In-Reply-To: <20170110044910-mutt-send-email-mst@kernel.org>
On 2017年01月10日 10:51, Michael S. Tsirkin wrote:
> On Tue, Jan 10, 2017 at 10:29:39AM +0800, Jason Wang wrote:
>>
>> On 2017年01月10日 07:58, Michael S. Tsirkin wrote:
>>> On Mon, Jan 09, 2017 at 03:49:27PM -0800, John Fastabend wrote:
>>>> On 17-01-09 03:24 PM, Michael S. Tsirkin wrote:
>>>>> On Mon, Jan 09, 2017 at 03:13:15PM -0800, John Fastabend wrote:
>>>>>> On 17-01-09 03:05 PM, Michael S. Tsirkin wrote:
>>>>>>> On Thu, Jan 05, 2017 at 11:09:14AM +0800, Jason Wang wrote:
>>>>>>>> On 2017年01月05日 02:57, John Fastabend wrote:
>>>>>>>>> [...]
>>>>>>>>>
>>>>>>>>>> On 2017年01月04日 00:48, John Fastabend wrote:
>>>>>>>>>>> On 17-01-02 10:14 PM, Jason Wang wrote:
>>>>>>>>>>>> On 2017年01月03日 06:30, John Fastabend wrote:
>>>>>>>>>>>>> XDP programs can not consume multiple pages so we cap the MTU to
>>>>>>>>>>>>> avoid this case. Virtio-net however only checks the MTU at XDP
>>>>>>>>>>>>> program load and does not block MTU changes after the program
>>>>>>>>>>>>> has loaded.
>>>>>>>>>>>>>
>>>>>>>>>>>>> This patch sets/clears the max_mtu value at XDP load/unload time.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Signed-off-by: John Fastabend<john.r.fastabend@intel.com>
>>>>>>>>>>>>> ---
>>>>>>>>> [...]
>>>>>>>>>
>>>>>>>>>>> OK so this logic is a bit too simply. When it resets the max_mtu I guess it
>>>>>>>>>>> needs to read the mtu via
>>>>>>>>>>>
>>>>>>>>>>> virtio_cread16(vdev, ...)
>>>>>>>>>>>
>>>>>>>>>>> or we may break the negotiated mtu.
>>>>>>>>>> Yes, this is a problem (even use ETH_MAX_MTU). We may need a method to notify
>>>>>>>>>> the device about the mtu in this case which is not supported by virtio now.
>>>>>>>>> Note this is not really a XDP specific problem. The guest can change the MTU
>>>>>>>>> after init time even without XDP which I assume should ideally result in a
>>>>>>>>> notification if the MTU is negotiated.
>>>>>>>> Yes, Michael, do you think we need add some mechanism to notify host about
>>>>>>>> MTU change in this case?
>>>>>>>>
>>>>>>>> Thanks
>>>>>>> Why does host care?
>>>>>>>
>>>>>> Well the guest will drop packets after mtu has been reduced.
>>>>> I didn't know. What place in code does this?
>>>>>
>>>> hmm in many of the drivers it is convention to use the mtu to set the rx
>>>> buffer sizes and a receive side max length filter. For example in the Intel
>>>> drivers if a packet with length greater than MTU + some headroom is received we
>>>> drop it. I guess in the networking stack RX path though nothing forces this and
>>>> virtio doesn't have any code to drop packets on rx size.
>>>>
>>>> In virtio I don't see any existing case currently. In the XDP case though we
>>>> need to ensure packets fit in a page for the time being which is why I was
>>>> looking at this code and generated this patch.
>>> I'd say just look at the hardware max mtu. Ignore the configured mtu.
>>>
>>>
>> Does this work for small buffers consider it always allocate skb with size
>> of GOOD_PACKET_LEN?
> Spec says hardware won't send in packets > max mtu in config space.
Yes, but if max mtu is greater than GOOD_PACKET_LEN, packet will be dropped.
>
>> I think in any case, we should limit max_mtu to
>> GOOD_PACKET_LEN for small buffers.
>>
>> Thanks
> XDP seems to have a bunch of weird restrictions, I just
> do not like it that the logic spills out to all drivers.
> What if someone decides to extend it to two pages in the future?
> Recode it all in all drivers ...
>
> Why can't net core enforce mtu?
>
Not sure it's a good idea to change mtu silently without notifying user.
Thanks
^ permalink raw reply
* Re: [PATCH net-next] net: ipv6: put autoconf routes into per-interface tables
From: David Ahern @ 2017-01-10 3:39 UTC (permalink / raw)
To: Lorenzo Colitti
Cc: netdev@vger.kernel.org, Maciej Żenczykowski,
Hannes Frederic Sowa, Erik Kline, YOSHIFUJI Hideaki, David Miller,
Daniel Rosenberg, temnota.am
In-Reply-To: <CAKD1Yr0BnYNTYtCBHLy=KuhX3_23p8eQst61CoC0BHEr5PVkjQ@mail.gmail.com>
On 1/9/17 8:30 PM, Lorenzo Colitti wrote:
> On Tue, Jan 10, 2017 at 12:04 PM, David Ahern <dsa@cumulusnetworks.com> wrote:
>>> I have no firsthand experience of this myself, but if the problems
>>> that Andrey reports above in this thread are real, then those would
>>> indicate that the code is not well-supported. Being unable to accept
>>> DAD is a pretty serious issue. Andrey, what version of the kernel did
>>> you see this on?
>>
>> Are you referencing an Android or google thread? This patch thread has not mentioned any IPv6 problems.
>
> No, this thread. I see message-ID 8cddkd-etc.ln1@banana.localnet in
> this thread. If you didn't get it, I also see it in the comments on
> patchwork - https://patchwork.ozlabs.org/patch/711956/
>
Odd that I did not get that -- checked spam and trash.
Andrey is missing 830218c1add1da16519b71909e5cf21522b7d062 which tells me the comment is not based on 4.10 or net-next:
$ git describe 830218c1add1da16519b71909e5cf21522b7d062
v4.8-14744-g830218c1add1
^ permalink raw reply
* Re: [RFC v2 00/10] HFI Virtual Network Interface Controller (VNIC)
From: Vishwanathapura, Niranjana @ 2017-01-10 3:39 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Doug Ledford, ira.weiny, Jeff Kirsher, David S. Miller,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
dennis.dalessandro-ral2JQCrhuEAvxtiuMwx3w
In-Reply-To: <20170109075104.GV15685-U/DQcQFIOTAAJjI8aNfphQ@public.gmane.org>
On Mon, Jan 09, 2017 at 09:51:04AM +0200, Leon Romanovsky wrote:
>On Thu, Dec 15, 2016 at 11:28:06AM -0500, Doug Ledford wrote:
>> On 12/15/2016 9:52 AM, ira.weiny wrote:
>>
>> 2) With more than 60% of the code being MAD related, and another
>> significant chunk being hfi related, and only a minor bit (20% maybe?)
>> being net related,
>
>Hi Doug and Ira,
>
>I may admit that I didn't read the code very deep, but from brief
>overview, I didn't find support for the claim the "60% code is MAD related".
>It looks like the opposite thing will be more accurate.
>
>Can you help me to understand this claim? How did you come to this
>conclusion?
>
>Thanks
Hi Leon,
Here is the breakdown of patches based on functionality.
In this series, patches #3..#8 compose hfi_vnic driver. In that, patches #4, #7
and #8 are MAD focused (interfacing with MAD agent and handling MAD packets).
Patch #6 and half of #3 (_encap.c/h) are OPA encapsulation related. Patch #5 is
netdev statistic related (which includes statistics MAD definitions).
So, only part of patch #3 (_netdev.c and _ethtool.c) deals with interfacing
with netstack.
Those percentage numbers are based on actual lines of code in these patches
(files).
We are also looking into Jason’s suggestion to make hfi_vnic interface to the
bottom driver a generic interface. This will include moving some of the
netstack interfacing to the bottom hfi1 driver.
Niranjana
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] net: add the AF_QIPCRTR entries to family name tables
From: Suman Anna @ 2017-01-10 3:48 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, linux-kernel, Suman Anna, Courtney Cavin, Bjorn Andersson
Commit bdabad3e363d ("net: Add Qualcomm IPC router") introduced a
new address family. Update the family name tables accordingly so
that the lockdep initialization can use the proper names for this
family.
Cc: Courtney Cavin <courtney.cavin@sonymobile.com>
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Suman Anna <s-anna@ti.com>
---
net/core/sock.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/core/sock.c b/net/core/sock.c
index f560e0826009..4eca27dc5c94 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -222,7 +222,7 @@ static const char *const af_family_key_strings[AF_MAX+1] = {
"sk_lock-AF_RXRPC" , "sk_lock-AF_ISDN" , "sk_lock-AF_PHONET" ,
"sk_lock-AF_IEEE802154", "sk_lock-AF_CAIF" , "sk_lock-AF_ALG" ,
"sk_lock-AF_NFC" , "sk_lock-AF_VSOCK" , "sk_lock-AF_KCM" ,
- "sk_lock-AF_MAX"
+ "sk_lock-AF_QIPCRTR", "sk_lock-AF_MAX"
};
static const char *const af_family_slock_key_strings[AF_MAX+1] = {
"slock-AF_UNSPEC", "slock-AF_UNIX" , "slock-AF_INET" ,
@@ -239,7 +239,7 @@ static const char *const af_family_slock_key_strings[AF_MAX+1] = {
"slock-AF_RXRPC" , "slock-AF_ISDN" , "slock-AF_PHONET" ,
"slock-AF_IEEE802154", "slock-AF_CAIF" , "slock-AF_ALG" ,
"slock-AF_NFC" , "slock-AF_VSOCK" ,"slock-AF_KCM" ,
- "slock-AF_MAX"
+ "slock-AF_QIPCRTR", "slock-AF_MAX"
};
static const char *const af_family_clock_key_strings[AF_MAX+1] = {
"clock-AF_UNSPEC", "clock-AF_UNIX" , "clock-AF_INET" ,
@@ -256,7 +256,7 @@ static const char *const af_family_clock_key_strings[AF_MAX+1] = {
"clock-AF_RXRPC" , "clock-AF_ISDN" , "clock-AF_PHONET" ,
"clock-AF_IEEE802154", "clock-AF_CAIF" , "clock-AF_ALG" ,
"clock-AF_NFC" , "clock-AF_VSOCK" , "clock-AF_KCM" ,
- "clock-AF_MAX"
+ "clock-AF_QIPCRTR", "clock-AF_MAX"
};
/*
--
2.10.2
^ permalink raw reply related
* Re: [net PATCH] net: virtio: cap mtu when XDP programs are running
From: Michael S. Tsirkin @ 2017-01-10 3:55 UTC (permalink / raw)
To: John Fastabend
Cc: Jason Wang, john.r.fastabend, netdev, alexei.starovoitov, daniel
In-Reply-To: <5874555A.3070307@gmail.com>
On Mon, Jan 09, 2017 at 07:30:34PM -0800, John Fastabend wrote:
> On 17-01-09 06:51 PM, Michael S. Tsirkin wrote:
> > On Tue, Jan 10, 2017 at 10:29:39AM +0800, Jason Wang wrote:
> >>
> >>
> >> On 2017年01月10日 07:58, Michael S. Tsirkin wrote:
> >>> On Mon, Jan 09, 2017 at 03:49:27PM -0800, John Fastabend wrote:
> >>>> On 17-01-09 03:24 PM, Michael S. Tsirkin wrote:
> >>>>> On Mon, Jan 09, 2017 at 03:13:15PM -0800, John Fastabend wrote:
> >>>>>> On 17-01-09 03:05 PM, Michael S. Tsirkin wrote:
> >>>>>>> On Thu, Jan 05, 2017 at 11:09:14AM +0800, Jason Wang wrote:
> >>>>>>>> On 2017年01月05日 02:57, John Fastabend wrote:
> >>>>>>>>> [...]
> >>>>>>>>>
> >>>>>>>>>> On 2017年01月04日 00:48, John Fastabend wrote:
> >>>>>>>>>>> On 17-01-02 10:14 PM, Jason Wang wrote:
> >>>>>>>>>>>> On 2017年01月03日 06:30, John Fastabend wrote:
> >>>>>>>>>>>>> XDP programs can not consume multiple pages so we cap the MTU to
> >>>>>>>>>>>>> avoid this case. Virtio-net however only checks the MTU at XDP
> >>>>>>>>>>>>> program load and does not block MTU changes after the program
> >>>>>>>>>>>>> has loaded.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> This patch sets/clears the max_mtu value at XDP load/unload time.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Signed-off-by: John Fastabend<john.r.fastabend@intel.com>
> >>>>>>>>>>>>> ---
> >>>>>>>>> [...]
> >>>>>>>>>
> >>>>>>>>>>> OK so this logic is a bit too simply. When it resets the max_mtu I guess it
> >>>>>>>>>>> needs to read the mtu via
> >>>>>>>>>>>
> >>>>>>>>>>> virtio_cread16(vdev, ...)
> >>>>>>>>>>>
> >>>>>>>>>>> or we may break the negotiated mtu.
> >>>>>>>>>> Yes, this is a problem (even use ETH_MAX_MTU). We may need a method to notify
> >>>>>>>>>> the device about the mtu in this case which is not supported by virtio now.
> >>>>>>>>> Note this is not really a XDP specific problem. The guest can change the MTU
> >>>>>>>>> after init time even without XDP which I assume should ideally result in a
> >>>>>>>>> notification if the MTU is negotiated.
> >>>>>>>> Yes, Michael, do you think we need add some mechanism to notify host about
> >>>>>>>> MTU change in this case?
> >>>>>>>>
> >>>>>>>> Thanks
> >>>>>>> Why does host care?
> >>>>>>>
> >>>>>> Well the guest will drop packets after mtu has been reduced.
> >>>>> I didn't know. What place in code does this?
> >>>>>
> >>>> hmm in many of the drivers it is convention to use the mtu to set the rx
> >>>> buffer sizes and a receive side max length filter. For example in the Intel
> >>>> drivers if a packet with length greater than MTU + some headroom is received we
> >>>> drop it. I guess in the networking stack RX path though nothing forces this and
> >>>> virtio doesn't have any code to drop packets on rx size.
> >>>>
> >>>> In virtio I don't see any existing case currently. In the XDP case though we
> >>>> need to ensure packets fit in a page for the time being which is why I was
> >>>> looking at this code and generated this patch.
> >>> I'd say just look at the hardware max mtu. Ignore the configured mtu.
> >>>
> >>>
> >>
> >> Does this work for small buffers consider it always allocate skb with size
> >> of GOOD_PACKET_LEN?
> >
> > Spec says hardware won't send in packets > max mtu in config space.
> >
> >> I think in any case, we should limit max_mtu to
> >> GOOD_PACKET_LEN for small buffers.
> >>
> >> Thanks
> >
> > XDP seems to have a bunch of weird restrictions, I just
> > do not like it that the logic spills out to all drivers.
> > What if someone decides to extend it to two pages in the future?
> > Recode it all in all drivers ...
> >
> > Why can't net core enforce mtu?
> >
>
> OK I agree I'll put most the logic in rtnetlink.c when the program is added
> or removed.
>
> But, I'm looking at the non-XDP receive_small path now and wondering how does
> multiple buffer receives work (e.g. packet larger than GOOD_PACKET_LEN?)
I don't understand the question. Look at add_recvbuf_small,
it adds a tiny buffer for head and then the skb.
> I think
> this is what Jason is looking at as well? The mergeable case clearly looks at
> num_bufs in the descriptor to construct multi-buffer packets but nothing like
> that exists in the small_receive path as best I can tell.
>
> .John
There's always a single buffer there.
BTW it was always a legacy path but if it's now important for people we
should probably check ANY_LAYOUT and put header linearly with the packet
if there.
--
MST
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox