* [PATCHv8 net-next 3/4] sunvnet: allow admin to set sunvnet MTU
From: David L Stevens @ 2014-09-29 19:54 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Sowmini Varadhan, Raghuram Kothahota
This patch allows an admin to set the MTU on a sunvnet device to arbitrary
values between the minimum (68) and maximum (65535) IPv4 packet sizes.
Signed-off-by: David L Stevens <david.stevens@oracle.com>
---
arch/sparc/kernel/ldc.c | 2 +-
drivers/net/ethernet/sun/sunvnet.c | 7 +++++--
drivers/net/ethernet/sun/sunvnet.h | 6 ++++--
3 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/arch/sparc/kernel/ldc.c b/arch/sparc/kernel/ldc.c
index 66dacd5..0af28b9 100644
--- a/arch/sparc/kernel/ldc.c
+++ b/arch/sparc/kernel/ldc.c
@@ -2159,7 +2159,7 @@ int ldc_map_single(struct ldc_channel *lp,
state.pte_idx = (base - iommu->page_table);
state.nc = 0;
fill_cookies(&state, (pa & PAGE_MASK), (pa & ~PAGE_MASK), len);
- BUG_ON(state.nc != 1);
+ BUG_ON(state.nc > ncookies);
return state.nc;
}
diff --git a/drivers/net/ethernet/sun/sunvnet.c b/drivers/net/ethernet/sun/sunvnet.c
index 7faa0ca..e1f954c 100644
--- a/drivers/net/ethernet/sun/sunvnet.c
+++ b/drivers/net/ethernet/sun/sunvnet.c
@@ -887,6 +887,9 @@ static int vnet_start_xmit(struct sk_buff *skb, struct net_device *dev)
if (unlikely(!skb))
goto out_dropped;
+ if (skb->len > port->rmtu)
+ goto out_dropped;
+
spin_lock_irqsave(&port->vio.lock, flags);
dr = &port->vio.drings[VIO_DRIVER_TX_RING];
@@ -917,7 +920,7 @@ static int vnet_start_xmit(struct sk_buff *skb, struct net_device *dev)
port->tx_bufs[txi].skb = skb;
err = ldc_map_single(port->vio.lp, start, nlen,
- port->tx_bufs[txi].cookies, 2,
+ port->tx_bufs[txi].cookies, VNET_MAXCOOKIES,
(LDC_MAP_SHADOW | LDC_MAP_DIRECT | LDC_MAP_RW));
if (err < 0) {
netdev_info(dev, "tx buffer map error %d\n", err);
@@ -1146,7 +1149,7 @@ static void vnet_set_rx_mode(struct net_device *dev)
static int vnet_change_mtu(struct net_device *dev, int new_mtu)
{
- if (new_mtu != ETH_DATA_LEN)
+ if (new_mtu < 68 || new_mtu > 65535)
return -EINVAL;
dev->mtu = new_mtu;
diff --git a/drivers/net/ethernet/sun/sunvnet.h b/drivers/net/ethernet/sun/sunvnet.h
index f18409b..ead9001 100644
--- a/drivers/net/ethernet/sun/sunvnet.h
+++ b/drivers/net/ethernet/sun/sunvnet.h
@@ -11,7 +11,7 @@
*/
#define VNET_TX_TIMEOUT (5 * HZ)
-#define VNET_MAXPACKET 1518ULL /* ETH_FRAMELEN + VLAN_HDR */
+#define VNET_MAXPACKET (65535ULL + ETH_HLEN + VLAN_HLEN)
#define VNET_TX_RING_SIZE 512
#define VNET_TX_WAKEUP_THRESH(dr) ((dr)->pending / 4)
@@ -21,10 +21,12 @@
*/
#define VNET_PACKET_SKIP 6
+#define VNET_MAXCOOKIES (VNET_MAXPACKET/PAGE_SIZE + 1)
+
struct vnet_tx_entry {
struct sk_buff *skb;
unsigned int ncookies;
- struct ldc_trans_cookie cookies[2];
+ struct ldc_trans_cookie cookies[VNET_MAXCOOKIES];
};
struct vnet;
--
1.7.1
^ permalink raw reply related
* [PATCHv8 net-next 2/4] sunvnet: make transmit path zero-copy in the kernel
From: David L Stevens @ 2014-09-29 19:54 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Sowmini Varadhan, Raghuram Kothahota
This patch removes pre-allocated transmit buffers and instead directly maps
pending packets on demand. This saves O(n^2) maximum-sized transmit buffers,
for n hosts on a vswitch, as well as a copy to those buffers.
Single-stream TCP throughput linux-solaris dropped ~5% for 1500-byte MTU,
but linux-linux at 1500-bytes increased ~20%.
Signed-off-by: David L Stevens <david.stevens@oracle.com>
---
drivers/net/ethernet/sun/sunvnet.c | 176 +++++++++++++++++++++++++++---------
drivers/net/ethernet/sun/sunvnet.h | 2 +-
2 files changed, 134 insertions(+), 44 deletions(-)
diff --git a/drivers/net/ethernet/sun/sunvnet.c b/drivers/net/ethernet/sun/sunvnet.c
index b1abcad..7faa0ca 100644
--- a/drivers/net/ethernet/sun/sunvnet.c
+++ b/drivers/net/ethernet/sun/sunvnet.c
@@ -780,6 +780,92 @@ struct vnet_port *tx_port_find(struct vnet *vp, struct sk_buff *skb)
return ret;
}
+static struct sk_buff *vnet_clean_tx_ring(struct vnet_port *port)
+{
+ struct vio_dring_state *dr = &port->vio.drings[VIO_DRIVER_TX_RING];
+ struct sk_buff *skb = NULL;
+ int i, txi;
+
+ txi = dr->prod-1;
+ if (txi < 0)
+ txi = VNET_TX_RING_SIZE-1;
+
+ for (i = 0; i < VNET_TX_RING_SIZE; ++i) {
+ struct vio_net_desc *d;
+
+ d = vio_dring_entry(dr, txi);
+
+ if (d->hdr.state == VIO_DESC_DONE) {
+ if (port->tx_bufs[txi].skb) {
+ BUG_ON(port->tx_bufs[txi].skb->next);
+
+ port->tx_bufs[txi].skb->next = skb;
+ skb = port->tx_bufs[txi].skb;
+ port->tx_bufs[txi].skb = NULL;
+
+ ldc_unmap(port->vio.lp,
+ port->tx_bufs[txi].cookies,
+ port->tx_bufs[txi].ncookies);
+ }
+ d->hdr.state = VIO_DESC_FREE;
+ } else if (d->hdr.state == VIO_DESC_FREE) {
+ break;
+ }
+ --txi;
+ if (txi < 0)
+ txi = VNET_TX_RING_SIZE-1;
+ }
+ return skb;
+}
+
+static inline void vnet_free_skbs(struct sk_buff *skb)
+{
+ struct sk_buff *next;
+
+ while (skb) {
+ next = skb->next;
+ skb->next = NULL;
+ dev_kfree_skb(skb);
+ skb = next;
+ }
+}
+
+static inline struct sk_buff *vnet_skb_shape(struct sk_buff *skb, void **pstart,
+ int *plen)
+{
+ struct sk_buff *nskb;
+ int len, pad;
+
+ len = skb->len;
+ pad = 0;
+ if (len < ETH_ZLEN) {
+ pad += ETH_ZLEN - skb->len;
+ len += pad;
+ }
+ len += VNET_PACKET_SKIP;
+ pad += 8 - (len & 7);
+ len += 8 - (len & 7);
+
+ if (((unsigned long)skb->data & 7) != VNET_PACKET_SKIP ||
+ skb_tailroom(skb) < pad ||
+ skb_headroom(skb) < VNET_PACKET_SKIP) {
+ nskb = alloc_and_align_skb(skb->dev, skb->len);
+ skb_reserve(nskb, VNET_PACKET_SKIP);
+ if (skb_copy_bits(skb, 0, nskb->data, skb->len)) {
+ dev_kfree_skb(nskb);
+ dev_kfree_skb(skb);
+ return NULL;
+ }
+ (void)skb_put(nskb, skb->len);
+ dev_kfree_skb(skb);
+ skb = nskb;
+ }
+
+ *pstart = skb->data - VNET_PACKET_SKIP;
+ *plen = len;
+ return skb;
+}
+
static int vnet_start_xmit(struct sk_buff *skb, struct net_device *dev)
{
struct vnet *vp = netdev_priv(dev);
@@ -788,12 +874,19 @@ static int vnet_start_xmit(struct sk_buff *skb, struct net_device *dev)
struct vio_net_desc *d;
unsigned long flags;
unsigned int len;
- void *tx_buf;
- int i, err;
+ struct sk_buff *freeskbs = NULL;
+ int i, err, txi;
+ void *start = NULL;
+ int nlen = 0;
if (unlikely(!port))
goto out_dropped;
+ skb = vnet_skb_shape(skb, &start, &nlen);
+
+ if (unlikely(!skb))
+ goto out_dropped;
+
spin_lock_irqsave(&port->vio.lock, flags);
dr = &port->vio.drings[VIO_DRIVER_TX_RING];
@@ -811,14 +904,26 @@ static int vnet_start_xmit(struct sk_buff *skb, struct net_device *dev)
d = vio_dring_cur(dr);
- tx_buf = port->tx_bufs[dr->prod].buf;
- skb_copy_from_linear_data(skb, tx_buf + VNET_PACKET_SKIP, skb->len);
+ txi = dr->prod;
+
+ freeskbs = vnet_clean_tx_ring(port);
+
+ BUG_ON(port->tx_bufs[txi].skb);
len = skb->len;
- if (len < ETH_ZLEN) {
+ if (len < ETH_ZLEN)
len = ETH_ZLEN;
- memset(tx_buf+VNET_PACKET_SKIP+skb->len, 0, len - skb->len);
+
+ port->tx_bufs[txi].skb = skb;
+
+ err = ldc_map_single(port->vio.lp, start, nlen,
+ port->tx_bufs[txi].cookies, 2,
+ (LDC_MAP_SHADOW | LDC_MAP_DIRECT | LDC_MAP_RW));
+ if (err < 0) {
+ netdev_info(dev, "tx buffer map error %d\n", err);
+ goto out_dropped_unlock;
}
+ port->tx_bufs[txi].ncookies = err;
/* We don't rely on the ACKs to free the skb in vnet_start_xmit(),
* thus it is safe to not set VIO_ACK_ENABLE for each transmission:
@@ -830,9 +935,9 @@ static int vnet_start_xmit(struct sk_buff *skb, struct net_device *dev)
*/
d->hdr.ack = VIO_ACK_DISABLE;
d->size = len;
- d->ncookies = port->tx_bufs[dr->prod].ncookies;
+ d->ncookies = port->tx_bufs[txi].ncookies;
for (i = 0; i < d->ncookies; i++)
- d->cookies[i] = port->tx_bufs[dr->prod].cookies[i];
+ d->cookies[i] = port->tx_bufs[txi].cookies[i];
/* This has to be a non-SMP write barrier because we are writing
* to memory which is shared with the peer LDOM.
@@ -887,7 +992,7 @@ ldc_start_done:
spin_unlock_irqrestore(&port->vio.lock, flags);
- dev_kfree_skb(skb);
+ vnet_free_skbs(freeskbs);
return NETDEV_TX_OK;
@@ -895,7 +1000,7 @@ out_dropped_unlock:
spin_unlock_irqrestore(&port->vio.lock, flags);
out_dropped:
- dev_kfree_skb(skb);
+ vnet_free_skbs(freeskbs);
dev->stats.tx_dropped++;
return NETDEV_TX_OK;
}
@@ -1097,17 +1202,22 @@ static void vnet_port_free_tx_bufs(struct vnet_port *port)
}
for (i = 0; i < VNET_TX_RING_SIZE; i++) {
- void *buf = port->tx_bufs[i].buf;
+ struct vio_net_desc *d;
+ void *skb = port->tx_bufs[i].skb;
- if (!buf)
+ if (!skb)
continue;
+ d = vio_dring_entry(dr, i);
+ if (d->hdr.state == VIO_DESC_READY)
+ pr_warn("active transmit buffers freed\n");
+
ldc_unmap(port->vio.lp,
port->tx_bufs[i].cookies,
port->tx_bufs[i].ncookies);
-
- kfree(buf);
- port->tx_bufs[i].buf = NULL;
+ dev_kfree_skb(skb);
+ port->tx_bufs[i].skb = NULL;
+ d->hdr.state = VIO_DESC_FREE;
}
}
@@ -1118,34 +1228,6 @@ static int vnet_port_alloc_tx_bufs(struct vnet_port *port)
int i, err, ncookies;
void *dring;
- for (i = 0; i < VNET_TX_RING_SIZE; i++) {
- void *buf = kzalloc(VNET_MAXPACKET + 8, GFP_KERNEL);
- int map_len = (VNET_MAXPACKET + 7) & ~7;
-
- err = -ENOMEM;
- if (!buf)
- goto err_out;
-
- err = -EFAULT;
- if ((unsigned long)buf & (8UL - 1)) {
- pr_err("TX buffer misaligned\n");
- kfree(buf);
- goto err_out;
- }
-
- err = ldc_map_single(port->vio.lp, buf, map_len,
- port->tx_bufs[i].cookies, 2,
- (LDC_MAP_SHADOW |
- LDC_MAP_DIRECT |
- LDC_MAP_RW));
- if (err < 0) {
- kfree(buf);
- goto err_out;
- }
- port->tx_bufs[i].buf = buf;
- port->tx_bufs[i].ncookies = err;
- }
-
dr = &port->vio.drings[VIO_DRIVER_TX_RING];
len = (VNET_TX_RING_SIZE *
@@ -1172,6 +1254,12 @@ static int vnet_port_alloc_tx_bufs(struct vnet_port *port)
dr->pending = VNET_TX_RING_SIZE;
dr->ncookies = ncookies;
+ for (i = 0; i < VNET_TX_RING_SIZE; ++i) {
+ struct vio_net_desc *d;
+
+ d = vio_dring_entry(dr, i);
+ d->hdr.state = VIO_DESC_FREE;
+ }
return 0;
err_out:
@@ -1203,6 +1291,8 @@ static struct vnet *vnet_new(const u64 *local_mac)
dev = alloc_etherdev(sizeof(*vp));
if (!dev)
return ERR_PTR(-ENOMEM);
+ dev->needed_headroom = VNET_PACKET_SKIP + 8;
+ dev->needed_tailroom = 8;
for (i = 0; i < ETH_ALEN; i++)
dev->dev_addr[i] = (*local_mac >> (5 - i) * 8) & 0xff;
diff --git a/drivers/net/ethernet/sun/sunvnet.h b/drivers/net/ethernet/sun/sunvnet.h
index 986e04b..f18409b 100644
--- a/drivers/net/ethernet/sun/sunvnet.h
+++ b/drivers/net/ethernet/sun/sunvnet.h
@@ -22,7 +22,7 @@
#define VNET_PACKET_SKIP 6
struct vnet_tx_entry {
- void *buf;
+ struct sk_buff *skb;
unsigned int ncookies;
struct ldc_trans_cookie cookies[2];
};
--
1.7.1
^ permalink raw reply related
* [PATCHv8 net-next 1/4] sunvnet: upgrade to VIO protocol version 1.6
From: David L Stevens @ 2014-09-29 19:53 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Sowmini Varadhan, Raghuram Kothahota
This patch upgrades the sunvnet driver to support VIO protocol version 1.6.
In particular, it adds per-port MTU negotiation, allowing MTUs other than
ETH_FRAMELEN with ports using newer VIO protocol versions.
Signed-off-by: David L Stevens <david.stevens@oracle.com>
---
arch/sparc/include/asm/vio.h | 44 ++++++++++++++-
arch/sparc/kernel/viohs.c | 14 ++++-
drivers/net/ethernet/sun/sunvnet.c | 104 +++++++++++++++++++++++++++++------
drivers/net/ethernet/sun/sunvnet.h | 3 +
4 files changed, 143 insertions(+), 22 deletions(-)
diff --git a/arch/sparc/include/asm/vio.h b/arch/sparc/include/asm/vio.h
index 5c0ebe7..107d4a4 100644
--- a/arch/sparc/include/asm/vio.h
+++ b/arch/sparc/include/asm/vio.h
@@ -65,6 +65,7 @@ struct vio_dring_register {
u16 options;
#define VIO_TX_DRING 0x0001
#define VIO_RX_DRING 0x0002
+#define VIO_RX_DRING_DATA 0x0004
u16 resv;
u32 num_cookies;
struct ldc_trans_cookie cookies[0];
@@ -80,6 +81,8 @@ struct vio_dring_unregister {
#define VIO_PKT_MODE 0x01 /* Packet based transfer */
#define VIO_DESC_MODE 0x02 /* In-band descriptors */
#define VIO_DRING_MODE 0x03 /* Descriptor rings */
+/* in vers >= 1.2, VIO_DRING_MODE is 0x04 and transfer mode is a bitmask */
+#define VIO_NEW_DRING_MODE 0x04
struct vio_dring_data {
struct vio_msg_tag tag;
@@ -209,10 +212,20 @@ struct vio_net_attr_info {
u8 addr_type;
#define VNET_ADDR_ETHERMAC 0x01
u16 ack_freq;
- u32 resv1;
+ u8 plnk_updt;
+#define PHYSLINK_UPDATE_NONE 0x00
+#define PHYSLINK_UPDATE_STATE 0x01
+#define PHYSLINK_UPDATE_STATE_ACK 0x02
+#define PHYSLINK_UPDATE_STATE_NACK 0x03
+ u8 options;
+ u16 resv1;
u64 addr;
u64 mtu;
- u64 resv2[3];
+ u16 cflags;
+#define VNET_LSO_IPV4_CAPAB 0x0001
+ u16 ipv4_lso_maxlen;
+ u32 resv2;
+ u64 resv3[2];
};
#define VNET_NUM_MCAST 7
@@ -370,6 +383,33 @@ struct vio_driver_state {
struct vio_driver_ops *ops;
};
+static inline bool vio_version_before(struct vio_driver_state *vio,
+ u16 major, u16 minor)
+{
+ u32 have = (u32)vio->ver.major << 16 | vio->ver.minor;
+ u32 want = (u32)major << 16 | minor;
+
+ return have < want;
+}
+
+static inline bool vio_version_after(struct vio_driver_state *vio,
+ u16 major, u16 minor)
+{
+ u32 have = (u32)vio->ver.major << 16 | vio->ver.minor;
+ u32 want = (u32)major << 16 | minor;
+
+ return have > want;
+}
+
+static inline bool vio_version_after_eq(struct vio_driver_state *vio,
+ u16 major, u16 minor)
+{
+ u32 have = (u32)vio->ver.major << 16 | vio->ver.minor;
+ u32 want = (u32)major << 16 | minor;
+
+ return have >= want;
+}
+
#define viodbg(TYPE, f, a...) \
do { if (vio->debug & VIO_DEBUG_##TYPE) \
printk(KERN_INFO "vio: ID[%lu] " f, \
diff --git a/arch/sparc/kernel/viohs.c b/arch/sparc/kernel/viohs.c
index f8e7dd5..7ef081a 100644
--- a/arch/sparc/kernel/viohs.c
+++ b/arch/sparc/kernel/viohs.c
@@ -426,6 +426,13 @@ static int process_dreg_info(struct vio_driver_state *vio,
if (vio->dr_state & VIO_DR_STATE_RXREG)
goto send_nack;
+ /* v1.6 and higher, ACK with desired, supported mode, or NACK */
+ if (vio_version_after_eq(vio, 1, 6)) {
+ if (!(pkt->options & VIO_TX_DRING))
+ goto send_nack;
+ pkt->options = VIO_TX_DRING;
+ }
+
BUG_ON(vio->desc_buf);
vio->desc_buf = kzalloc(pkt->descr_size, GFP_ATOMIC);
@@ -453,8 +460,11 @@ static int process_dreg_info(struct vio_driver_state *vio,
pkt->tag.stype = VIO_SUBTYPE_ACK;
pkt->dring_ident = ++dr->ident;
- viodbg(HS, "SEND DRING_REG ACK ident[%llx]\n",
- (unsigned long long) pkt->dring_ident);
+ viodbg(HS, "SEND DRING_REG ACK ident[%llx] "
+ "ndesc[%u] dsz[%u] opt[0x%x] ncookies[%u]\n",
+ (unsigned long long) pkt->dring_ident,
+ pkt->num_descr, pkt->descr_size, pkt->options,
+ pkt->num_cookies);
len = (sizeof(*pkt) +
(dr->ncookies * sizeof(struct ldc_trans_cookie)));
diff --git a/drivers/net/ethernet/sun/sunvnet.c b/drivers/net/ethernet/sun/sunvnet.c
index edb8609..b1abcad 100644
--- a/drivers/net/ethernet/sun/sunvnet.c
+++ b/drivers/net/ethernet/sun/sunvnet.c
@@ -15,6 +15,7 @@
#include <linux/ethtool.h>
#include <linux/etherdevice.h>
#include <linux/mutex.h>
+#include <linux/if_vlan.h>
#include <asm/vio.h>
#include <asm/ldc.h>
@@ -41,6 +42,7 @@ static int __vnet_tx_trigger(struct vnet_port *port, u32 start);
/* Ordered from largest major to lowest */
static struct vio_version vnet_versions[] = {
+ { .major = 1, .minor = 6 },
{ .major = 1, .minor = 0 },
};
@@ -67,6 +69,7 @@ static int vnet_send_attr(struct vio_driver_state *vio)
struct vnet_port *port = to_vnet_port(vio);
struct net_device *dev = port->vp->dev;
struct vio_net_attr_info pkt;
+ int framelen = ETH_FRAME_LEN;
int i;
memset(&pkt, 0, sizeof(pkt));
@@ -74,19 +77,41 @@ static int vnet_send_attr(struct vio_driver_state *vio)
pkt.tag.stype = VIO_SUBTYPE_INFO;
pkt.tag.stype_env = VIO_ATTR_INFO;
pkt.tag.sid = vio_send_sid(vio);
- pkt.xfer_mode = VIO_DRING_MODE;
+ if (vio_version_before(vio, 1, 2))
+ pkt.xfer_mode = VIO_DRING_MODE;
+ else
+ pkt.xfer_mode = VIO_NEW_DRING_MODE;
pkt.addr_type = VNET_ADDR_ETHERMAC;
pkt.ack_freq = 0;
for (i = 0; i < 6; i++)
pkt.addr |= (u64)dev->dev_addr[i] << ((5 - i) * 8);
- pkt.mtu = ETH_FRAME_LEN;
+ if (vio_version_after(vio, 1, 3)) {
+ if (port->rmtu) {
+ port->rmtu = min(VNET_MAXPACKET, port->rmtu);
+ pkt.mtu = port->rmtu;
+ } else {
+ port->rmtu = VNET_MAXPACKET;
+ pkt.mtu = port->rmtu;
+ }
+ if (vio_version_after_eq(vio, 1, 6))
+ pkt.options = VIO_TX_DRING;
+ } else if (vio_version_before(vio, 1, 3)) {
+ pkt.mtu = framelen;
+ } else { /* v1.3 */
+ pkt.mtu = framelen + VLAN_HLEN;
+ }
+
+ pkt.plnk_updt = PHYSLINK_UPDATE_NONE;
+ pkt.cflags = 0;
viodbg(HS, "SEND NET ATTR xmode[0x%x] atype[0x%x] addr[%llx] "
- "ackfreq[%u] mtu[%llu]\n",
+ "ackfreq[%u] plnk_updt[0x%02x] opts[0x%02x] mtu[%llu] "
+ "cflags[0x%04x] lso_max[%u]\n",
pkt.xfer_mode, pkt.addr_type,
- (unsigned long long) pkt.addr,
- pkt.ack_freq,
- (unsigned long long) pkt.mtu);
+ (unsigned long long)pkt.addr,
+ pkt.ack_freq, pkt.plnk_updt, pkt.options,
+ (unsigned long long)pkt.mtu, pkt.cflags, pkt.ipv4_lso_maxlen);
+
return vio_ldc_send(vio, &pkt, sizeof(pkt));
}
@@ -94,18 +119,52 @@ static int vnet_send_attr(struct vio_driver_state *vio)
static int handle_attr_info(struct vio_driver_state *vio,
struct vio_net_attr_info *pkt)
{
- viodbg(HS, "GOT NET ATTR INFO xmode[0x%x] atype[0x%x] addr[%llx] "
- "ackfreq[%u] mtu[%llu]\n",
+ struct vnet_port *port = to_vnet_port(vio);
+ u64 localmtu;
+ u8 xfer_mode;
+
+ viodbg(HS, "GOT NET ATTR xmode[0x%x] atype[0x%x] addr[%llx] "
+ "ackfreq[%u] plnk_updt[0x%02x] opts[0x%02x] mtu[%llu] "
+ " (rmtu[%llu]) cflags[0x%04x] lso_max[%u]\n",
pkt->xfer_mode, pkt->addr_type,
- (unsigned long long) pkt->addr,
- pkt->ack_freq,
- (unsigned long long) pkt->mtu);
+ (unsigned long long)pkt->addr,
+ pkt->ack_freq, pkt->plnk_updt, pkt->options,
+ (unsigned long long)pkt->mtu, port->rmtu, pkt->cflags,
+ pkt->ipv4_lso_maxlen);
pkt->tag.sid = vio_send_sid(vio);
- if (pkt->xfer_mode != VIO_DRING_MODE ||
+ xfer_mode = pkt->xfer_mode;
+ /* for version < 1.2, VIO_DRING_MODE = 0x3 and no bitmask */
+ if (vio_version_before(vio, 1, 2) && xfer_mode == VIO_DRING_MODE)
+ xfer_mode = VIO_NEW_DRING_MODE;
+
+ /* MTU negotiation:
+ * < v1.3 - ETH_FRAME_LEN exactly
+ * > v1.3 - MIN(pkt.mtu, VNET_MAXPACKET, port->rmtu) and change
+ * pkt->mtu for ACK
+ * = v1.3 - ETH_FRAME_LEN + VLAN_HLEN exactly
+ */
+ if (vio_version_before(vio, 1, 3)) {
+ localmtu = ETH_FRAME_LEN;
+ } else if (vio_version_after(vio, 1, 3)) {
+ localmtu = port->rmtu ? port->rmtu : VNET_MAXPACKET;
+ localmtu = min(pkt->mtu, localmtu);
+ pkt->mtu = localmtu;
+ } else { /* v1.3 */
+ localmtu = ETH_FRAME_LEN + VLAN_HLEN;
+ }
+ port->rmtu = localmtu;
+
+ /* for version >= 1.6, ACK packet mode we support */
+ if (vio_version_after_eq(vio, 1, 6)) {
+ pkt->xfer_mode = VIO_NEW_DRING_MODE;
+ pkt->options = VIO_TX_DRING;
+ }
+
+ if (!(xfer_mode | VIO_NEW_DRING_MODE) ||
pkt->addr_type != VNET_ADDR_ETHERMAC ||
- pkt->mtu != ETH_FRAME_LEN) {
+ pkt->mtu != localmtu) {
viodbg(HS, "SEND NET ATTR NACK\n");
pkt->tag.stype = VIO_SUBTYPE_NACK;
@@ -114,7 +173,14 @@ static int handle_attr_info(struct vio_driver_state *vio,
return -ECONNRESET;
} else {
- viodbg(HS, "SEND NET ATTR ACK\n");
+ viodbg(HS, "SEND NET ATTR ACK xmode[0x%x] atype[0x%x] "
+ "addr[%llx] ackfreq[%u] plnk_updt[0x%02x] opts[0x%02x] "
+ "mtu[%llu] (rmtu[%llu]) cflags[0x%04x] lso_max[%u]\n",
+ pkt->xfer_mode, pkt->addr_type,
+ (unsigned long long)pkt->addr,
+ pkt->ack_freq, pkt->plnk_updt, pkt->options,
+ (unsigned long long)pkt->mtu, port->rmtu, pkt->cflags,
+ pkt->ipv4_lso_maxlen);
pkt->tag.stype = VIO_SUBTYPE_ACK;
@@ -210,7 +276,7 @@ static int vnet_rx_one(struct vnet_port *port, unsigned int len,
int err;
err = -EMSGSIZE;
- if (unlikely(len < ETH_ZLEN || len > ETH_FRAME_LEN)) {
+ if (unlikely(len < ETH_ZLEN || len > port->rmtu)) {
dev->stats.rx_length_errors++;
goto out_dropped;
}
@@ -558,8 +624,10 @@ static void vnet_event(void *arg, int event)
vio_link_state_change(vio, event);
spin_unlock_irqrestore(&vio->lock, flags);
- if (event == LDC_EVENT_RESET)
+ if (event == LDC_EVENT_RESET) {
+ port->rmtu = 0;
vio_port_up(vio);
+ }
return;
}
@@ -1051,8 +1119,8 @@ static int vnet_port_alloc_tx_bufs(struct vnet_port *port)
void *dring;
for (i = 0; i < VNET_TX_RING_SIZE; i++) {
- void *buf = kzalloc(ETH_FRAME_LEN + 8, GFP_KERNEL);
- int map_len = (ETH_FRAME_LEN + 7) & ~7;
+ void *buf = kzalloc(VNET_MAXPACKET + 8, GFP_KERNEL);
+ int map_len = (VNET_MAXPACKET + 7) & ~7;
err = -ENOMEM;
if (!buf)
diff --git a/drivers/net/ethernet/sun/sunvnet.h b/drivers/net/ethernet/sun/sunvnet.h
index da49337..986e04b 100644
--- a/drivers/net/ethernet/sun/sunvnet.h
+++ b/drivers/net/ethernet/sun/sunvnet.h
@@ -11,6 +11,7 @@
*/
#define VNET_TX_TIMEOUT (5 * HZ)
+#define VNET_MAXPACKET 1518ULL /* ETH_FRAMELEN + VLAN_HDR */
#define VNET_TX_RING_SIZE 512
#define VNET_TX_WAKEUP_THRESH(dr) ((dr)->pending / 4)
@@ -44,6 +45,8 @@ struct vnet_port {
u32 stop_rx_idx;
bool stop_rx;
bool start_cons;
+
+ u64 rmtu;
};
static inline struct vnet_port *to_vnet_port(struct vio_driver_state *vio)
--
1.7.1
^ permalink raw reply related
* [PATCHv8 net-next 0/4] sunvnet: add jumbo frames support
From: David L Stevens @ 2014-09-29 19:53 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Sowmini Varadhan, Raghuram Kothahota
This patch set updates the sunvnet driver to version 1.6 of the VIO protocol
to support per-port exchange of MTU information and allow non-standard MTU
sizes, including jumbo frames.
Using large MTUs shows a nearly 5X throughput improvement Linux-Solaris
and > 10X throughput improvement Linux-Linux.
Changes from v7:
-handle skb allocation failures in vnet_skb_shape()
per Dave Miller <davem@davemloft.net>
Changes from v6:
-made kernel transmit path zero-copy to remove memory n^2 scaling issue
raised by Raghuram Kothakota <Raghuram.Kothakota@oracle.com>
Changes from v5:
- fixed comment per Sowmini Varadhan <sowmini.varadhan@oracle.com>
Changes from v4:
- changed VNET_MAXPACKET per David Laight <David.Laight@ACULAB.COM>
- added cookies to support non-contiguous buffers of max size
Changes from v3:
- added version functions per Dave Miller <davem@davemloft.net>
- moved rmtu to vnet_port per Dave Miller <davem@davemloft.net>
- explicitly set options bits and capability flags to 0 per
Raghuram Kothakota <Raghuram.Kothakota@oracle.com>
Changes from v2:
- make checkpatch clean
Changes from v1:
- fix brace formatting per Dave Miller <davem@davemloft.net>
David L Stevens (4):
sunvnet: upgrade to VIO protocol version 1.6
sunvnet: make transmit path zero-copy in the kernel
sunvnet: allow admin to set sunvnet MTU
sunvnet: generate ICMP PTMUD messages for smaller port MTUs
arch/sparc/include/asm/vio.h | 44 +++++-
arch/sparc/kernel/ldc.c | 2 +-
arch/sparc/kernel/viohs.c | 14 ++-
drivers/net/ethernet/sun/sunvnet.c | 316 +++++++++++++++++++++++++++++-------
drivers/net/ethernet/sun/sunvnet.h | 9 +-
5 files changed, 318 insertions(+), 67 deletions(-)
^ permalink raw reply
* Re: [PATCH v5 2/3] net: Add Keystone NetCP ethernet driver
From: David Miller @ 2014-09-29 19:52 UTC (permalink / raw)
To: santosh.shilimkar
Cc: netdev, linux-arm-kernel, linux-kernel, robh+dt, grant.likely,
devicetree, sandeep_n, joe
In-Reply-To: <1411667317-1163-3-git-send-email-santosh.shilimkar@ti.com>
From: Santosh Shilimkar <santosh.shilimkar@ti.com>
Date: Thu, 25 Sep 2014 13:48:36 -0400
> +static inline int gbe_phy_link_status(struct gbe_slave *slave)
> +{
> + if (!slave->phy)
> + return 1;
> +
> + if (slave->phy->link)
> + return 1;
> +
> + return 0;
> +}
Please use 'bool' as the return type and return 'true' or 'false'.
Do not use 'inline' in foo.c files, let the compiler decide. Please
audit this entire submission for this problem.
> +static int gbe_port_reset(struct gbe_slave *slave)
> +{
> + u32 i, v;
> +
> + /* Set the soft reset bit */
> + writel_relaxed(SOFT_RESET, GBE_REG_ADDR(slave, emac_regs, soft_reset));
This driver seems to use relaxed readl and writel for almost everything.
That absolutely cannot be right. For example, here, you depend upon the
ordering of this writel_relaxed() to reset the chip relative to the
real_relaxed() you subsequently do to check ths bits.
I seriously think that *_relaxed() should only be done in very special
circumstances where 1) the performance matters and 2) the validity of
the usage has been put under a microscope and fully documented with huge
comments above the *_relaxed() calls.
If you cannot reduce and properly document the really necessary *_relaxed()
uses, just convert them all to non-_relaxed() for now.
I'm also warning you ahead of time that since nobody else seems to feel
like reviewing this enormous submission, you are going to have to get used
to me pushing back on these changes over and over for small things like
coding style and structural/API issues until some reviews it on a higher
level.
I really don't want to apply this series until someone thinks seriously
about the driver's design and the long term ramifications of having a
driver like this in the tree with so many random TX etc. hooks.
^ permalink raw reply
* Re: [PATCH] tun: make sure interface usage can not overflow
From: Kees Cook @ 2014-09-29 19:48 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: LKML, David S. Miller, Jason Wang, Zhi Yong Wu, Tom Herbert,
Masatake YAMATO, Xi Wang, stephen hemminger, Network Development
In-Reply-To: <20140929114849.GA913@redhat.com>
On Mon, Sep 29, 2014 at 4:48 AM, Michael S. Tsirkin <mst@redhat.com> wrote:
> On Sun, Sep 28, 2014 at 04:27:53PM -0700, Kees Cook wrote:
>> This makes the size argument a const, since it is always populated by
>> the caller. Additionally double-checks to make sure the copy_from_user
>> can never overflow, keeping CONFIG_DEBUG_STRICT_USER_COPY_CHECKS happy:
>>
>> In function 'copy_from_user',
>> inlined from '__tun_chr_ioctl' at drivers/net/tun.c:1871:7:
>> ... copy_from_user() buffer size is not provably correct
>>
>> Signed-off-by: Kees Cook <keescook@chromium.org>
>
> What exactly is the issue here?
> __tun_chr_ioctl is called with sizeof(struct compat_ifreq)
> or sizeof (struct ifreq) as the last argument.
Correct. There is no vulnerability here; I am attempting to both make
the code more defensive to future changes, and to keep
CONFIG_DEBUG_STRICT_USER_COPY_CHECKS happy.
> So this looks like a false positive, but
> CONFIG_DEBUG_STRICT_USER_COPY_CHECKS machinery is supposed
> to avoid false positives.
The support in GCC is currently a bit faulty, and it seems that it
didn't notice the two callers were static values, so instead, adding
an explicit test keeps it happy.
> On which architecture is this?
This is on x86, but with CONFIG_DEBUG_STRICT_USER_COPY_CHECKS
correctly enabled (gcc after 4.6 broke its ability to correctly
optimize), which I've been playing with trying to get gcc working
again. I sent the patch because it seems like it's a reasonable
defensive change to make.
If you want to look more deeply, there's some background here:
https://code.google.com/p/chromium/issues/detail?id=371036
https://git.kernel.org/cgit/linux/kernel/git/kees/linux.git/commit/?h=gcc-bug&id=92dd7154932d8775a05dfd3de5564124c05a4150
Thanks,
-Kees
--
Kees Cook
Chrome OS Security
^ permalink raw reply
* Re: IPv6 FIB related crash with MACVLANs in 3.9.11+ kernel.
From: Ben Greear @ 2014-09-29 19:48 UTC (permalink / raw)
To: Hannes Frederic Sowa; +Cc: Hongmei Li, netdev
In-Reply-To: <1412017399.14757.4.camel@localhost>
On 09/29/2014 12:03 PM, Hannes Frederic Sowa wrote:
> On Mo, 2014-09-29 at 11:44 -0700, Ben Greear wrote:
>> On 09/29/2014 11:15 AM, Hongmei Li wrote:
>>> Thanks Hannes for your prompt response!
>>>
>>> We just encountered this issue two times in our product stability test so far,
>>> and my panic backtrace is the exactly same with the one reported here.
>>> I don't know how to reproduce the issue till now.
>>> I tried several method, unfortunately, I can not reproduce it by myself. :(
>>
>> We could reproduce it easily using our user-space tool that creates 1000
>> mac-vlans, configures them, dumps routing tables, etc. But, we could
>> only reproduce it when we had the ixgbe ports unplugged. If they
>> were properly connected to a switch, we did not see any crashes.
>>
>> My original email on 2/3/2014 has more details, and the thread that
>> follows has some info on debugging we did at the time.
>
> I just tried to reproduce the problem, disabling the port on a switch
> and setting up 1000 macvlans on a ixgbe, enabling ipv6 and dumping
> routing tables. Unluckily I had no success. :(
>
> Any more hints?
We are going to be running up to 20 concurrent scripts that
will be dumping routes & ips, and configuring ip addresses
and routes during bringup.
I don't have a simple stand-alone way to reproduce this,
but at least when we reported the problem is was very easy
for us to reproduce with our tool.
Maybe 20 scripts running in parallel that randomly configured and dumped routes
and ip addresses on random interfaces would do the trick?
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: BCM4313 & brcmsmac & 3.12: only semi-working?
From: Maximilian Engelhardt @ 2014-09-29 19:40 UTC (permalink / raw)
To: Arend van Spriel
Cc: Michael Tokarev, Seth Forshee, brcm80211-dev-list, linux-wireless,
netdev
In-Reply-To: <54296223.6090702@broadcom.com>
[-- Attachment #1: Type: text/plain, Size: 3930 bytes --]
On Monday 29 September 2014 15:44:03 Arend van Spriel wrote:
> On 09/26/14 17:20, Michael Tokarev wrote:
> > I can send it your way, -- guess it will be quite a bit costly,
> > but I don't have any use for it anyway (short of throwing it
> > away), and since I already spent significantly more money due
> > to all this (whole thinkpad plus ssds and several wifi adaptors),
> > this additional cost is just a small noize. But since that's
> > 2nd card in a row, maybe there's something else in there, the
> > prob is not in the card?
>
> Could be. Maybe some BIOS issue. Can you make some hi-res pictures of
> the card and email them to me? If it is identical to what I already have
> over here there is not much sense in sending it.
>
> Regards,
> Arend
Hi Arend,
I just saw this thread on linux-wireless and wanted to answer as it might be
of interest to you.
I also own a BCM4313 wireless network card. About a year ago I reported some
problems with reception strength which were then fixed after some time,
debugging and testing passed. At that time I also did some throughput testing,
but only had a 802.11g access-point to test. The results were not ideal, but
also not too bad. So at that time I thought the issues were all more or less
fixed and mostly fine. I also don't use wireless very much, so as long as things
do work somehow acceptable I probably don't notice any problems immediately.
So it comes that only about some month ago I noticed that the throughput I
measured with my 11g access-point (about half the rate than with an atheros
card on the same ap) is about the same on a 11n access-point where it should
be much faster. I didn't experience any stalls, but that may also be that I
didn't use the card enough to really notice them.
I always wanted to report a bug because of the low throughout, but never got
to it because of lack of time. I didn't want to provide a report saying just
it doesn't work or it's slow without any data about it and a description how
to reproduce it, as I think without this information a bug report is mostly
useless.
I also had a look at the kernel changelog of the brcmsm driver and notices
there was little to no activity lately. Because of this I also wasn't sure if
there is still someone interesting in fixing bugs for this device.
As I was annoyed by the bad support for this card I decided it would be more
easy and much less time consuming to simply buy another card than trying to
get this fixed. So I bought a BCM43228 card, because it also supports 5 GHz.
Only after it arrived I noticed that it was only supported by the 3.17+ kernel
(not so much of a problem) and that it only seems to work in 802.11g mode
(only slow speeds and no 5 GHz). At least I could use it in full 11g speeds,
so it was a improvement.
So I still don't have a card that does simply work. As I hope the missing
support for my BCM43228 will hopefully be added some time in the future it
probably would still be worth fixing the BCM4313 card as other users will also
benefit from it.
A friend of mine also has the same laptop than me and the same (or at least
very similar) wireless card. He has told me he has also problem with stalls
like Michael reported (if I remember the history of the thread correctly).
So I'm not really sure where I should go from here. I can try to provide some
debugging information as time permits, but I don't know how much time I will
have for this in the future. Of course ideally I want to use the BCM43228 card
with full support, as it can work on 5 GHz.
Currently the BCM43228 card is plugged into my laptop, but I want to avoid
swapping the cards more that very few times because the antenna connectors are
only designed for very few (un)plug cycles.
If it's of any information, my card is labeled BCM-BCM94313HMGB on the
sticker, the laptop where it was originally is a ThinkPad Edge E135.
Greetings,
Maxi
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* [IPROUTE2] [PATCH] add missing underscore to man page and example nf_mark ematch
From: Andy Furniss @ 2014-09-29 19:43 UTC (permalink / raw)
To: Linux Networking Developer Mailing List
The man page and the "fail" example are missing an underscore in the
nf_mark ematch.
eg.
tc filter add dev eth0 parent ffff: basic match 'meta(nfmark gt 24)'
classid 2:4
meta: unknown meta id
... >>meta(nfmark gt 24)<< ...
... meta(>>nfmark<< gt 24)...
Usage: meta(OBJECT { eq | lt | gt } OBJECT)
where: OBJECT := { META_ID | VALUE }
META_ID := id [ shift SHIFT ] [ mask MASK ]
Example: meta(nfmark gt 24)
meta(indev shift 1 eq "ppp")
meta(tcindex mask 0xf0 eq 0xf0)
For a list of meta identifiers, use meta(list).
Illegal "ematch"
meta(list) does correctly show nf_mark and the above test works with
nf_mark.
Signed-off-by: Andy Furniss adf.lists@gmail.com
diff --git a/man/man8/tc-ematch.8 b/man/man8/tc-ematch.8
index b9bf70c..4726673 100644
--- a/man/man8/tc-ematch.8
+++ b/man/man8/tc-ematch.8
@@ -113,7 +113,7 @@ The original interface (i.e. the device the packet
arrived on) is treated as the
# 'cmp(u16 at 3 layer 2 mask 0xff00 gt 20)'
-# 'meta(nfmark gt 24)' and 'meta(tcindex mask 0xf0 eq 0xf0)'
+# 'meta(nf_mark gt 24)' and 'meta(tcindex mask 0xf0 eq 0xf0)'
# 'nbyte("ababa" at 12 layer 1)'
diff --git a/tc/em_meta.c b/tc/em_meta.c
index fad6b12..b64f333 100644
--- a/tc/em_meta.c
+++ b/tc/em_meta.c
@@ -32,7 +32,7 @@ static void meta_print_usage(FILE *fd)
"where: OBJECT := { META_ID | VALUE }\n" \
" META_ID := id [ shift SHIFT ] [ mask MASK ]\n" \
"\n" \
- "Example: meta(nfmark gt 24)\n" \
+ "Example: meta(nf_mark gt 24)\n" \
" meta(indev shift 1 eq \"ppp\")\n" \
" meta(tcindex mask 0xf0 eq 0xf0)\n" \
"\n" \
^ permalink raw reply related
* Re: [PATCH] tun: make sure interface usage can not overflow
From: Kees Cook @ 2014-09-29 19:41 UTC (permalink / raw)
To: David Laight
Cc: linux-kernel@vger.kernel.org, David S. Miller, Jason Wang,
Zhi Yong Wu, Michael S. Tsirkin, Tom Herbert, Masatake YAMATO,
Xi Wang, stephen hemminger, netdev@vger.kernel.org
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D1749FC70@AcuExch.aculab.com>
On Mon, Sep 29, 2014 at 4:04 AM, David Laight <David.Laight@aculab.com> wrote:
> From: Kees Cook
>> This makes the size argument a const, since it is always populated by
>> the caller.
>
> There is almost no point making parameters 'const.
> ('const foo *' makes sense).
>
>> Additionally double-checks to make sure the copy_from_user
>> can never overflow, keeping CONFIG_DEBUG_STRICT_USER_COPY_CHECKS happy:
>>
>> In function 'copy_from_user',
>> inlined from '__tun_chr_ioctl' at drivers/net/tun.c:1871:7:
>> ... copy_from_user() buffer size is not provably correct
>
> If 'ifreq_len' could be too big then you want to error the ioctl, not panic.
> If it can't be too big you don't need the check.
The ifreq_len comes from the callers, and is the output of "sizeof"
which is const. Changing the function parameter to "const" means any
changes made in the future where the incoming value isn't const, the
compiler will throw a warning.
-Kees
--
Kees Cook
Chrome OS Security
^ permalink raw reply
* Re: [PATCH net-next] macvlan: add source mode
From: David Miller @ 2014-09-29 19:36 UTC (permalink / raw)
To: michael-dev; +Cc: netdev, projekt-wlan
In-Reply-To: <1411655468-485-1-git-send-email-michael-dev@fami-braun.de>
From: michael-dev@fami-braun.de
Date: Thu, 25 Sep 2014 16:31:08 +0200
> From: Michael Braun <michael-dev@fami-braun.de>
>
> This patch adds a new mode of operation to macvlan, called "source".
> It allows one to set a list of allowed mac address, which is used
> to match against source mac address from received frames on underlying
> interface.
> This enables creating mac based VLAN associations, instead of standard
> port or tag based. The feature is useful to deploy 802.1x mac based
> behavior, where drivers of underlying interfaces doesn't allows that.
>
> Configuration is done through the netlink interface using e.g.:
> ip link add link eth0 name macvlan0 type macvlan mode source
> ip link add link eth0 name macvlan1 type macvlan mode source
> ip link set link dev macvlan0 type macvlan macaddr add 00:11:11:11:11:11
> ip link set link dev macvlan0 type macvlan macaddr add 00:22:22:22:22:22
> ip link set link dev macvlan0 type macvlan macaddr add 00:33:33:33:33:33
> ip link set link dev macvlan1 type macvlan macaddr add 00:33:33:33:33:33
> ip link set link dev macvlan1 type macvlan macaddr add 00:44:44:44:44:44
>
> This allows clients with MAC addresses 00:11:11:11:11:11,
> 00:22:22:22:22:22 to be part of only VLAN associated with macvlan0
> interface. Clients with MAC addresses 00:44:44:44:44:44 with only VLAN
> associated with macvlan1 interface. And client with MAC address
> 00:33:33:33:33:33 to be associated with both VLANs.
>
> Based on work of Stefan Gula <steweg@gmail.com>
>
> Signed-off-by: Michael Braun <michael-dev@fami-braun.de>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH v3 5/7] net: Add GSO support for UDP tunnels with checksum
From: Or Gerlitz @ 2014-09-29 19:33 UTC (permalink / raw)
To: Tom Herbert; +Cc: Or Gerlitz, David Miller, netdev@vger.kernel.org
In-Reply-To: <CA+mtBx9L3axScgW=jm5yxLNgvdNCCG0X2TcDrHjPrV_gSxujpg@mail.gmail.com>
On Mon, Sep 29, 2014 at 7:11 AM, Tom Herbert <therbert@google.com> wrote:
> On Sat, Sep 27, 2014 at 1:39 PM, Or Gerlitz <or.gerlitz@gmail.com> wrote:
>> On Sat, Sep 27, 2014 at 12:57 AM, Tom Herbert <therbert@google.com> wrote:
>>> On Fri, Sep 26, 2014 at 2:05 PM, Or Gerlitz <or.gerlitz@gmail.com> wrote:
>>>> On Thu, Jun 5, 2014 at 3:20 AM, Tom Herbert <therbert@google.com> wrote:
>>
>>>>> Added a new netif feature for GSO_UDP_TUNNEL_CSUM. This indicates
>>>>> that a device is capable of computing the UDP checksum in the
>>>>> encapsulating header of a UDP tunnel.
>>
>>>> Do we have upstream driver that supports GSO_UDP_TUNNEL_CSUM? did you
>>>> had such driver/patch while doing this patches? when a driver
>>>> advertizes that bit, should they look over the xmit path on the new
>>>> encap_hdr_csum bit?
>>
>>> No, no, and encap_hdr_csum should only be set with
>>> SKB_GSO_UDP_TUNNEL_CSUM or SKB_GSO_GRE_CSUM.
>>
>> I'm still trying to dig the bigger picture w.r.t checksum of the outer
>> UDP packet from the patches -- if I got it right, once these patches
>> were picked upstream, there's a scheme where the kernel either
>> computes this checksum or let the device do that - when they advertize
>> NETIF_F_GSO_YYY_CSUM and in that case
>> (skb->encap_hdr_csum == true) should be interpreted as a directive to
>> do that, right?
>
> NETIF_F_GSO_UDP_CSUM does indicate that device is capable of setting
> outer UDP checksum. gso_type in an skbuff indicates to driver that the
> outer checksum needs to be computed (e.g. SKB_GSO_UDP_TUNNEL_CSUM).
> skb->encap_hdr_csum is only used in software GSO, drivers should not
> care about this.
>
>>
>> So what happens when the device isn't capable to compute that checksum
>> (e.g they don't set _GSO_UDP_TUNNEL_CSUM) but they do advertize the
>> GSO_UDP_TUNNEL bit?
>>
> Then for tunnels configured to use outer checksum software GSO would be used.
I see. Can you point on the code that does this job, i.e goes to SW
GSO unless the driver advertizes both bits
Also, I saw some weird behavior recently (which I haven't fully nailed
down, so didn't rush to post that) when I tested vxlan between
node/NIC that supported offloads to another node/NIC which doesn't.
That is packets in one direction where flying w. udp csum = 0 and in
the other direction with udp csum != 0, did you run such test? does it
work for you?
>> I was worried that we can run into this scheme - the stack computes
>> the outer checksum for the giant 64K UDP chunck that encapsulate a 64K
>> TCP segment, but when the NIC will issue the segmentation, they will
>> likely to just repeat ~40 times (64K/1500) the original udp checksum
>> for the packets they send, which will be treated as bad checksum on
>> the receiving end, bad.
>>
> This shouldn't happen since the driver would not advertise
> SKB_GSO_UDP_TUNNEL_CSUM.
>
> We can add some comments in skbuff.h to clarify some of the GSO types.
that will be very helpful
>>> find . -name '*.[ch]' -exec fgrep -l GSO_UDP_TUNNEL {} \;
>>> returns
>>> ./ethernet/intel/i40e/i40e_main.c
>>> ./ethernet/broadcom/bnx2x/bnx2x_main.c
>>> ./ethernet/qlogic/qlcnic/qlcnic_main.c
>>> ./ethernet/mellanox/mlx4/en_netdev.c
>>> ./ethernet/emulex/benet/be_main.c
>> cool, I see here four 40Gbs NICs that support GSO offloading of VXLAN
>> traffic, each of them can serve you for testing new developments you
>> do in that area.
any thoughts here?
^ permalink raw reply
* Re: [PATCH net] ematch: Fix matching of inverted containers.
From: David Miller @ 2014-09-29 19:31 UTC (permalink / raw)
To: ignacy.gawedzki; +Cc: netdev
In-Reply-To: <20140924163839.GA6925@zenon.in.qult.net>
From: Ignacy Gawędzki <ignacy.gawedzki@green-communications.fr>
Date: Wed, 24 Sep 2014 18:38:39 +0200
> Negated expressions and sub-expressions need to have their flags checked for
> TCF_EM_INVERT and their result negated accordingly.
>
> Signed-off-by: Ignacy Gawędzki <ignacy.gawedzki@green-communications.fr>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH net-next v4] bonding: make global bonding stats more reliable
From: David Miller @ 2014-09-29 19:30 UTC (permalink / raw)
To: gospo; +Cc: netdev, j.vosburgh, vfalico, nikolay
In-Reply-To: <1411958077-13160-1-git-send-email-gospo@cumulusnetworks.com>
Date: Sun, 28 Sep 2014 22:34:37 -0400
Andy, _please_ fix the date on your computer.
Thank you.
^ permalink raw reply
* Re: [PATCH][net-next] ipv4: unnecessary to set err on no_route path
From: Julian Anastasov @ 2014-09-29 19:30 UTC (permalink / raw)
To: roy.qing.li; +Cc: netdev
In-Reply-To: <1411982198-17416-1-git-send-email-roy.qing.li@gmail.com>
Hello,
On Mon, 29 Sep 2014, roy.qing.li@gmail.com wrote:
> From: Li RongQing <roy.qing.li@gmail.com>
>
> When the code skips to no_route label, it will skip to local_input at last,
> then err will be reset on the local_input path before exit function.
But local_input saves -err into rth->dst.error,
the places you change provided more-specific error code.
> Signed-off-by: Li RongQing <roy.qing.li@gmail.com>
> ---
> net/ipv4/route.c | 11 ++++-------
> 1 file changed, 4 insertions(+), 7 deletions(-)
>
> diff --git a/net/ipv4/route.c b/net/ipv4/route.c
> index d4bd68d..403914b 100644
> --- a/net/ipv4/route.c
> +++ b/net/ipv4/route.c
> @@ -1704,11 +1704,9 @@ static int ip_route_input_slow(struct sk_buff *skb, __be32 daddr, __be32 saddr,
> fl4.daddr = daddr;
> fl4.saddr = saddr;
> err = fib_lookup(net, &fl4, &res);
> - if (err != 0) {
> - if (!IN_DEV_FORWARD(in_dev))
> - err = -EHOSTUNREACH;
> + if (err != 0)
> goto no_route;
> - }
> +
>
> if (res.type == RTN_BROADCAST)
> goto brd_input;
> @@ -1721,10 +1719,9 @@ static int ip_route_input_slow(struct sk_buff *skb, __be32 daddr, __be32 saddr,
> goto local_input;
> }
>
> - if (!IN_DEV_FORWARD(in_dev)) {
> - err = -EHOSTUNREACH;
> + if (!IN_DEV_FORWARD(in_dev))
> goto no_route;
> - }
> +
> if (res.type != RTN_UNICAST)
> goto martian_destination;
>
> --
> 1.7.10.4
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* Re: [PATCHv7 net-next 1/4] sunvnet: upgrade to VIO protocol version 1.6
From: David Miller @ 2014-09-29 19:29 UTC (permalink / raw)
To: david.stevens; +Cc: netdev, sowmini.varadhan, Raghuram.Kothakota
In-Reply-To: <54299BCD.7050807@oracle.com>
From: David L Stevens <david.stevens@oracle.com>
Date: Mon, 29 Sep 2014 13:50:05 -0400
> This patch upgrades the sunvnet driver to support VIO protocol version 1.6.
> In particular, it adds per-port MTU negotiation, allowing MTUs other than
> ETH_FRAMELEN with ports using newer VIO protocol versions.
>
> Signed-off-by: David L Stevens <david.stevens@oracle.com>
Just an FYI, once I apply this series I'm going to extract the
arch/sparc parts and apply that also to the sparc-next tree in order
to deal with the pending block driver patches from Dwight Engen and
Allan Pais.
^ permalink raw reply
* Re: [PATCHv7 net-next 2/4] sunvnet: make transmit path zero-copy in the kernel
From: David Miller @ 2014-09-29 19:28 UTC (permalink / raw)
To: david.stevens; +Cc: netdev, sowmini.varadhan, Raghuram.Kothakota
In-Reply-To: <54299A87.80305@oracle.com>
From: David L Stevens <david.stevens@oracle.com>
Date: Mon, 29 Sep 2014 13:44:39 -0400
> @@ -788,12 +874,16 @@ static int vnet_start_xmit(struct sk_buff *skb, struct net_device *dev)
> struct vio_net_desc *d;
> unsigned long flags;
> unsigned int len;
> - void *tx_buf;
> - int i, err;
> + struct sk_buff *freeskbs = NULL;
> + int i, err, txi;
> + void *start = NULL;
> + int nlen = 0;
>
> if (unlikely(!port))
> goto out_dropped;
>
> + skb = vnet_skb_shape(skb, &start, &nlen);
> +
> spin_lock_irqsave(&port->vio.lock, flags);
>
> dr = &port->vio.drings[VIO_DRIVER_TX_RING];
vnet_skb_shape() can return NULL, I don't think you're handling that case
at all and are blindly derefencing a potentially NULL skb pointer.
^ permalink raw reply
* [PATCH net-next v4] bonding: make global bonding stats more reliable
From: Andy Gospodarek @ 2014-09-29 2:34 UTC (permalink / raw)
To: netdev; +Cc: j.vosburgh, vfalico, nikolay
As the code stands today, bonding stats are based simply on the stats
from the member interfaces. If a member was to be removed from a bond,
the stats would instantly drop. This would be confusing to an admin
would would suddonly see interface stats drop while traffic is still
flowing.
In addition to preventing the stats drops mentioned above, new members
will now be added to the bond and only traffic received after the member
was added to the bond will be counted as part of bonding stats. Bonding
counters will also be updated when any slaves are dropped to make sure
the reported stats are reliable.
v2: Changes suggested by Nik to properly allocate/free stats memory.
v3: Properly destroy workqueue and fix netlink configuration path.
v4: Moved cached stats into bonding and slave structs as there does not
seem to be a complexity/performance benefit to using alloc'd memory vs
in-struct memory.
Signed-off-by: Andy Gospodarek <gospo@cumulusnetworks.com>
---
drivers/net/bonding/bond_main.c | 68 ++++++++++++++++++++++++-----------------
drivers/net/bonding/bonding.h | 3 ++
2 files changed, 43 insertions(+), 28 deletions(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 5390475..c2adc27 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -208,6 +208,8 @@ static int lacp_fast;
static int bond_init(struct net_device *bond_dev);
static void bond_uninit(struct net_device *bond_dev);
+static struct rtnl_link_stats64 *bond_get_stats(struct net_device *bond_dev,
+ struct rtnl_link_stats64 *stats);
/*---------------------------- General routines -----------------------------*/
@@ -1344,6 +1346,8 @@ int bond_enslave(struct net_device *bond_dev, struct net_device *slave_dev)
}
slave_dev->priv_flags |= IFF_BONDING;
+ /* initialize slave stats */
+ dev_get_stats(new_slave->dev, &new_slave->slave_stats);
if (bond_is_lb(bond)) {
/* bond_alb_init_slave() must be called before all other stages since
@@ -1652,6 +1656,9 @@ static int __bond_release_one(struct net_device *bond_dev,
bond_sysfs_slave_del(slave);
+ /* recompute stats just before removing the slave */
+ bond_get_stats(bond->dev, &bond->bond_stats);
+
bond_upper_dev_unlink(bond_dev, slave_dev);
/* unregister rx_handler early so bond_handle_frame wouldn't be called
* for this slave anymore.
@@ -3085,38 +3092,43 @@ static struct rtnl_link_stats64 *bond_get_stats(struct net_device *bond_dev,
struct list_head *iter;
struct slave *slave;
- memset(stats, 0, sizeof(*stats));
+ memcpy(stats, &bond->bond_stats, sizeof(*stats));
bond_for_each_slave(bond, slave, iter) {
const struct rtnl_link_stats64 *sstats =
dev_get_stats(slave->dev, &temp);
-
- stats->rx_packets += sstats->rx_packets;
- stats->rx_bytes += sstats->rx_bytes;
- stats->rx_errors += sstats->rx_errors;
- stats->rx_dropped += sstats->rx_dropped;
-
- stats->tx_packets += sstats->tx_packets;
- stats->tx_bytes += sstats->tx_bytes;
- stats->tx_errors += sstats->tx_errors;
- stats->tx_dropped += sstats->tx_dropped;
-
- stats->multicast += sstats->multicast;
- stats->collisions += sstats->collisions;
-
- stats->rx_length_errors += sstats->rx_length_errors;
- stats->rx_over_errors += sstats->rx_over_errors;
- stats->rx_crc_errors += sstats->rx_crc_errors;
- stats->rx_frame_errors += sstats->rx_frame_errors;
- stats->rx_fifo_errors += sstats->rx_fifo_errors;
- stats->rx_missed_errors += sstats->rx_missed_errors;
-
- stats->tx_aborted_errors += sstats->tx_aborted_errors;
- stats->tx_carrier_errors += sstats->tx_carrier_errors;
- stats->tx_fifo_errors += sstats->tx_fifo_errors;
- stats->tx_heartbeat_errors += sstats->tx_heartbeat_errors;
- stats->tx_window_errors += sstats->tx_window_errors;
- }
+ struct rtnl_link_stats64 *pstats = &slave->slave_stats;
+
+ stats->rx_packets += sstats->rx_packets - pstats->rx_packets;
+ stats->rx_bytes += sstats->rx_bytes - pstats->rx_bytes;
+ stats->rx_errors += sstats->rx_errors - pstats->rx_errors;
+ stats->rx_dropped += sstats->rx_dropped - pstats->rx_dropped;
+
+ stats->tx_packets += sstats->tx_packets - pstats->tx_packets;;
+ stats->tx_bytes += sstats->tx_bytes - pstats->tx_bytes;
+ stats->tx_errors += sstats->tx_errors - pstats->tx_errors;
+ stats->tx_dropped += sstats->tx_dropped - pstats->tx_dropped;
+
+ stats->multicast += sstats->multicast - pstats->multicast;
+ stats->collisions += sstats->collisions - pstats->collisions;
+
+ stats->rx_length_errors += sstats->rx_length_errors - pstats->rx_length_errors;
+ stats->rx_over_errors += sstats->rx_over_errors - pstats->rx_over_errors;
+ stats->rx_crc_errors += sstats->rx_crc_errors - pstats->rx_crc_errors;
+ stats->rx_frame_errors += sstats->rx_frame_errors - pstats->rx_frame_errors;
+ stats->rx_fifo_errors += sstats->rx_fifo_errors - pstats->rx_fifo_errors;
+ stats->rx_missed_errors += sstats->rx_missed_errors - pstats->rx_missed_errors;
+
+ stats->tx_aborted_errors += sstats->tx_aborted_errors - pstats->tx_aborted_errors;
+ stats->tx_carrier_errors += sstats->tx_carrier_errors - pstats->tx_carrier_errors;
+ stats->tx_fifo_errors += sstats->tx_fifo_errors - pstats->tx_fifo_errors;
+ stats->tx_heartbeat_errors += sstats->tx_heartbeat_errors - pstats->tx_heartbeat_errors;
+ stats->tx_window_errors += sstats->tx_window_errors - pstats->tx_window_errors;
+
+ /* save off the slave stats for the next run */
+ memcpy(pstats, sstats, sizeof(*sstats));
+ }
+ memcpy(&bond->bond_stats, stats, sizeof(*stats));
return stats;
}
diff --git a/drivers/net/bonding/bonding.h b/drivers/net/bonding/bonding.h
index 6140bf0..57917e6 100644
--- a/drivers/net/bonding/bonding.h
+++ b/drivers/net/bonding/bonding.h
@@ -24,6 +24,7 @@
#include <linux/inetdevice.h>
#include <linux/etherdevice.h>
#include <linux/reciprocal_div.h>
+#include <linux/if_link.h>
#include "bond_3ad.h"
#include "bond_alb.h"
@@ -175,6 +176,7 @@ struct slave {
struct netpoll *np;
#endif
struct kobject kobj;
+ struct rtnl_link_stats64 slave_stats;
};
/*
@@ -224,6 +226,7 @@ struct bonding {
/* debugging support via debugfs */
struct dentry *debug_dir;
#endif /* CONFIG_DEBUG_FS */
+ struct rtnl_link_stats64 bond_stats;
};
#define bond_slave_get_rcu(dev) \
--
1.9.3
^ permalink raw reply related
* Re: [PATCH net] gro: fix aggregation for skb using frag_list
From: David Miller @ 2014-09-29 19:19 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, erezsh
In-Reply-To: <1412012069.30721.31.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 29 Sep 2014 10:34:29 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> In commit 8a29111c7ca6 ("net: gro: allow to build full sized skb")
> I added a regression for linear skb that traditionally force GRO
> to use the frag_list fallback.
>
> Erez Shitrit found that at most two segments were aggregated and
> the "if (skb_gro_len(p) != pinfo->gso_size)" test was failing.
>
> This is because pinfo at this spot still points to the last skb in the
> chain, instead of the first one, where we find the correct gso_size
> information.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Fixes: 8a29111c7ca6 ("net: gro: allow to build full sized skb")
> Reported-by: Erez Shitrit <erezsh@mellanox.com>
Applied and queued up for -stable, thanks Eric.
^ permalink raw reply
* Re: [PATCH net-next] tcp: abort orphan sockets stalling on zero window probes
From: Yuchung Cheng @ 2014-09-29 19:17 UTC (permalink / raw)
To: David Miller; +Cc: Eric Dumazet, Andrey Dmitrov, Neal Cardwell, netdev
In-Reply-To: <20140926.155611.954320324745536887.davem@davemloft.net>
On Fri, Sep 26, 2014 at 12:56 PM, David Miller <davem@davemloft.net> wrote:
> From: Yuchung Cheng <ycheng@google.com>
> Date: Mon, 22 Sep 2014 20:52:13 -0700
>
>> -
>> + if (!alive && icsk->icsk_backoff >= max_probes)
>> + goto abort;
>> if (tcp_out_of_resources(sk, alive || icsk->icsk_probes_out <= max_probes))
>> return;
>
> This new logic means that the second argument to tcp_out_of_resources()
> will always be 'true'.
>
> Please make that explicit, because the code is confusing otherwise.
>
> Also perhaps target this for the 'net' tree?
Sure I'll clear up the patch.
Net-next is probably a better target b/c it's more of a feature patch.
It also changes TCP_USER_TIMEOUT semantics slightly.
Thanks!
>
> Thanks.
^ permalink raw reply
* Re: [PATCH net-next 3/4] sunvnet: allow admin to set sunvnet MTU
From: David L Stevens @ 2014-09-29 19:13 UTC (permalink / raw)
To: David Miller; +Cc: netdev, sowmini.varadhan, Raghuram.Kothakota
In-Reply-To: <20140929.145839.1840433438051963991.davem@davemloft.net>
On 09/29/2014 02:58 PM, David Miller wrote:
>
> More patch corruption.
>
Yes, sorry about that. I lost my .gitconfig in a crash and the backup
wasn't quite right; fixed, and the ones with subject "PATCHv7" I believe
are correct.
+-DLS
^ permalink raw reply
* Re: IPv6 FIB related crash with MACVLANs in 3.9.11+ kernel.
From: Hannes Frederic Sowa @ 2014-09-29 19:03 UTC (permalink / raw)
To: Ben Greear; +Cc: Hongmei Li, netdev
In-Reply-To: <5429A886.1040809@candelatech.com>
On Mo, 2014-09-29 at 11:44 -0700, Ben Greear wrote:
> On 09/29/2014 11:15 AM, Hongmei Li wrote:
> > Thanks Hannes for your prompt response!
> >
> > We just encountered this issue two times in our product stability test so far,
> > and my panic backtrace is the exactly same with the one reported here.
> > I don't know how to reproduce the issue till now.
> > I tried several method, unfortunately, I can not reproduce it by myself. :(
>
> We could reproduce it easily using our user-space tool that creates 1000
> mac-vlans, configures them, dumps routing tables, etc. But, we could
> only reproduce it when we had the ixgbe ports unplugged. If they
> were properly connected to a switch, we did not see any crashes.
>
> My original email on 2/3/2014 has more details, and the thread that
> follows has some info on debugging we did at the time.
I just tried to reproduce the problem, disabling the port on a switch
and setting up 1000 macvlans on a ixgbe, enabling ipv6 and dumping
routing tables. Unluckily I had no success. :(
Any more hints?
Bye,
Hannes
^ permalink raw reply
* Re: 3.17-rc1 oops during network interface configuration
From: Eric Dumazet @ 2014-09-29 19:00 UTC (permalink / raw)
To: Chuck Lever
Cc: Or Gerlitz, Govindarajulu Varadarajan, David S. Miller,
netdev-u79uwXL29TY76Z2rM5mHXA, LKML Kernel, linux-rdma,
Bart Van Assche, Saeed Mahameed, Tal Alon, Yevgeny Petrilin,
Roland Dreier
In-Reply-To: <6C43129E-4365-4BEF-ADAD-963B8F386789-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
On Mon, 2014-09-29 at 14:52 -0400, Chuck Lever wrote:
> Is there a bugzilla report filed for this issue? Has there been any progress
> towards a fix?
This is fixed in Linus tree.
http://git.kernel.org/cgit/linux/kernel/git/davem/net.git/commit/?id=257117862634d89de33fec74858b1a0ba5ab444b
http://git.kernel.org/cgit/linux/kernel/git/davem/net.git/commit/?id=b49fe36208b45f76dfbcfcd3afd952a33fa9f5ce
--
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
* Re: [PATCH net-next] net: cleanup and document skb fclone layout
From: David Miller @ 2014-09-29 18:59 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1412011416.30721.24.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 29 Sep 2014 10:23:36 -0700
> On Sat, 2014-09-27 at 16:25 -0700, Eric Dumazet wrote:
>> From: Eric Dumazet <edumazet@google.com>
>>
>> Lets use a proper structure to clearly document and implement
>> skb fast clones.
>>
>> Then, we might experiment more easily alternative layouts.
>>
>> This patch adds a new skb_fclone_busy() helper, used by tcp and xfrm.
>>
>> Signed-off-by: Eric Dumazet <edumazet@google.com>
>> ---
>> include/linux/skbuff.h | 25 ++++++++++++++++++++++
>> net/core/skbuff.c | 44 +++++++++++++++++++--------------------
>> net/ipv4/tcp_output.c | 5 ----
>> net/xfrm/xfrm_policy.c | 4 ---
>> 4 files changed, 49 insertions(+), 29 deletions(-)
>
>
> I'll rebase this patch and send a v2.
Thanks.
^ permalink raw reply
* Re: [PATCH net-next 3/4] sunvnet: allow admin to set sunvnet MTU
From: David Miller @ 2014-09-29 18:58 UTC (permalink / raw)
To: david.stevens; +Cc: netdev, sowmini.varadhan, Raghuram.Kothakota
In-Reply-To: <5429940D.4040500@oracle.com>
From: David L Stevens <david.stevens@oracle.com>
Date: Mon, 29 Sep 2014 13:17:01 -0400
> @@ -884,6 +884,9 @@ static int vnet_start_xmit(struct sk_buff *skb, struct net_device *dev)
> skb = vnet_skb_shape(skb, &start, &nlen);
> + if (skb->len > port->rmtu)
> + goto out_dropped;
> +
> spin_lock_irqsave(&port->vio.lock, flags);
More patch corruption.
^ 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