* Re: [PATCHv1 net] xen-netback: support frontends without feature-rx-notify again
From: Wei Liu @ 2014-12-18 11:51 UTC (permalink / raw)
To: David Vrabel; +Cc: netdev, xen-devel, Ian Campbell, Wei Liu
In-Reply-To: <1418901186-14478-1-git-send-email-david.vrabel@citrix.com>
On Thu, Dec 18, 2014 at 11:13:06AM +0000, David Vrabel wrote:
> Commit bc96f648df1bbc2729abbb84513cf4f64273a1f1 (xen-netback: make
> feature-rx-notify mandatory) incorrectly assumed that there were no
> frontends in use that did not support this feature. But the frontend
> driver in MiniOS does not and since this is used by (qemu) stubdoms,
> these stopped working.
>
> Netback sort of works as-is in this mode except:
>
> - If there are no Rx requests and the internal Rx queue fills, only
> the drain timeout will wake the thread. The default drain timeout
> of 10 s would give unacceptable pauses.
>
> - If an Rx stall was detected and the internal Rx queue is drained,
> then the Rx thread would never wake.
>
> Handle these two cases (when feature-rx-notify is disabled) by:
>
> - Reducing the drain timeout to 30 ms.
>
> - Disabling Rx stall detection.
>
> Reported-by: John <jw@nuclearfallout.net>
> Tested-by: John <jw@nuclearfallout.net>
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Reviewed-by: Wei Liu <wei.liu2@citrix.com>
^ permalink raw reply
* Re: [RFC PATCH net-next v2 1/1] net: Support for switch port configuration
From: Thomas Graf @ 2014-12-18 11:41 UTC (permalink / raw)
To: Varlese, Marco
Cc: netdev@vger.kernel.org, Fastabend, John R, Jiri Pirko,
roopa@cumulusnetworks.com, sfeldma@gmail.com,
linux-kernel@vger.kernel.org
In-Reply-To: <C4896FB061E7DE4AAC93031BDCA044B104AD7B82@IRSMSX108.ger.corp.intel.com>
On 12/18/14 at 11:29am, Varlese, Marco wrote:
> diff --git a/include/uapi/linux/if_link.h b/include/uapi/linux/if_link.h
> index f7d0d2d..19cb51a 100644
> --- a/include/uapi/linux/if_link.h
> +++ b/include/uapi/linux/if_link.h
> @@ -146,6 +146,7 @@ enum {
> IFLA_PHYS_PORT_ID,
> IFLA_CARRIER_CHANGES,
> IFLA_PHYS_SWITCH_ID,
> + IFLA_SWITCH_PORT_CFG,
> __IFLA_MAX
> };
Needs an entry in ifla_policy[]
[IFLA_SWITCH_PORT_CFG] = { .type = NLA_NESTED },
> @@ -603,4 +604,18 @@ enum {
>
> #define IFLA_HSR_MAX (__IFLA_HSR_MAX - 1)
>
> +/* Switch Port Attributes section */
> +
> +enum {
> + IFLA_ATTR_UNSPEC,
> + IFLA_ATTR_LEARNING,
> + IFLA_ATTR_LOOPBACK,
> + IFLA_ATTR_BCAST_FLOODING,
> + IFLA_ATTR_UCAST_FLOODING,
> + IFLA_ATTR_MCAST_FLOODING,
> + __IFLA_ATTR_MAX
> +};
> +
> +#define IFLA_ATTR_MAX (__IFLA_ATTR_MAX - 1)
Change the prefix to IFLA_SW_* since it's switch specific?
>
> +#ifdef CONFIG_NET_SWITCHDEV
> +static int do_setswcfg(struct net_device *dev, struct nlattr *attr)
> +{
> + int rem, err = -EINVAL;
> + struct nlattr *v;
> + const struct net_device_ops *ops = dev->netdev_ops;
> +
> + nla_for_each_nested(v, attr, rem) {
> + u32 op = nla_type(v);
> + u64 value = 0;
> +
> + switch (op) {
> + case IFLA_ATTR_LEARNING:
> + case IFLA_ATTR_LOOPBACK:
> + case IFLA_ATTR_BCAST_FLOODING:
> + case IFLA_ATTR_UCAST_FLOODING:
> + case IFLA_ATTR_MCAST_FLOODING: {
> + if (nla_len(v) < sizeof(value)) {
> + err = -EINVAL;
> + break;
> + }
You should validate the message before you start applying the
changes. Otherwise if the 3rd attribute is too short you've already
applied some changes and the user has not idea how much has been
applied.
nla_parse_nested() can help here.
> +
> + value = nla_get_u64(v);
> + err = ops->ndo_switch_port_set_cfg(dev,
> + op,
> + value);
This avoids having individual ndos but wastes a lot of space in the
Netlink message. Not a problem when setting configuration but you
likely want to dump these attributes as well and we need 12 bytes
for each attribute even though some are merely flags which could fit
in 4 bytes.
> static int do_setvfinfo(struct net_device *dev, struct nlattr *attr)
> {
> int rem, err = -EINVAL;
> @@ -1740,6 +1780,20 @@ static int do_setlink(const struct sk_buff *skb,
> status |= DO_SETLINK_NOTIFY;
> }
> }
> +#ifdef CONFIG_NET_SWITCHDEV
> + if (tb[IFLA_SWITCH_PORT_CFG]) {
> + err = -EOPNOTSUPP;
> + if (!ops->ndo_switch_port_set_cfg)
> + goto errout;
> + if (!ops->ndo_switch_parent_id_get)
> + goto errout;
> + err = do_setswcfg(dev, tb[IFLA_SWITCH_PORT_CFG]);
> + if (err < 0)
> + goto errout;
> +
> + status |= DO_SETLINK_NOTIFY;
> + }
> +#endif
Should return -EOPNOTSUPP if IFLA_SWITCH_PORT_CFG is provided but
CONFIG_NET_SWITCHDEV is not set.
^ permalink raw reply
* [RFC PATCH net-next v2 1/1] net: Support for switch port configuration
From: Varlese, Marco @ 2014-12-18 11:29 UTC (permalink / raw)
To: netdev@vger.kernel.org
Cc: Fastabend, John R, Thomas Graf, Jiri Pirko,
roopa@cumulusnetworks.com, sfeldma@gmail.com,
linux-kernel@vger.kernel.org
From: Marco Varlese <marco.varlese@intel.com>
Switch hardware offers a list of attributes that are configurable
on a per port basis.
This patch provides a mechanism to configure switch ports by adding
an NDO for setting specific values to specific attributes.
There will be a separate patch that adds the "get" functionality via
another NDO and another patch that extends iproute2 to call the two
new NDOs.
Signed-off-by: Marco Varlese <marco.varlese@intel.com>
---
include/linux/netdevice.h | 5 ++++
include/uapi/linux/if_link.h | 15 ++++++++++++
net/core/rtnetlink.c | 54 ++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 74 insertions(+)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index c31f74d..4881c7b 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -1027,6 +1027,9 @@ typedef u16 (*select_queue_fallback_t)(struct net_device *dev,
* int (*ndo_switch_port_stp_update)(struct net_device *dev, u8 state);
* Called to notify switch device port of bridge port STP
* state change.
+ * int (*ndo_switch_port_set_cfg)(struct net_device *dev,
+ * u32 attr, u64 value);
+ * Called to set specific switch ports attributes.
*/
struct net_device_ops {
int (*ndo_init)(struct net_device *dev);
@@ -1185,6 +1188,8 @@ struct net_device_ops {
struct netdev_phys_item_id *psid);
int (*ndo_switch_port_stp_update)(struct net_device *dev,
u8 state);
+ int (*ndo_switch_port_set_cfg)(struct net_device *dev,
+ u32 attr, u64 value);
#endif
};
diff --git a/include/uapi/linux/if_link.h b/include/uapi/linux/if_link.h
index f7d0d2d..19cb51a 100644
--- a/include/uapi/linux/if_link.h
+++ b/include/uapi/linux/if_link.h
@@ -146,6 +146,7 @@ enum {
IFLA_PHYS_PORT_ID,
IFLA_CARRIER_CHANGES,
IFLA_PHYS_SWITCH_ID,
+ IFLA_SWITCH_PORT_CFG,
__IFLA_MAX
};
@@ -603,4 +604,18 @@ enum {
#define IFLA_HSR_MAX (__IFLA_HSR_MAX - 1)
+/* Switch Port Attributes section */
+
+enum {
+ IFLA_ATTR_UNSPEC,
+ IFLA_ATTR_LEARNING,
+ IFLA_ATTR_LOOPBACK,
+ IFLA_ATTR_BCAST_FLOODING,
+ IFLA_ATTR_UCAST_FLOODING,
+ IFLA_ATTR_MCAST_FLOODING,
+ __IFLA_ATTR_MAX
+};
+
+#define IFLA_ATTR_MAX (__IFLA_ATTR_MAX - 1)
+
#endif /* _UAPI_LINUX_IF_LINK_H */
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index eaa057f..c0d1c45 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -1389,6 +1389,46 @@ static int validate_linkmsg(struct net_device *dev, struct nlattr *tb[])
return 0;
}
+#ifdef CONFIG_NET_SWITCHDEV
+static int do_setswcfg(struct net_device *dev, struct nlattr *attr)
+{
+ int rem, err = -EINVAL;
+ struct nlattr *v;
+ const struct net_device_ops *ops = dev->netdev_ops;
+
+ nla_for_each_nested(v, attr, rem) {
+ u32 op = nla_type(v);
+ u64 value = 0;
+
+ switch (op) {
+ case IFLA_ATTR_LEARNING:
+ case IFLA_ATTR_LOOPBACK:
+ case IFLA_ATTR_BCAST_FLOODING:
+ case IFLA_ATTR_UCAST_FLOODING:
+ case IFLA_ATTR_MCAST_FLOODING: {
+ if (nla_len(v) < sizeof(value)) {
+ err = -EINVAL;
+ break;
+ }
+
+ value = nla_get_u64(v);
+ err = ops->ndo_switch_port_set_cfg(dev,
+ op,
+ value);
+ break;
+ }
+ default:
+ err = -EINVAL;
+ break;
+ }
+ if (err)
+ break;
+ }
+ return err;
+}
+
+#endif
+
static int do_setvfinfo(struct net_device *dev, struct nlattr *attr)
{
int rem, err = -EINVAL;
@@ -1740,6 +1780,20 @@ static int do_setlink(const struct sk_buff *skb,
status |= DO_SETLINK_NOTIFY;
}
}
+#ifdef CONFIG_NET_SWITCHDEV
+ if (tb[IFLA_SWITCH_PORT_CFG]) {
+ err = -EOPNOTSUPP;
+ if (!ops->ndo_switch_port_set_cfg)
+ goto errout;
+ if (!ops->ndo_switch_parent_id_get)
+ goto errout;
+ err = do_setswcfg(dev, tb[IFLA_SWITCH_PORT_CFG]);
+ if (err < 0)
+ goto errout;
+
+ status |= DO_SETLINK_NOTIFY;
+ }
+#endif
err = 0;
errout:
--
1.8.5.3
^ permalink raw reply related
* [PATCHv1 net] xen-netback: support frontends without feature-rx-notify again
From: David Vrabel @ 2014-12-18 11:13 UTC (permalink / raw)
To: netdev; +Cc: David Vrabel, xen-devel, Ian Campbell, Wei Liu
Commit bc96f648df1bbc2729abbb84513cf4f64273a1f1 (xen-netback: make
feature-rx-notify mandatory) incorrectly assumed that there were no
frontends in use that did not support this feature. But the frontend
driver in MiniOS does not and since this is used by (qemu) stubdoms,
these stopped working.
Netback sort of works as-is in this mode except:
- If there are no Rx requests and the internal Rx queue fills, only
the drain timeout will wake the thread. The default drain timeout
of 10 s would give unacceptable pauses.
- If an Rx stall was detected and the internal Rx queue is drained,
then the Rx thread would never wake.
Handle these two cases (when feature-rx-notify is disabled) by:
- Reducing the drain timeout to 30 ms.
- Disabling Rx stall detection.
Reported-by: John <jw@nuclearfallout.net>
Tested-by: John <jw@nuclearfallout.net>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
drivers/net/xen-netback/common.h | 4 +++-
drivers/net/xen-netback/interface.c | 4 +++-
drivers/net/xen-netback/netback.c | 27 ++++++++++++++-------------
drivers/net/xen-netback/xenbus.c | 12 +++++++++---
4 files changed, 29 insertions(+), 18 deletions(-)
diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index 083ecc9..5f1fda4 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -230,6 +230,8 @@ struct xenvif {
*/
bool disabled;
unsigned long status;
+ unsigned long drain_timeout;
+ unsigned long stall_timeout;
/* Queues */
struct xenvif_queue *queues;
@@ -328,7 +330,7 @@ irqreturn_t xenvif_interrupt(int irq, void *dev_id);
extern bool separate_tx_rx_irq;
extern unsigned int rx_drain_timeout_msecs;
-extern unsigned int rx_drain_timeout_jiffies;
+extern unsigned int rx_stall_timeout_msecs;
extern unsigned int xenvif_max_queues;
#ifdef CONFIG_DEBUG_FS
diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
index a6a32d3..9259a73 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -166,7 +166,7 @@ static int xenvif_start_xmit(struct sk_buff *skb, struct net_device *dev)
goto drop;
cb = XENVIF_RX_CB(skb);
- cb->expires = jiffies + rx_drain_timeout_jiffies;
+ cb->expires = jiffies + vif->drain_timeout;
xenvif_rx_queue_tail(queue, skb);
xenvif_kick_thread(queue);
@@ -414,6 +414,8 @@ struct xenvif *xenvif_alloc(struct device *parent, domid_t domid,
vif->ip_csum = 1;
vif->dev = dev;
vif->disabled = false;
+ vif->drain_timeout = msecs_to_jiffies(rx_drain_timeout_msecs);
+ vif->stall_timeout = msecs_to_jiffies(rx_stall_timeout_msecs);
/* Start out with no queues. */
vif->queues = NULL;
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 4a509f7..908e65e 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -60,14 +60,12 @@ module_param(separate_tx_rx_irq, bool, 0644);
*/
unsigned int rx_drain_timeout_msecs = 10000;
module_param(rx_drain_timeout_msecs, uint, 0444);
-unsigned int rx_drain_timeout_jiffies;
/* The length of time before the frontend is considered unresponsive
* because it isn't providing Rx slots.
*/
-static unsigned int rx_stall_timeout_msecs = 60000;
+unsigned int rx_stall_timeout_msecs = 60000;
module_param(rx_stall_timeout_msecs, uint, 0444);
-static unsigned int rx_stall_timeout_jiffies;
unsigned int xenvif_max_queues;
module_param_named(max_queues, xenvif_max_queues, uint, 0644);
@@ -2020,7 +2018,7 @@ static bool xenvif_rx_queue_stalled(struct xenvif_queue *queue)
return !queue->stalled
&& prod - cons < XEN_NETBK_RX_SLOTS_MAX
&& time_after(jiffies,
- queue->last_rx_time + rx_stall_timeout_jiffies);
+ queue->last_rx_time + queue->vif->stall_timeout);
}
static bool xenvif_rx_queue_ready(struct xenvif_queue *queue)
@@ -2038,8 +2036,9 @@ static bool xenvif_have_rx_work(struct xenvif_queue *queue)
{
return (!skb_queue_empty(&queue->rx_queue)
&& xenvif_rx_ring_slots_available(queue, XEN_NETBK_RX_SLOTS_MAX))
- || xenvif_rx_queue_stalled(queue)
- || xenvif_rx_queue_ready(queue)
+ || (queue->vif->stall_timeout &&
+ (xenvif_rx_queue_stalled(queue)
+ || xenvif_rx_queue_ready(queue)))
|| kthread_should_stop()
|| queue->vif->disabled;
}
@@ -2092,6 +2091,9 @@ int xenvif_kthread_guest_rx(void *data)
struct xenvif_queue *queue = data;
struct xenvif *vif = queue->vif;
+ if (!vif->stall_timeout)
+ xenvif_queue_carrier_on(queue);
+
for (;;) {
xenvif_wait_for_rx_work(queue);
@@ -2118,10 +2120,12 @@ int xenvif_kthread_guest_rx(void *data)
* while it's probably not responsive, drop the
* carrier so packets are dropped earlier.
*/
- if (xenvif_rx_queue_stalled(queue))
- xenvif_queue_carrier_off(queue);
- else if (xenvif_rx_queue_ready(queue))
- xenvif_queue_carrier_on(queue);
+ if (vif->stall_timeout) {
+ if (xenvif_rx_queue_stalled(queue))
+ xenvif_queue_carrier_off(queue);
+ else if (xenvif_rx_queue_ready(queue))
+ xenvif_queue_carrier_on(queue);
+ }
/* Queued packets may have foreign pages from other
* domains. These cannot be queued indefinitely as
@@ -2192,9 +2196,6 @@ static int __init netback_init(void)
if (rc)
goto failed_init;
- rx_drain_timeout_jiffies = msecs_to_jiffies(rx_drain_timeout_msecs);
- rx_stall_timeout_jiffies = msecs_to_jiffies(rx_stall_timeout_msecs);
-
#ifdef CONFIG_DEBUG_FS
xen_netback_dbg_root = debugfs_create_dir("xen-netback", NULL);
if (IS_ERR_OR_NULL(xen_netback_dbg_root))
diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
index d44cd19..efbaf2a 100644
--- a/drivers/net/xen-netback/xenbus.c
+++ b/drivers/net/xen-netback/xenbus.c
@@ -887,9 +887,15 @@ static int read_xenbus_vif_flags(struct backend_info *be)
return -EOPNOTSUPP;
if (xenbus_scanf(XBT_NIL, dev->otherend,
- "feature-rx-notify", "%d", &val) < 0 || val == 0) {
- xenbus_dev_fatal(dev, -EINVAL, "feature-rx-notify is mandatory");
- return -EINVAL;
+ "feature-rx-notify", "%d", &val) < 0)
+ val = 0;
+ if (!val) {
+ /* - Reduce drain timeout to poll more frequently for
+ * Rx requests.
+ * - Disable Rx stall detection.
+ */
+ be->vif->drain_timeout = msecs_to_jiffies(30);
+ be->vif->stall_timeout = 0;
}
if (xenbus_scanf(XBT_NIL, dev->otherend, "feature-sg",
--
1.7.10.4
^ permalink raw reply related
* [PULL] vhost: cleanups and fixes
From: Michael S. Tsirkin @ 2014-12-18 10:46 UTC (permalink / raw)
To: Linus Torvalds; +Cc: herbert, kvm, mst, netdev, linux-kernel, virtualization
The following changes since commit f01a2a811ae04124fc9382925038fcbbd2f0b7c8:
virtio_ccw: finalize_features error handling (2014-12-09 21:42:06 +0200)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git tags/for_linus
for you to fetch changes up to 5ff16110c637726111662c1df41afd9df7ef36bd:
virtio_pci: restore module attributes (2014-12-17 00:59:40 +0200)
----------------------------------------------------------------
vhost/virtio: virtio 1.0 related fixes
Most importantly, this fixes using virtio_pci as a module.
Further, the big virtio 1.0 conversion missed a couple of places. This fixes
them up.
This isn't 100% sparse-clean yet because on many architectures get_user
triggers sparse warnings when used with __bitwise tag (when same tag is on both
pointer and value read).
I posted a patchset to fix it up by adding __force on all
arches that don't already have it (many do), when that's
merged these warnings will go away.
Cc: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
----------------------------------------------------------------
Herbert Xu (1):
virtio_pci: restore module attributes
Michael S. Tsirkin (15):
virtio: set VIRTIO_CONFIG_S_FEATURES_OK on restore
virtio_config: fix virtio_cread_bytes
virtio_pci_common.h: drop VIRTIO_PCI_NO_LEGACY
virtio_pci: move probe to common file
virtio_pci: add VIRTIO_PCI_NO_LEGACY
virtio: core support for config generation
tools/virtio: more stubs
tools/virtio: fix vringh test
tools/virtio: 64 bit features
tools/virtio: enable -Werror
tools/virtio: add virtio 1.0 in virtio_test
tools/virtio: add virtio 1.0 in vringh_test
vringh: 64 bit features
vringh: update for virtio 1.0 APIs
mic/host: fix up virtio 1.0 APIs
drivers/virtio/virtio_pci_common.h | 7 +-
include/linux/virtio_config.h | 29 +++++++-
include/linux/vringh.h | 37 +++++++++-
include/uapi/linux/virtio_pci.h | 15 ++--
tools/virtio/linux/virtio.h | 1 +
tools/virtio/linux/virtio_byteorder.h | 8 +++
tools/virtio/linux/virtio_config.h | 70 +++++++++++++++++-
tools/virtio/uapi/linux/virtio_types.h | 1 +
drivers/misc/mic/host/mic_debugfs.c | 18 +++--
drivers/vhost/vringh.c | 125 ++++++++++++++++++++-------------
drivers/virtio/virtio.c | 37 ++++++----
drivers/virtio/virtio_pci_common.c | 39 +++++++++-
drivers/virtio/virtio_pci_legacy.c | 24 +------
tools/virtio/virtio_test.c | 15 +++-
tools/virtio/vringh_test.c | 5 +-
tools/virtio/Makefile | 2 +-
16 files changed, 324 insertions(+), 109 deletions(-)
create mode 100644 tools/virtio/linux/virtio_byteorder.h
create mode 100644 tools/virtio/uapi/linux/virtio_types.h
^ permalink raw reply
* [PATCH net] netlink: Don't reorder loads/stores before marking mmap netlink frame as available
From: Thomas Graf @ 2014-12-18 10:30 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, dborkman, luto, torvalds, kaber, netdev
In-Reply-To: <1418774579.9773.69.camel@edumazet-glaptop2.roam.corp.google.com>
Each mmap Netlink frame contains a status field which indicates
whether the frame is unused, reserved, contains data or needs to
be skipped. Both loads and stores may not be reordeded and must
complete before the status field is changed and another CPU might
pick up the frame for use. Use an smp_mb() to cover needs of both
types of callers to netlink_set_status(), callers which have been
reading data frame from the frame, and callers which have been
filling or releasing and thus writing to the frame.
- Example code path requiring a smp_rmb():
memcpy(skb->data, (void *)hdr + NL_MMAP_HDRLEN, hdr->nm_len);
netlink_set_status(hdr, NL_MMAP_STATUS_UNUSED);
- Example code path requiring a smp_wmb():
hdr->nm_uid = from_kuid(sk_user_ns(sk), NETLINK_CB(skb).creds.uid);
hdr->nm_gid = from_kgid(sk_user_ns(sk), NETLINK_CB(skb).creds.gid);
netlink_frame_flush_dcache(hdr);
netlink_set_status(hdr, NL_MMAP_STATUS_VALID);
Fixes: f9c228 ("netlink: implement memory mapped recvmsg()")
Reported-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: Thomas Graf <tgraf@suug.ch>
---
net/netlink/af_netlink.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
index ef5f77b..2662821 100644
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c
@@ -550,9 +550,9 @@ static enum nl_mmap_status netlink_get_status(const struct nl_mmap_hdr *hdr)
static void netlink_set_status(struct nl_mmap_hdr *hdr,
enum nl_mmap_status status)
{
+ smp_mb();
hdr->nm_status = status;
flush_dcache_page(pgvec_to_page(hdr));
- smp_wmb();
}
static struct nl_mmap_hdr *
^ permalink raw reply related
* [PATCH net] enic: fix rx skb checksum
From: Govindarajulu Varadarajan @ 2014-12-18 10:28 UTC (permalink / raw)
To: davem, netdev, ssujith, benve
Cc: Govindarajulu Varadarajan, Jiri Benc, Stefan Assmann
Hardware always provides compliment of IP pseudo checksum. Stack expects
whole packet checksum without pseudo checksum if CHECKSUM_COMPLETE is set.
This causes checksum error in nf & ovs.
kernel: qg-19546f09-f2: hw csum failure
kernel: CPU: 9 PID: 0 Comm: swapper/9 Tainted: GF O-------------- 3.10.0-123.8.1.el7.x86_64 #1
kernel: Hardware name: Cisco Systems Inc UCSB-B200-M3/UCSB-B200-M3, BIOS B200M3.2.2.3.0.080820141339 08/08/2014
kernel: ffff881218f40000 df68243feb35e3a8 ffff881237a43ab8 ffffffff815e237b
kernel: ffff881237a43ad0 ffffffff814cd4ca ffff8829ec71eb00 ffff881237a43af0
kernel: ffffffff814c6232 0000000000000286 ffff8829ec71eb00 ffff881237a43b00
kernel: Call Trace:
kernel: <IRQ> [<ffffffff815e237b>] dump_stack+0x19/0x1b
kernel: [<ffffffff814cd4ca>] netdev_rx_csum_fault+0x3a/0x40
kernel: [<ffffffff814c6232>] __skb_checksum_complete_head+0x62/0x70
kernel: [<ffffffff814c6251>] __skb_checksum_complete+0x11/0x20
kernel: [<ffffffff8155a20c>] nf_ip_checksum+0xcc/0x100
kernel: [<ffffffffa049edc7>] icmp_error+0x1f7/0x35c [nf_conntrack_ipv4]
kernel: [<ffffffff814cf419>] ? netif_rx+0xb9/0x1d0
kernel: [<ffffffffa040eb7b>] ? internal_dev_recv+0xdb/0x130 [openvswitch]
kernel: [<ffffffffa04c8330>] nf_conntrack_in+0xf0/0xa80 [nf_conntrack]
kernel: [<ffffffff81509380>] ? inet_del_offload+0x40/0x40
kernel: [<ffffffffa049e302>] ipv4_conntrack_in+0x22/0x30 [nf_conntrack_ipv4]
kernel: [<ffffffff815005ca>] nf_iterate+0xaa/0xc0
kernel: [<ffffffff81509380>] ? inet_del_offload+0x40/0x40
kernel: [<ffffffff81500664>] nf_hook_slow+0x84/0x140
kernel: [<ffffffff81509380>] ? inet_del_offload+0x40/0x40
kernel: [<ffffffff81509dd4>] ip_rcv+0x344/0x380
Hardware verifies IP & tcp/udp header checksum but does not provide payload
checksum, use CHECKSUM_UNNECESSARY. Set it only if its valid IP tcp/udp packet.
Cc: Jiri Benc <jbenc@redhat.com>
Cc: Stefan Assmann <sassmann@redhat.com>
Reported-by: Sunil Choudhary <schoudha@redhat.com>
Signed-off-by: Govindarajulu Varadarajan <_govind@gmx.com>
---
drivers/net/ethernet/cisco/enic/enic_main.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/cisco/enic/enic_main.c b/drivers/net/ethernet/cisco/enic/enic_main.c
index 868d0f6..705f334 100644
--- a/drivers/net/ethernet/cisco/enic/enic_main.c
+++ b/drivers/net/ethernet/cisco/enic/enic_main.c
@@ -1060,10 +1060,14 @@ static void enic_rq_indicate_buf(struct vnic_rq *rq,
PKT_HASH_TYPE_L4 : PKT_HASH_TYPE_L3);
}
- if ((netdev->features & NETIF_F_RXCSUM) && !csum_not_calc) {
- skb->csum = htons(checksum);
- skb->ip_summed = CHECKSUM_COMPLETE;
- }
+ /* Hardware does not provide whole packet checksum. It only
+ * provides pseudo checksum. Since hw validates the packet
+ * checksum but not provide us the checksum value. use
+ * CHECSUM_UNNECESSARY.
+ */
+ if ((netdev->features & NETIF_F_RXCSUM) && tcp_udp_csum_ok &&
+ ipv4_csum_ok)
+ skb->ip_summed = CHECKSUM_UNNECESSARY;
if (vlan_stripped)
__vlan_hwaccel_put_tag(skb, htons(ETH_P_8021Q), vlan_tci);
--
2.1.3
^ permalink raw reply related
* Re: [PATCH] ixgbe, ixgbevf: Add new mbox API to enable MC promiscuous mode
From: Hiroshi Shimamoto @ 2014-12-18 9:47 UTC (permalink / raw)
To: Alexander Duyck, e1000-devel@lists.sourceforge.net
Cc: netdev@vger.kernel.org, Choi, Sy Jong, Hayato Momma,
linux-kernel@vger.kernel.org
In-Reply-To: <54809D57.9060804@gmail.com>
> > > Subject: Re: [E1000-devel] [PATCH] ixgbe, ixgbevf: Add new mbox API to enable MC promiscuous mode
> > >
> > > On 11/27/2014 02:39 AM, Hiroshi Shimamoto wrote:
> > > > From: Hiroshi Shimamoto <h-shimamoto@ct.jp.nec.com>
> > > >
> > > > The limitation of the number of multicast address for VF is not enough
> > > > for the large scale server with SR-IOV feature.
> > > > IPv6 requires the multicast MAC address for each IP address to handle
> > > > the Neighbor Solicitation message.
> > > > We couldn't assign over 30 IPv6 addresses to a single VF interface.
> > > >
> > > > The easy way to solve this is enabling multicast promiscuous mode.
> > > > It is good to have a functionality to enable multicast promiscuous mode
> > > > for each VF from VF driver.
> > > >
> > > > This patch introduces the new mbox API, IXGBE_VF_SET_MC_PROMISC, to
> > > > enable/disable multicast promiscuous mode in VF. If multicast promiscuous
> > > > mode is enabled the VF can receive all multicast packets.
> > > >
> > > > With this patch, the ixgbevf driver automatically enable multicast
> > > > promiscuous mode when the number of multicast addresses is over than 30
> > > > if possible.
> > > >
> > > > This also bump the API version up to 1.2 to check whether the API,
> > > > IXGBE_VF_SET_MC_PROMISC is available.
> > > >
> > > > Signed-off-by: Hiroshi Shimamoto <h-shimamoto@ct.jp.nec.com>
> > > > CC: Choi, Sy Jong <sy.jong.choi@intel.com>
> > > > Reviewed-by: Hayato Momma <h-momma@ce.jp.nec.com>
> > >
> > > This is a REALLY bad idea unless you plan to limit this to privileged VFs.
> > >
> > > I would recommend looking at adding an ndo operation to control this
> > > feature so that it could be disabled by default in the PF and only
> > > enabled on the host side if specifically requested. Otherwise the
Do you think whether introducing ndo_set_vf_mc_promisc to control the multicast
promiscuous mode of VF from host is good to you?
If that's okay I'm fine to post the new patch.
We need the capability to use thousands IPv6 addresses in VF.
I think setting multicast promiscuous mode on is the easiest way to do it.
thanks,
Hiroshi
------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* [PATCH net] bnx2x: fix typos in "configure"
From: Jiri Benc @ 2014-12-18 8:04 UTC (permalink / raw)
To: netdev; +Cc: Ariel Elior
Noticed when debugging ptp.
Signed-off-by: Jiri Benc <jbenc@redhat.com>
---
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 4 ++--
drivers/net/ethernet/broadcom/bnx2x/bnx2x_reg.h | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
index 691f0bf09ee1..9f5e38769a29 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
@@ -13256,7 +13256,7 @@ static int bnx2x_ptp_adjfreq(struct ptp_clock_info *ptp, s32 ppb)
return -EFAULT;
}
- DP(BNX2X_MSG_PTP, "Configrued val = %d, period = %d\n", best_val,
+ DP(BNX2X_MSG_PTP, "Configured val = %d, period = %d\n", best_val,
best_period);
return 0;
@@ -14784,7 +14784,7 @@ static int bnx2x_hwtstamp_ioctl(struct bnx2x *bp, struct ifreq *ifr)
-EFAULT : 0;
}
-/* Configrues HW for PTP */
+/* Configures HW for PTP */
static int bnx2x_configure_ptp(struct bnx2x *bp)
{
int rc, port = BP_PORT(bp);
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_reg.h b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_reg.h
index b0779d773343..6fe547c93e74 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_reg.h
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_reg.h
@@ -7549,7 +7549,7 @@ Theotherbitsarereservedandshouldbezero*/
#define IGU_REG_SISR_MDPC_WOMASK_UPPER 0x05a6
#define IGU_REG_RESERVED_UPPER 0x05ff
-/* Fields of IGU PF CONFIGRATION REGISTER */
+/* Fields of IGU PF CONFIGURATION REGISTER */
#define IGU_PF_CONF_FUNC_EN (0x1<<0) /* function enable */
#define IGU_PF_CONF_MSI_MSIX_EN (0x1<<1) /* MSI/MSIX enable */
#define IGU_PF_CONF_INT_LINE_EN (0x1<<2) /* INT enable */
@@ -7557,7 +7557,7 @@ Theotherbitsarereservedandshouldbezero*/
#define IGU_PF_CONF_SINGLE_ISR_EN (0x1<<4) /* single ISR mode enable */
#define IGU_PF_CONF_SIMD_MODE (0x1<<5) /* simd all ones mode */
-/* Fields of IGU VF CONFIGRATION REGISTER */
+/* Fields of IGU VF CONFIGURATION REGISTER */
#define IGU_VF_CONF_FUNC_EN (0x1<<0) /* function enable */
#define IGU_VF_CONF_MSI_MSIX_EN (0x1<<1) /* MSI/MSIX enable */
#define IGU_VF_CONF_PARENT_MASK (0x3<<2) /* Parent PF */
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH 09/10] macvtap: Re-enable UFO support
From: Michael S. Tsirkin @ 2014-12-18 7:55 UTC (permalink / raw)
To: Vlad Yasevich; +Cc: netdev, Vladislav Yasevich, ben, stefanha, virtualization
In-Reply-To: <54923F67.3000205@redhat.com>
On Wed, Dec 17, 2014 at 09:43:51PM -0500, Vlad Yasevich wrote:
> On 12/17/2014 05:41 PM, Michael S. Tsirkin wrote:
> > On Wed, Dec 17, 2014 at 01:20:54PM -0500, Vladislav Yasevich wrote:
> >> Now that UFO is split into v4 and v6 parts, we can bring
> >> back v4 support. Continue to handle legacy applications
> >> by selecting the ipv6 fagment id but do not change the
> >> gso type. This allows 2 legacy VMs to continue to communicate.
> >>
> >> Based on original work from Ben Hutchings.
> >>
> >> Fixes: 88e0e0e5aa7a ("drivers/net: Disable UFO through virtio")
> >> CC: Ben Hutchings <ben@decadent.org.uk>
> >> Signed-off-by: Vladislav Yasevich <vyasevic@redhat.com>
> >> ---
> >> drivers/net/macvtap.c | 20 ++++++++++++++------
> >> 1 file changed, 14 insertions(+), 6 deletions(-)
> >>
> >> diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
> >> index 880cc09..75febd4 100644
> >> --- a/drivers/net/macvtap.c
> >> +++ b/drivers/net/macvtap.c
> >> @@ -66,7 +66,7 @@ static struct cdev macvtap_cdev;
> >> static const struct proto_ops macvtap_socket_ops;
> >>
> >> #define TUN_OFFLOADS (NETIF_F_HW_CSUM | NETIF_F_TSO_ECN | NETIF_F_TSO | \
> >> - NETIF_F_TSO6)
> >> + NETIF_F_TSO6 | NETIF_F_UFO)
> >> #define RX_OFFLOADS (NETIF_F_GRO | NETIF_F_LRO)
> >> #define TAP_FEATURES (NETIF_F_GSO | NETIF_F_SG)
> >>
> >> @@ -570,11 +570,14 @@ static int macvtap_skb_from_vnet_hdr(struct sk_buff *skb,
> >> gso_type = SKB_GSO_TCPV6;
> >> break;
> >> case VIRTIO_NET_HDR_GSO_UDP:
> >> - pr_warn_once("macvtap: %s: using disabled UFO feature; please fix this program\n",
> >> - current->comm);
> >> gso_type = SKB_GSO_UDP;
> >> - if (skb->protocol == htons(ETH_P_IPV6))
> >> + if (vlan_get_protocol(skb) == htons(ETH_P_IPV6)) {
> >> + /* This is to support legacy appliacations.
> >> + * Do not change the gso_type as legacy apps
> >> + * may not know about the new type.
> >> + */
> >> ipv6_proxy_select_ident(skb);
> >> + }
> >> break;
> >> default:
> >> return -EINVAL;
> >> @@ -619,6 +622,8 @@ static void macvtap_skb_to_vnet_hdr(const struct sk_buff *skb,
> >> vnet_hdr->gso_type = VIRTIO_NET_HDR_GSO_TCPV4;
> >> else if (sinfo->gso_type & SKB_GSO_TCPV6)
> >> vnet_hdr->gso_type = VIRTIO_NET_HDR_GSO_TCPV6;
> >> + else if (sinfo->gso_type & SKB_GSO_UDP)
> >> + vnet_hdr->gso_type = VIRTIO_NET_HDR_GSO_UDP;
> >> else
> >> BUG();
> >> if (sinfo->gso_type & SKB_GSO_TCP_ECN)
> >> @@ -955,6 +960,9 @@ static int set_offload(struct macvtap_queue *q, unsigned long arg)
> >> if (arg & TUN_F_TSO6)
> >> feature_mask |= NETIF_F_TSO6;
> >> }
> >> +
> >> + if (arg & TUN_F_UFO)
> >> + feature_mask |= NETIF_F_UFO;
> >> }
> >>
> >> /* tun/tap driver inverts the usage for TSO offloads, where
> >> @@ -965,7 +973,7 @@ static int set_offload(struct macvtap_queue *q, unsigned long arg)
> >> * When user space turns off TSO, we turn off GSO/LRO so that
> >> * user-space will not receive TSO frames.
> >> */
> >> - if (feature_mask & (NETIF_F_TSO | NETIF_F_TSO6))
> >> + if (feature_mask & (NETIF_F_TSO | NETIF_F_TSO6 | NETIF_F_UFO))
> >> features |= RX_OFFLOADS;
> >> else
> >> features &= ~RX_OFFLOADS;
> >
> > By the way this logic is completely broken, even without your patch,
> > isn't it?
> >
> > It says: enable LRO+GRO if any of NETIF_F_TSO | NETIF_F_TSO6 |
> > NETIF_F_UFO set.
> >
> > So what happens if I enable TSO only?
> > LRO gets enabled so I can still get TSO6 packets.
> >
> >
> > This really should be:
> >
> > if (feature_mask & (NETIF_F_TSO | NETIF_F_TSO6 | NETIF_F_UFO) ==
> > (NETIF_F_TSO | NETIF_F_TSO6 | NETIF_F_UFO)
> >
> >
> > fixing this probably should be a separate patch before your
> > series, and Cc stable.
>
> Actually, all this LRO/GRO feature manipulation on the macvtap device is
> rather pointless as those features aren't really checked at any point
> on the macvtap receive path. GRO calls are done from napi context on
> the lowest device, so by the time a packet hits macvtap, GRO/LRO has
> already been done.
>
> So it doesn't really matter that we disable them incorrectly. I
> can send a separate patch to clean this up.
Hmm so if userspace says it can't handle TSO packets,
it might get them anyway?
> >
> >
> >> @@ -1066,7 +1074,7 @@ static long macvtap_ioctl(struct file *file, unsigned int cmd,
> >> case TUNSETOFFLOAD:
> >> /* let the user check for future flags */
> >> if (arg & ~(TUN_F_CSUM | TUN_F_TSO4 | TUN_F_TSO6 |
> >> - TUN_F_TSO_ECN))
> >> + TUN_F_TSO_ECN | TUN_F_UFO))
> >> return -EINVAL;
> >>
> >> rtnl_lock();
> >> --
> >> 1.9.3
^ permalink raw reply
* Re: [PATCH 01/10] core: Split out UFO6 support
From: Michael S. Tsirkin @ 2014-12-18 7:54 UTC (permalink / raw)
To: Vlad Yasevich
Cc: netdev, Vladislav Yasevich, virtualization, stefanha, ben,
David Miller
In-Reply-To: <54921266.30300@redhat.com>
Cc Dave, pls remember to do this next time otherwise
your patches won't get merged :)
On Wed, Dec 17, 2014 at 06:31:50PM -0500, Vlad Yasevich wrote:
> On 12/17/2014 05:45 PM, Michael S. Tsirkin wrote:
> > On Wed, Dec 17, 2014 at 01:20:46PM -0500, Vladislav Yasevich wrote:
> >> Split IPv6 support for UFO into its own feature similiar to TSO.
> >> This will later allow us to re-enable UFO support for virtio-net
> >> devices.
> >>
> >> Signed-off-by: Vladislav Yasevich <vyasevic@redhat.com>
> >> ---
> >> include/linux/netdev_features.h | 7 +++++--
> >> include/linux/netdevice.h | 1 +
> >> include/linux/skbuff.h | 1 +
> >> net/core/dev.c | 35 +++++++++++++++++++----------------
> >> net/core/ethtool.c | 2 +-
> >> 5 files changed, 27 insertions(+), 19 deletions(-)
> >>
> >> diff --git a/include/linux/netdev_features.h b/include/linux/netdev_features.h
> >> index dcfdecb..a078945 100644
> >> --- a/include/linux/netdev_features.h
> >> +++ b/include/linux/netdev_features.h
> >> @@ -48,8 +48,9 @@ enum {
> >> NETIF_F_GSO_UDP_TUNNEL_BIT, /* ... UDP TUNNEL with TSO */
> >> NETIF_F_GSO_UDP_TUNNEL_CSUM_BIT,/* ... UDP TUNNEL with TSO & CSUM */
> >> NETIF_F_GSO_MPLS_BIT, /* ... MPLS segmentation */
> >> + NETIF_F_UFO6_BIT, /* ... UDPv6 fragmentation */
> >> /**/NETIF_F_GSO_LAST = /* last bit, see GSO_MASK */
> >> - NETIF_F_GSO_MPLS_BIT,
> >> + NETIF_F_UFO6_BIT,
> >>
> >> NETIF_F_FCOE_CRC_BIT, /* FCoE CRC32 */
> >> NETIF_F_SCTP_CSUM_BIT, /* SCTP checksum offload */
> >> @@ -109,6 +110,7 @@ enum {
> >> #define NETIF_F_TSO_ECN __NETIF_F(TSO_ECN)
> >> #define NETIF_F_TSO __NETIF_F(TSO)
> >> #define NETIF_F_UFO __NETIF_F(UFO)
> >> +#define NETIF_F_UFO6 __NETIF_F(UFO6)
> >> #define NETIF_F_VLAN_CHALLENGED __NETIF_F(VLAN_CHALLENGED)
> >> #define NETIF_F_RXFCS __NETIF_F(RXFCS)
> >> #define NETIF_F_RXALL __NETIF_F(RXALL)
> >> @@ -141,7 +143,7 @@ enum {
> >>
> >> /* List of features with software fallbacks. */
> >> #define NETIF_F_GSO_SOFTWARE (NETIF_F_TSO | NETIF_F_TSO_ECN | \
> >> - NETIF_F_TSO6 | NETIF_F_UFO)
> >> + NETIF_F_TSO6 | NETIF_F_UFO | NETIF_F_UFO6)
> >>
> >> #define NETIF_F_GEN_CSUM NETIF_F_HW_CSUM
> >> #define NETIF_F_V4_CSUM (NETIF_F_GEN_CSUM | NETIF_F_IP_CSUM)
> >> @@ -149,6 +151,7 @@ enum {
> >> #define NETIF_F_ALL_CSUM (NETIF_F_V4_CSUM | NETIF_F_V6_CSUM)
> >>
> >> #define NETIF_F_ALL_TSO (NETIF_F_TSO | NETIF_F_TSO6 | NETIF_F_TSO_ECN)
> >> +#define NETIF_F_ALL_UFO (NETIF_F_UFO | NETIF_F_UFO6)
> >>
> >> #define NETIF_F_ALL_FCOE (NETIF_F_FCOE_CRC | NETIF_F_FCOE_MTU | \
> >> NETIF_F_FSO)
> >> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> >> index 74fd5d3..86af10a 100644
> >> --- a/include/linux/netdevice.h
> >> +++ b/include/linux/netdevice.h
> >> @@ -3559,6 +3559,7 @@ static inline bool net_gso_ok(netdev_features_t features, int gso_type)
> >> /* check flags correspondence */
> >> BUILD_BUG_ON(SKB_GSO_TCPV4 != (NETIF_F_TSO >> NETIF_F_GSO_SHIFT));
> >> BUILD_BUG_ON(SKB_GSO_UDP != (NETIF_F_UFO >> NETIF_F_GSO_SHIFT));
> >> + BUILD_BUG_ON(SKB_GSO_UDP6 != (NETIF_F_UFO6 >> NETIF_F_GSO_SHIFT));
> >> BUILD_BUG_ON(SKB_GSO_DODGY != (NETIF_F_GSO_ROBUST >> NETIF_F_GSO_SHIFT));
> >> BUILD_BUG_ON(SKB_GSO_TCP_ECN != (NETIF_F_TSO_ECN >> NETIF_F_GSO_SHIFT));
> >> BUILD_BUG_ON(SKB_GSO_TCPV6 != (NETIF_F_TSO6 >> NETIF_F_GSO_SHIFT));
> >> diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
> >> index 6c8b6f6..8538b67 100644
> >> --- a/include/linux/skbuff.h
> >> +++ b/include/linux/skbuff.h
> >> @@ -372,6 +372,7 @@ enum {
> >>
> >> SKB_GSO_MPLS = 1 << 12,
> >>
> >> + SKB_GSO_UDP6 = 1 << 13
> >> };
> >>
> >> #if BITS_PER_LONG > 32
> >
> > So this implies anything getting GSO packets e.g.
> > from userspace now needs to check IP version to
> > set GSO type correctly.
> >
> > I think you missed some places that do this, e.g. af_packet
> > sockets.
> >
>
> I looked at af_packet sockets and they set this only in the event
> vnet header has been used with a GSO type. In this case, the user
> already knows the the type.
Imagine you are receiving a packet:
if (vnet_hdr.gso_type != VIRTIO_NET_HDR_GSO_NONE) {
switch (vnet_hdr.gso_type & ~VIRTIO_NET_HDR_GSO_ECN) {
case VIRTIO_NET_HDR_GSO_TCPV4:
gso_type = SKB_GSO_TCPV4;
break;
case VIRTIO_NET_HDR_GSO_TCPV6:
gso_type = SKB_GSO_TCPV6;
break;
case VIRTIO_NET_HDR_GSO_UDP:
gso_type = SKB_GSO_UDP;
break;
default:
goto out_unlock;
}
if (vnet_hdr.gso_type & VIRTIO_NET_HDR_GSO_ECN)
gso_type |= SKB_GSO_TCP_ECN;
if (vnet_hdr.gso_size == 0)
goto out_unlock;
}
we used to report UFO6 as SKB_GSO_UDP, we probably
should keep doing this, with your patch we select the
goto out_unlock path.
> It is true that with this series af_packets now can't do IPv6 UFO
> since there is no VIRTIO_NET_HDR_GSO_UDPV6 yet.
What do you mean by "do".
Are we talking about sending or receiving packets?
You seem to conflate the two.
We always discarded ID on RX.
For tun, this is xmit, so just by saying "this device can
not do UFO" you will never get short packets.
>
> I suppose we could do something similar there as we do in tun code/macvtap code.
> If that's the case, it currently broken as well.
>
> -vlad
Broken is a big word.
Let's stop conflating two directions.
Here's the way I look at it:
1. Userspace doesn't have a way to get fragment IDs
from tun/macvtap/packet sockets.
Presumably, not all users need these IDs.
E.g. old guests clearly don't.
We should either give them packets stripping the ID,
like we always did, or make sure they never get these packets.
Second option seems achievable for tun if we
never tell linux it can do UFO, but I don't see
how to do it for macvtap and packet socket.
2. Userspace doesn't have a way to set fragment IDs
for tun/macvtap/packet sockets.
Presumably, not all users have these IDs. E.g. old
guests clearly don't.
We should either generate our own ID,
like we always did, or make sure we don't accept
these packets.
Second option is almost sure to break userspace,
so it seems we must do the first one.
3.
Exactly the same two things if you replace userspace
with hypervisor and tun/macvtap/packet socket with
virtio device.
4.
As a next step, we should add a way for userspace
to tell us that it has ids and can handle them.
> >
> >> diff --git a/net/core/dev.c b/net/core/dev.c
> >> index 945bbd0..fa4d2ee 100644
> >> --- a/net/core/dev.c
> >> +++ b/net/core/dev.c
> >> @@ -5929,6 +5929,12 @@ static netdev_features_t netdev_fix_features(struct net_device *dev,
> >> features &= ~NETIF_F_ALL_TSO;
> >> }
> >>
> >> + /* UFO requires that SG is present as well */
> >> + if ((features & NETIF_F_ALL_UFO) && !(features & NETIF_F_SG)) {
> >> + netdev_dbg(dev, "Dropping UFO features since no SG feature.\n");
> >> + features &= ~NETIF_F_ALL_UFO;
> >> + }
> >> +
> >> if ((features & NETIF_F_TSO) && !(features & NETIF_F_HW_CSUM) &&
> >> !(features & NETIF_F_IP_CSUM)) {
> >> netdev_dbg(dev, "Dropping TSO features since no CSUM feature.\n");
> >> @@ -5952,24 +5958,21 @@ static netdev_features_t netdev_fix_features(struct net_device *dev,
> >> features &= ~NETIF_F_GSO;
> >> }
> >>
> >> - /* UFO needs SG and checksumming */
> >> - if (features & NETIF_F_UFO) {
> >> - /* maybe split UFO into V4 and V6? */
> >> - if (!((features & NETIF_F_GEN_CSUM) ||
> >> - (features & (NETIF_F_IP_CSUM|NETIF_F_IPV6_CSUM))
> >> - == (NETIF_F_IP_CSUM|NETIF_F_IPV6_CSUM))) {
> >> - netdev_dbg(dev,
> >> - "Dropping NETIF_F_UFO since no checksum offload features.\n");
> >> - features &= ~NETIF_F_UFO;
> >> - }
> >> -
> >> - if (!(features & NETIF_F_SG)) {
> >> - netdev_dbg(dev,
> >> - "Dropping NETIF_F_UFO since no NETIF_F_SG feature.\n");
> >> - features &= ~NETIF_F_UFO;
> >> - }
> >> + /* UFO also needs checksumming */
> >> + if ((features & NETIF_F_UFO) && !(features & NETIF_F_GEN_CSUM) &&
> >> + !(features & NETIF_F_IP_CSUM)) {
> >> + netdev_dbg(dev,
> >> + "Dropping NETIF_F_UFO since no checksum offload features.\n");
> >> + features &= ~NETIF_F_UFO;
> >> + }
> >> + if ((features & NETIF_F_UFO6) && !(features & NETIF_F_GEN_CSUM) &&
> >> + !(features & NETIF_F_IPV6_CSUM)) {
> >> + netdev_dbg(dev,
> >> + "Dropping NETIF_F_UFO6 since no checksum offload features.\n");
> >> + features &= ~NETIF_F_UFO6;
> >> }
> >>
> >> +
> >> #ifdef CONFIG_NET_RX_BUSY_POLL
> >> if (dev->netdev_ops->ndo_busy_poll)
> >> features |= NETIF_F_BUSY_POLL;
> >> diff --git a/net/core/ethtool.c b/net/core/ethtool.c
> >> index 06dfb29..93eff41 100644
> >> --- a/net/core/ethtool.c
> >> +++ b/net/core/ethtool.c
> >> @@ -223,7 +223,7 @@ static netdev_features_t ethtool_get_feature_mask(u32 eth_cmd)
> >> return NETIF_F_ALL_TSO;
> >> case ETHTOOL_GUFO:
> >> case ETHTOOL_SUFO:
> >> - return NETIF_F_UFO;
> >> + return NETIF_F_ALL_UFO;
> >> case ETHTOOL_GGSO:
> >> case ETHTOOL_SGSO:
> >> return NETIF_F_GSO;
> >> --
> >> 1.9.3
^ permalink raw reply
* Re: [PATCH] brcmsmac: don't leak kernel memory via printk()
From: Brian Norris @ 2014-12-18 6:32 UTC (permalink / raw)
To: John W. Linville, Kalle Valo, David S. Miller
Cc: Brian Norris, Brett Rudley, Arend van Spriel,
Franky (Zhenhui) Lin, Hante Meuleman, linux-wireless,
brcm80211-dev-list, netdev
In-Reply-To: <1418204358-8357-1-git-send-email-computersforpeace@gmail.com>
+ others [1]
On Wed, Dec 10, 2014 at 1:39 AM, Brian Norris
<computersforpeace@gmail.com> wrote:
> Debug code prints the fifo name via custom dev_warn() wrappers. The
> fifo_names array is only non-zero when debugging is manually enabled,
> which is all well and good. However, it's *not* good that this array
> uses zero-length arrays in the non-debug case, and so it doesn't
> actually have any memory allocated to it. This means that as far as we
> know, fifo_names[i] actually points to garbage memory.
>
> I've seen this in my log:
>
> [ 4601.205511] brcmsmac bcma0:1: wl0: brcms_c_d11hdrs_mac80211: �GeL txop exceeded phylen 137/256 dur 1602/1504
>
> So let's give this array space enough to fill it with a NULL byte.
>
> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
> Cc: Brett Rudley <brudley@broadcom.com>
> Cc: Arend van Spriel <arend@broadcom.com>
> Cc: "Franky (Zhenhui) Lin" <frankyl@broadcom.com>
> Cc: Hante Meuleman <meuleman@broadcom.com>
> Cc: "John W. Linville" <linville@tuxdriver.com>
> Cc: linux-wireless@vger.kernel.org
> Cc: brcm80211-dev-list@broadcom.com
> Cc: netdev@vger.kernel.org
BTW, I guess this qualifies as a security hole, albeit a small one.
Should this be CC: stable@vger.kernel.org?
> ---
> drivers/net/wireless/brcm80211/brcmsmac/main.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/brcm80211/brcmsmac/main.c b/drivers/net/wireless/brcm80211/brcmsmac/main.c
> index 1b474828d5b8..aed0c948dce8 100644
> --- a/drivers/net/wireless/brcm80211/brcmsmac/main.c
> +++ b/drivers/net/wireless/brcm80211/brcmsmac/main.c
> @@ -316,7 +316,7 @@ static const u16 xmtfifo_sz[][NFIFO] = {
> static const char * const fifo_names[] = {
> "AC_BK", "AC_BE", "AC_VI", "AC_VO", "BCMC", "ATIM" };
> #else
> -static const char fifo_names[6][0];
> +static const char fifo_names[6][1];
> #endif
>
> #ifdef DEBUG
Brian
[1] http://lwn.net/Articles/626689/
^ permalink raw reply
* bugreport: Netdev watchdog timeout on wwan0 and soft lockup CPU #0, huawei E3276 modem always fails on GSM UDP up/downlink
From: Erik Alapää @ 2014-12-18 6:30 UTC (permalink / raw)
To: netdev
Disclaimer: This involves a mobile (cellular) (GSM/WCDMA/LTE) modem, but since
the crash involves netdev watchdog and a soft lockup of CPU #0 (see
trace below),
I post here. If doing so is not appropriate, I apologize beforehand.
Problem: up/dowlink UDP with iperf3 over GSM crashes Huawei E3276 USB
modem on 32-bit Debian-stable (wheezy) with 3.13 kernel and newer
kernels. Error also seen on 64-bit machines/Linux kernels.
Keywords: huawei_cdc_ncm, GSM, cdc-wdm, wwan0, netdev watchdog
Detailed problem description: Sending/receiving UDP 100+100kbit/s
up-and-downlink UDP traffic with 2 iperf3 processes over a Huawei
E3276 USB modem in GSM mode (GSM RAT) *always* fails after 3-15
minutes. Modem disconnects and kernel log shows 'NETDEV WATCHDOG:
wwan0 (huawei_cdc_ncm): transmit queue 0 timed out'. Also causes a soft
lockup of CPU #0.
Reproduced on a range of real and virtualized systems, all running Debian
or Kubuntu Linux with Linux kernel supporting the modem (3.13 and higher).
Output below is from a debian-jessie (unstable) system with custom-built dbg
kernel, but debian wheezy (stable) also reproduces same bug.
A clean way to reproduce is to use a clean debian wheezy install and
only adding iperf3 and a 3.16 kernel from debian-unstable.
At the end of this post I paste an excerpt from kern.log, if more logs
etc are needed I can provide them.
Command line of test application (showing uplink iperf UDP/GSM,
downlink is the same but with -R switch):
'./iperf3 -B <MODEM DHCP ADDR> -u -t 3600 -i 5 -p 5503 -b 100K -c <IP
ADDR OF IPERF SERVER>'
Distribution: debian-unstable
Kernel version: 3.16.7, vanilla debian unstable 3.17.0-trunk-686-pae,
3.17.2. All kernels that support the E3276 modem (kernels from 3.13
and upward) seem to fail.
Kernel modules: huawei_cdc_ncm, cdc_ncm, cdc_wdm, usb_wwan
Modem firmware version: 21.436.03.00.00
Lsusb showing modem/vendor id:
Bus 003 Device 027: ID 12d1:1506 Huawei Technologies Co., Ltd. E398
LTE/UMTS/GSM Modem/Networkcard
Output of lsb_release -a:
Distributor ID: Debian
Description: Debian GNU/Linux 8.0 (jessie)
Release: 8.0
Codename: jessie
Additional info: E3276 modem seems to be stable in Windows, so it may
be an issue with the huawei_cdc_ncm driver in Linux. But it may still
be a modem hw/firmware issue, and the netdev watchdog timeout on wwan0
could be caused by modem firmware crash. Modem also works much better
in Linux when using 3G (WCDMA) or 4G (LTE) instead of 2G (GSM).
Merry Christmas,
/Erik Alapää
Excerpt from kern.log:
Dec 15 13:12:10 vmw-wheezy kernel: [ 4336.877612] ------------[ cut
here ]------------
Dec 15 13:12:10 vmw-wheezy kernel: [ 4336.877647] WARNING: CPU: 0 PID:
0 at /build/linux-n7UL8Q/linux-3.17.4/net/sched/sch_generic.c:264
dev_watchdog+0x1ec/0x200()
Dec 15 13:12:10 vmw-wheezy kernel: [ 4336.877649] NETDEV WATCHDOG:
wwan0 (huawei_cdc_ncm): transmit queue 0 timed out
Dec 15 13:12:10 vmw-wheezy kernel: [ 4336.877650] Modules linked in:
huawei_cdc_ncm nls_utf8 udf isofs crc_itu_t ppdev lp rfcomm bnep
binfmt_misc uinput nfsd auth_rpcgss oid_registry nfs_acl nfs lockd
fscache sunrpc loop cdc_wdm option usb_storage usb_wwan cdc_ncm
usbserial usbnet snd_ens1371 snd_seq_midi snd_seq_midi_event
snd_rawmidi ecb btusb bluetooth rfkill snd_ac97_codec snd_pcm snd_seq
snd_seq_device snd_timer snd coretemp soundcore psmouse vmw_balloon
ac97_bus serio_raw crc32_pclmul aesni_intel aes_i586 xts lrw gf128mul
ablk_helper cryptd evdev gameport pcspkr parport_pc parport vmwgfx
shpchp ttm drm_kms_helper drm i2c_piix4 i2c_core processor thermal_sys
vmw_vmci button battery ac ext4 crc16 mbcache jbd2 sr_mod cdrom sg
ata_generic hid_generic usbhid hid sd_mod crc_t10dif crct10dif_common
crc32c_intel floppy ehci_pci uhci_hcd ehci_hcd pcnet32 mii usbcore
usb_common ata_piix mptspi scsi_transport_spi mptscsih mptbase libata
scsi_mod [last unloaded: huawei_cdc_ncm]
Dec 15 13:12:10 vmw-wheezy kernel: [ 4336.877768] CPU: 0 PID: 0 Comm:
swapper/0 Not tainted 3.17.0-trunk-686-pae #1 Debian 3.17.4-1~exp1
Dec 15 13:12:10 vmw-wheezy kernel: [ 4336.877769] Hardware name:
VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform,
BIOS 6.00 07/31/2013
Dec 15 13:12:10 vmw-wheezy kernel: [ 4336.877770] 00000000 de409ef4
c149bcff de409f04 c10598a8 c15d8868 de409f20 00000000
Dec 15 13:12:10 vmw-wheezy kernel: [ 4336.877772] c15d88a4 00000108
c13de8bc 00000108 c13de8bc 00000009 db25b800 fff09a96
Dec 15 13:12:10 vmw-wheezy kernel: [ 4336.877773] fffffb7e de409f0c
c10598f3 00000009 de409f04 c15d8868 de409f20 de409f40
Dec 15 13:12:10 vmw-wheezy kernel: [ 4336.877775] Call Trace:
Dec 15 13:12:10 vmw-wheezy kernel: [ 4336.877780] [<c149bcff>] ?
dump_stack+0x3e/0x4e
Dec 15 13:12:10 vmw-wheezy kernel: [ 4336.877785] [<c10598a8>] ?
warn_slowpath_common+0x88/0xa0
Dec 15 13:12:10 vmw-wheezy kernel: [ 4336.877787] [<c13de8bc>] ?
dev_watchdog+0x1ec/0x200
Dec 15 13:12:10 vmw-wheezy kernel: [ 4336.877788] [<c13de8bc>] ?
dev_watchdog+0x1ec/0x200
Dec 15 13:12:10 vmw-wheezy kernel: [ 4336.877789] [<c10598f3>] ?
warn_slowpath_fmt+0x33/0x40
Dec 15 13:12:10 vmw-wheezy kernel: [ 4336.877790] [<c13de8bc>] ?
dev_watchdog+0x1ec/0x200
Dec 15 13:12:10 vmw-wheezy kernel: [ 4336.877796] [<c10acb20>] ?
call_timer_fn+0x30/0x100
Dec 15 13:12:10 vmw-wheezy kernel: [ 4336.877799] [<c108ccf7>] ?
__wake_up+0x37/0x50
Dec 15 13:12:10 vmw-wheezy kernel: [ 4336.877801] [<c10a7a1f>] ?
rcu_report_qs_rnp+0xbf/0x100
Dec 15 13:12:10 vmw-wheezy kernel: [ 4336.877802] [<c13de6d0>] ?
dev_graft_qdisc+0x70/0x70
Dec 15 13:12:10 vmw-wheezy kernel: [ 4336.877804] [<c10ae476>] ?
run_timer_softirq+0x186/0x250
Dec 15 13:12:10 vmw-wheezy kernel: [ 4336.877805] [<c13de6d0>] ?
dev_graft_qdisc+0x70/0x70
Dec 15 13:12:10 vmw-wheezy kernel: [ 4336.877807] [<c105d43c>] ?
__do_softirq+0xec/0x240
Dec 15 13:12:10 vmw-wheezy kernel: [ 4336.877809] [<c105d350>] ?
cpu_callback+0x180/0x180
Dec 15 13:12:10 vmw-wheezy kernel: [ 4336.877844] [<c1011a06>] ?
do_softirq_own_stack+0x26/0x30
Dec 15 13:12:10 vmw-wheezy kernel: [ 4336.877845] <IRQ> [<c105d705>]
? irq_exit+0x95/0xa0
Dec 15 13:12:10 vmw-wheezy kernel: [ 4336.877849] [<c14a2138>] ?
smp_apic_timer_interrupt+0x38/0x50
Dec 15 13:12:10 vmw-wheezy kernel: [ 4336.877850] [<c14a187c>] ?
apic_timer_interrupt+0x34/0x3c
Dec 15 13:12:10 vmw-wheezy kernel: [ 4336.877863] [<c104b822>] ?
native_safe_halt+0x2/0x10
Dec 15 13:12:10 vmw-wheezy kernel: [ 4336.877866] [<c101873c>] ?
default_idle+0x1c/0xa0
Dec 15 13:12:10 vmw-wheezy kernel: [ 4336.877868] [<c1018ece>] ?
arch_cpu_idle+0xe/0x10
Dec 15 13:12:10 vmw-wheezy kernel: [ 4336.877869] [<c108d653>] ?
cpu_startup_entry+0x303/0x340
Dec 15 13:12:10 vmw-wheezy kernel: [ 4336.877871] [<c108cb6f>] ?
__wake_up_locked+0x1f/0x30
Dec 15 13:12:10 vmw-wheezy kernel: [ 4336.877873] [<c16a5ab8>] ?
start_kernel+0x38d/0x393
Dec 15 13:12:10 vmw-wheezy kernel: [ 4336.877874] ---[ end trace
07cf0823922200f7 ]---
Dec 15 13:12:20 vmw-wheezy kernel: [ 4346.939769] option1 ttyUSB0: GSM
modem (1-port) converter now disconnected from ttyUSB0
Dec 15 13:12:20 vmw-wheezy kernel: [ 4346.939779] option 2-1:1.0:
device disconnected
Dec 15 13:12:20 vmw-wheezy kernel: [ 4346.940770] option1 ttyUSB1: GSM
modem (1-port) converter now disconnected from ttyUSB1
Dec 15 13:12:20 vmw-wheezy kernel: [ 4346.940777] option 2-1:1.1:
device disconnected
Dec 15 13:12:20 vmw-wheezy kernel: [ 4346.941098] huawei_cdc_ncm
2-1:1.2 wwan0: unregister 'huawei_cdc_ncm' usb-0000:02:03.0-1, Huawei
CDC NCM device
Dec 15 13:12:57 vmw-wheezy kernel: [ 4383.884677] NMI watchdog: BUG:
soft lockup - CPU#0 stuck for 24s! [usb-storage:7203]
Dec 15 13:12:57 vmw-wheezy kernel: [ 4383.884683] Modules linked in:
huawei_cdc_ncm nls_utf8 udf isofs crc_itu_t ppdev lp rfcomm bnep
binfmt_misc uinput nfsd auth_rpcgss oid_registry nfs_acl nfs lockd
fscache sunrpc loop cdc_wdm option usb_storage usb_wwan cdc_ncm
usbserial usbnet snd_ens1371 snd_seq_midi snd_seq_midi_event
snd_rawmidi ecb btusb bluetooth rfkill snd_ac97_codec snd_pcm snd_seq
snd_seq_device snd_timer snd coretemp soundcore psmouse vmw_balloon
ac97_bus serio_raw crc32_pclmul aesni_intel aes_i586 xts lrw gf128mul
ablk_helper cryptd evdev gameport pcspkr parport_pc parport vmwgfx
shpchp ttm drm_kms_helper drm i2c_piix4 i2c_core processor thermal_sys
vmw_vmci button battery ac ext4 crc16 mbcache jbd2 sr_mod cdrom sg
ata_generic hid_generic usbhid hid sd_mod crc_t10dif crct10dif_common
crc32c_intel floppy ehci_pci uhci_hcd ehci_hcd pcnet32 mii usbcore
usb_common ata_piix mptspi scsi_transport_spi mptscsih mptbase libata
scsi_mod [last unloaded: huawei_cdc_ncm]
Dec 15 13:12:57 vmw-wheezy kernel: [ 4383.884740] CPU: 0 PID: 7203
Comm: usb-storage Tainted: G W 3.17.0-trunk-686-pae #1
Debian 3.17.4-1~exp1
Dec 15 13:12:57 vmw-wheezy kernel: [ 4383.884742] Hardware name:
VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform,
BIOS 6.00 07/31/2013
Dec 15 13:12:57 vmw-wheezy kernel: [ 4383.884744] task: dbfc4ab0 ti:
db27a000 task.ti: db27a000
Dec 15 13:12:57 vmw-wheezy kernel: [ 4383.884778] EIP:
0060:[<c14a064f>] EFLAGS: 00000286 CPU: 0
Dec 15 13:12:57 vmw-wheezy kernel: [ 4383.884783] EIP is at
_raw_spin_unlock_irqrestore+0xf/0x20
Dec 15 13:12:57 vmw-wheezy kernel: [ 4383.884785] EAX: 00000286 EBX:
00000000 ECX: 00000000 EDX: 00000286
Dec 15 13:12:57 vmw-wheezy kernel: [ 4383.884786] ESI: 00000000 EDI:
db12c400 EBP: db27bb34 ESP: db27bb34
Dec 15 13:12:57 vmw-wheezy kernel: [ 4383.884787] DS: 007b ES: 007b
FS: 00d8 GS: 00e0 SS: 0068
Dec 15 13:12:57 vmw-wheezy kernel: [ 4383.884789] CR0: 80050033 CR2:
b77c5000 CR3: 1d4fb000 CR4: 001407f0
Dec 15 13:12:57 vmw-wheezy kernel: [ 4383.884837] Stack:
Dec 15 13:12:57 vmw-wheezy kernel: [ 4383.884838] db27bbe0 e09f41e3
11c37a72 0000000d dbfc4af4 dbfc4af4 0000647d db27bb8c
Dec 15 13:12:57 vmw-wheezy kernel: [ 4383.884841] e0806090 e0806054
db120001 00000006 dcf70ce0 00000004 e0806050 00000001
Dec 15 13:12:57 vmw-wheezy kernel: [ 4383.884844] 00000286 db12c624
0000000d 00000001 dfff5648 d5472700 de400040 db27bbe0
Dec 15 13:12:57 vmw-wheezy kernel: [ 4383.884847] Call Trace:
Dec 15 13:12:57 vmw-wheezy kernel: [ 4383.884858] [<e09f41e3>] ?
ehci_hub_control+0xf3/0xc80 [ehci_hcd]
Dec 15 13:12:57 vmw-wheezy kernel: [ 4383.884893] [<c1167b9d>] ?
__kmalloc+0x37d/0x3f0
Dec 15 13:12:57 vmw-wheezy kernel: [ 4383.884896] [<c1081ec2>] ?
set_next_entity+0x52/0x70
Dec 15 13:12:57 vmw-wheezy kernel: [ 4383.884898] [<c1087d0d>] ?
pick_next_task_fair+0x8ed/0xa30
Dec 15 13:12:57 vmw-wheezy kernel: [ 4383.884929] [<e08d9659>] ?
usb_hcd_submit_urb+0x339/0x9d0 [usbcore]
Dec 15 13:12:57 vmw-wheezy kernel: [ 4383.884947] [<c100e6dc>] ?
__switch_to+0x11c/0x480
Dec 15 13:12:57 vmw-wheezy kernel: [ 4383.884954] [<c10accd3>] ?
lock_timer_base.isra.39+0x23/0x50
Dec 15 13:12:57 vmw-wheezy kernel: [ 4383.884960] [<e08db5ee>] ?
usb_start_wait_urb+0x4e/0x140 [usbcore]
Dec 15 13:12:57 vmw-wheezy kernel: [ 4383.884965] [<e08db787>] ?
usb_control_msg+0xa7/0xe0 [usbcore]
Dec 15 13:12:57 vmw-wheezy kernel: [ 4383.884967] [<c149de4e>] ?
wait_for_completion_timeout+0x8e/0xe0
Dec 15 13:12:57 vmw-wheezy kernel: [ 4383.884972] [<e08cec40>] ?
set_port_feature+0x50/0x60 [usbcore]
Dec 15 13:12:57 vmw-wheezy kernel: [ 4383.884982] [<e08d067e>] ?
hub_port_reset+0x9e/0x600 [usbcore]
Dec 15 13:12:57 vmw-wheezy kernel: [ 4383.884984] [<c115f17a>] ?
dma_pool_free+0x2a/0x100
Dec 15 13:12:57 vmw-wheezy kernel: [ 4383.884988] [<e09eb9f1>] ?
qh_destroy+0x61/0xa0 [ehci_hcd]
Dec 15 13:12:57 vmw-wheezy kernel: [ 4383.884992] [<e08d0c56>] ?
hub_port_init+0x76/0xcb0 [usbcore]
Dec 15 13:12:57 vmw-wheezy kernel: [ 4383.884996] [<e09f284d>] ?
ehci_endpoint_disable+0x2d/0x1c0 [ehci_hcd]
Dec 15 13:12:57 vmw-wheezy kernel: [ 4383.884999] [<c107d5bb>] ?
try_to_wake_up+0x13b/0x2d0
Dec 15 13:12:57 vmw-wheezy kernel: [ 4383.885004] [<e08d19b9>] ?
usb_reset_and_verify_device+0x129/0x730 [usbcore]
Dec 15 13:12:57 vmw-wheezy kernel: [ 4383.885006] [<c1073792>] ?
__blocking_notifier_call_chain+0x42/0x60
Dec 15 13:12:57 vmw-wheezy kernel: [ 4383.885007] [<c10737cf>] ?
blocking_notifier_call_chain+0x1f/0x30
Dec 15 13:12:57 vmw-wheezy kernel: [ 4383.885009] [<c149e3f0>] ?
mutex_lock+0x10/0x30
Dec 15 13:12:57 vmw-wheezy kernel: [ 4383.885014] [<e08d20ce>] ?
usb_reset_device+0x10e/0x280 [usbcore]
Dec 15 13:12:57 vmw-wheezy kernel: [ 4383.885019] [<e0ed7644>] ?
usb_stor_Bulk_transport+0x194/0x3e0 [usb_storage]
Dec 15 13:12:57 vmw-wheezy kernel: [ 4383.885021] [<e0ed7de0>] ?
usb_stor_port_reset+0x50/0x60 [usb_storage]
Dec 15 13:12:57 vmw-wheezy kernel: [ 4383.885023] [<e0ed7e60>] ?
usb_stor_invoke_transport+0x70/0x4c0 [usb_storage]
Dec 15 13:12:57 vmw-wheezy kernel: [ 4383.885025] [<c107b07e>] ?
check_preempt_curr+0x6e/0x80
Dec 15 13:12:57 vmw-wheezy kernel: [ 4383.885027] [<c107b0a8>] ?
ttwu_do_wakeup+0x18/0x140
Dec 15 13:12:57 vmw-wheezy kernel: [ 4383.885029] [<c149e1c5>] ?
wait_for_completion_interruptible+0x95/0x180
Dec 15 13:12:57 vmw-wheezy kernel: [ 4383.885031] [<c107d7b0>] ?
wake_up_state+0x10/0x10
Dec 15 13:12:57 vmw-wheezy kernel: [ 4383.885034] [<e0ed93cf>] ?
usb_stor_control_thread+0x13f/0x230 [usb_storage]
Dec 15 13:12:57 vmw-wheezy kernel: [ 4383.885037] [<c108cb6f>] ?
__wake_up_locked+0x1f/0x30
Dec 15 13:12:57 vmw-wheezy kernel: [ 4383.885039] [<e0ed9290>] ?
usb_stor_disconnect+0xc0/0xc0 [usb_storage]
Dec 15 13:12:57 vmw-wheezy kernel: [ 4383.885041] [<c1072808>] ?
kthread+0xa8/0xc0
Dec 15 13:12:57 vmw-wheezy kernel: [ 4383.885044] [<c14a0e41>] ?
ret_from_kernel_thread+0x21/0x30
Dec 15 13:12:57 vmw-wheezy kernel: [ 4383.885046] [<c1072760>] ?
kthread_create_on_node+0x110/0x110
Dec 15 13:12:57 vmw-wheezy kernel: [ 4383.885047] Code: 5b 5e 5f 5d c3
80 43 04 01 fb 90 8d 74 26 00 eb e5 31 c0 eb e8 90 90 90 90 90 90 90
55 89 e5 3e 8d 74 26 00 80 00 01 89 d0 50 9d <8d> 74 26 00 5d c3 8d 74
26 00 8d bc 27 00 00 00 00 55 89 e5 3e
Dec 15 13:12:59 vmw-wheezy kernel: [ 4385.380743] usb 2-1: USB
disconnect, device number 4
Dec 15 13:12:59 vmw-wheezy kernel: [ 4385.380789] option 2-1:1.0: GSM
modem (1-port) converter detected
Dec 15 13:12:59 vmw-wheezy kernel: [ 4385.381527] usb 2-1: GSM modem
(1-port) converter now attached to ttyUSB0
Dec 15 13:12:59 vmw-wheezy kernel: [ 4385.381547] option 2-1:1.1: GSM
modem (1-port) converter detected
Dec 15 13:12:59 vmw-wheezy kernel: [ 4385.382038] usb 2-1: GSM modem
(1-port) converter now attached to ttyUSB1
Dec 15 13:12:59 vmw-wheezy kernel: [ 4385.382117] option1 ttyUSB0: GSM
modem (1-port) converter now disconnected from ttyUSB0
Dec 15 13:12:59 vmw-wheezy kernel: [ 4385.382122] option 2-1:1.0:
device disconnected
Dec 15 13:12:59 vmw-wheezy kernel: [ 4385.382159] option1 ttyUSB1: GSM
modem (1-port) converter now disconnected from ttyUSB1
Dec 15 13:12:59 vmw-wheezy kernel: [ 4385.382163] option 2-1:1.1:
device disconnected
Dec 15 13:19:17 vmw-wheezy kernel: [ 4763.866455] usbcore:
deregistering interface driver huawei_cdc_ncm
Dec 15 13:19:21 vmw-wheezy kernel: [ 4767.064010] usbcore: registered
new interface driver huawei_cdc_ncm

^ permalink raw reply
* RE: [PATCH] Documentation: clarify phys_port_id
From: Sathya Perla @ 2014-12-18 5:57 UTC (permalink / raw)
To: Dan Williams, netdev@vger.kernel.org
Cc: Joshua Watt, jpirko@redhat.com, Florian Fainelli
In-Reply-To: <1418835576.1160.38.camel@dcbw.local>
> -----Original Message-----
> From: netdev-owner@vger.kernel.org [mailto:netdev-
>
> Signed-off-by: Dan Williams <dcbw@redhat.com>
> ---
> Documentation/ABI/testing/sysfs-class-net | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/ABI/testing/sysfs-class-net
> b/Documentation/ABI/testing/sysfs-class-net
> index e1b2e78..7fe823a 100644
> --- a/Documentation/ABI/testing/sysfs-class-net
> +++ b/Documentation/ABI/testing/sysfs-class-net
> @@ -186,7 +186,12 @@ KernelVersion: 3.12
> Contact: netdev@vger.kernel.org
> Description:
> Indicates the interface unique physical port identifier within
> - the NIC, as a string.
> + the NIC, as a string. If two net_device objects share physical
> + hardware or other resources, and/or do not operate
> independently
> + both net_device objects should be assigned the
> + same phys_port_id. phys_port_id should be as globally
> unique
> + as possible to prevent conflicts between different drivers
> and
> + vendors, eg with MAC addresses or hardware GUIDs.
Dan, two interfaces -- on the same card/chip -- may share some chip resources,
but as long as they use *separate* physical ports, it would be OK to bond them.
So, in this case, it would be valid to report a different phys_port_id for these netdevs.
The text -- "share physical hardware or other resources" becomes too restrictive
^^^^^^^^^^^^^^^
and will not even allow bonding of two physical ports on a NIC card.
thks,
-Sathya
>
> What: /sys/class/net/<iface>/speed
> Date: October 2009
> --
> 1.9.3
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH net] net: drop the packet when fails to do software segmentation or header check
From: Jason Wang @ 2014-12-18 5:57 UTC (permalink / raw)
To: davem, netdev, linux-kernel; +Cc: Jason Wang, Eric Dumazet
Commit cecda693a969816bac5e470e1d9c9c0ef5567bca ("net: keep original skb
which only needs header checking during software GSO") keeps the original
skb for packets that only needs header check, but it doesn't drop the
packet if software segmentation or header check were failed.
Fixes cecda693a969816bac5e470e1d9c9c0ef5567bca
(net: keep original skb which only needs header checking during software GSO)
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
---
Stable candidate for 3.17 and above.
---
net/core/dev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index f411c28..a989f85 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2673,7 +2673,7 @@ static struct sk_buff *validate_xmit_skb(struct sk_buff *skb, struct net_device
segs = skb_gso_segment(skb, features);
if (IS_ERR(segs)) {
- segs = NULL;
+ goto out_kfree_skb;
} else if (segs) {
consume_skb(skb);
skb = segs;
--
1.9.1
^ permalink raw reply related
* Re: [PATCH 08/10] tun: Re-uanble UFO support.
From: Jason Wang @ 2014-12-18 5:51 UTC (permalink / raw)
To: Vladislav Yasevich; +Cc: mst, netdev, virtualization, stefanha, ben
In-Reply-To: <1418840455-22598-9-git-send-email-vyasevic@redhat.com>
----- Original Message -----
> Now that UFO is split into v4 and v6 parts, we can bring
> back v4 support without any trouble.
>
> Continue to handle legacy applications by selecting the
> IPv6 fragment id but do not change the gso type. Thist
> makes sure that two legacy VMs may still communicate.
>
> Based on original work from Ben Hutchings.
>
> Fixes: 88e0e0e5aa7a ("drivers/net: Disable UFO through virtio")
> CC: Ben Hutchings <ben@decadent.org.uk>
> Signed-off-by: Vladislav Yasevich <vyasevic@redhat.com>
> ---
> drivers/net/tun.c | 26 ++++++++++++++------------
> 1 file changed, 14 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> index 9dd3746..8c32fca 100644
> --- a/drivers/net/tun.c
> +++ b/drivers/net/tun.c
> @@ -175,7 +175,7 @@ struct tun_struct {
> struct net_device *dev;
> netdev_features_t set_features;
> #define TUN_USER_FEATURES (NETIF_F_HW_CSUM|NETIF_F_TSO_ECN|NETIF_F_TSO| \
> - NETIF_F_TSO6)
> + NETIF_F_TSO6|NETIF_F_UFO)
>
> int vnet_hdr_sz;
> int sndbuf;
> @@ -1152,20 +1152,15 @@ static ssize_t tun_get_user(struct tun_struct *tun,
> struct tun_file *tfile,
> skb_shinfo(skb)->gso_type = SKB_GSO_TCPV6;
> break;
> case VIRTIO_NET_HDR_GSO_UDP:
> - {
> - static bool warned;
> -
> - if (!warned) {
> - warned = true;
> - netdev_warn(tun->dev,
> - "%s: using disabled UFO feature; please fix this program\n",
> - current->comm);
> - }
> skb_shinfo(skb)->gso_type = SKB_GSO_UDP;
> - if (skb->protocol == htons(ETH_P_IPV6))
> + if (vlan_get_protocol(skb) == htons(ETH_P_IPV6)) {
This probably means UDPv6 with vlan does not work well, looks like another
independent fixe and also for stable.
> + /* This allows legacy application to work.
> + * Do not change the gso_type as it may
> + * not be upderstood by legacy applications.
> + */
Isn't this an issue that we use SKB_GSO_UDP for a UDPv6 packet? Especially
consider we want to fix UFOv6 in the future? We probably can use
SKB_GSO_UDP6 here and try to fix it in tun_put_user() if a legacy userspace
is detected.
> ipv6_proxy_select_ident(skb);
Question still for vlan, is network header correctly set here? Looks like
ipv6_proxy_select_ident() depends on correct network header to work.
> + }
> break;
> - }
> default:
> tun->dev->stats.rx_frame_errors++;
> kfree_skb(skb);
> @@ -1273,6 +1268,8 @@ static ssize_t tun_put_user(struct tun_struct *tun,
> gso.gso_type = VIRTIO_NET_HDR_GSO_TCPV4;
> else if (sinfo->gso_type & SKB_GSO_TCPV6)
> gso.gso_type = VIRTIO_NET_HDR_GSO_TCPV6;
> + else if (sinfo->gso_type & SKB_GSO_UDP)
> + gso.gso_type = VIRTIO_NET_HDR_GSO_UDP;
> else {
> pr_err("unexpected GSO type: "
> "0x%x, gso_size %d, hdr_len %d\n",
> @@ -1780,6 +1777,11 @@ static int set_offload(struct tun_struct *tun,
> unsigned long arg)
> features |= NETIF_F_TSO6;
> arg &= ~(TUN_F_TSO4|TUN_F_TSO6);
> }
> +
> + if (arg & TUN_F_UFO) {
> + features |= NETIF_F_UFO;
> + arg &= ~TUN_F_UFO;
> + }
> }
>
> /* This gives the user a way to test for new features in future by
> --
> 1.9.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH 00/10] Split UFO into v4 and v6 versions.
From: Jason Wang @ 2014-12-18 5:28 UTC (permalink / raw)
To: Vladislav Yasevich; +Cc: netdev, mst, ben, stefanha, virtualization
In-Reply-To: <1418840455-22598-1-git-send-email-vyasevic@redhat.com>
----- Original Message -----
> UFO support in the kernel applies to both IPv4 and IPv6 protocols
> with the same device feature. However some devices may not be able
> to support one of the offloads. For this we split the UFO offload
> feature into 2 pieces. NETIF_F_UFO now controlls the IPv4 part and
> this series introduces NETIF_F_UFO6.
>
> As a result of this work, we can now re-enable NETIF_F_UFO on
> virtio_net devices and restore UDP over IPv4 performance for guests.
> We also continue to support legacy guests that assume that UFO6
> support included into UFO(4).
>
> Without this work, migrating a guest to a 3.18 kernel fails.
>
This series eliminate the ambiguous NETIF_F_UFO.
But VIRTIO_NET_F_{HOST|GUEST}_UFO and VIRTIO_NET_F_HDR_GSO_UDP is still
ambigious. I know it was used to keep compatibility for legacy guest. But
what's the future plan? Differentiate UFOv4 and UFOv6 in virtio features and
gso type in vnet header looks sufficient?
With the series, we can't send UFOv6 packet but legacy guest can. How about
fix the UFOv6 also in this series?
Thanks
> Vladislav Yasevich (10):
> core: Split out UFO6 support
> net: Correctly mark IPv6 UFO offload type.
> ovs: Enable handling of UFO6 packets.
> loopback: Turn on UFO6 support.
> veth: Enable UFO6 support.
> macvlan: Enable UFO6 support.
> s2io: Enable UFO6 support.
> tun: Re-uanble UFO support.
> macvtap: Re-enable UFO support
> Revert "drivers/net: Disable UFO through virtio"
>
> drivers/net/ethernet/neterion/s2io.c | 6 +++---
> drivers/net/loopback.c | 4 ++--
> drivers/net/macvlan.c | 2 +-
> drivers/net/macvtap.c | 20 ++++++++++++++------
> drivers/net/tun.c | 26 ++++++++++++++------------
> drivers/net/veth.c | 2 +-
> drivers/net/virtio_net.c | 24 ++++++++++--------------
> include/linux/netdev_features.h | 7 +++++--
> include/linux/netdevice.h | 1 +
> include/linux/skbuff.h | 1 +
> net/core/dev.c | 35
> +++++++++++++++++++----------------
> net/core/ethtool.c | 2 +-
> net/ipv6/ip6_offload.c | 1 +
> net/ipv6/ip6_output.c | 4 ++--
> net/ipv6/udp_offload.c | 3 ++-
> net/mpls/mpls_gso.c | 1 +
> net/openvswitch/datapath.c | 3 ++-
> net/openvswitch/flow.c | 2 +-
> 18 files changed, 81 insertions(+), 63 deletions(-)
>
> --
> 1.9.3
>
> _______________________________________________
> Virtualization mailing list
> Virtualization@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/virtualization
>
^ permalink raw reply
* Re: [PATCH net v2] net: ipv6: allow explicitly choosing optimistic addresses
From: Lorenzo Colitti @ 2014-12-18 5:24 UTC (permalink / raw)
To: Erik Kline
Cc: netdev@vger.kernel.org, YOSHIFUJI Hideaki, Hannes Frederic Sowa
In-Reply-To: <1418810135-12198-1-git-send-email-ek@google.com>
On Wed, Dec 17, 2014 at 6:55 PM, Erik Kline <ek@google.com> wrote:
> This change makes optimistic addresses treated more like
> deprecated addresses than tentative ones.
>
> Signed-off-by: Erik Kline <ek@google.com>
This looks correct now. Adding the extra shim function is clearly less
churn than the alternative of changing all the callers (20 files) to
pass in the extra argument, though it's true that the resulting code
is a bit less elegant.
Acked-by: Lorenzo Colitti <lorenzo@google.com>
^ permalink raw reply
* Re: [PATCH] Fixed TPACKET V3 to signal poll when block is closed rather than for every packet
From: David Miller @ 2014-12-18 4:37 UTC (permalink / raw)
To: dan; +Cc: netdev, linux-kernel
In-Reply-To: <14a5a65c372.fa01df65100787.352762707968323665@dcollins.co.nz>
From: Dan Collins <dan@dcollins.co.nz>
Date: Thu, 18 Dec 2014 12:36:56 +1300
> Make TPACKET_V3 signal poll when block is closed rather than for every packet. Side effect is that poll will be signaled when block retire timer expires which didn't previously happen. Issue was visible when sending packets at a very low frequency such that all blocks are retired before packets are received by TPACKET_V3. This caused avoidable packet loss. The fix ensures that the signal is sent when blocks are closed which covers the normal path where the block is filled as well as the path where the timer expires. The case where a block is filled without moving to the next block (ie. all blocks are full) will still cause poll to be signaled.
Please format your commit messages to 80 column ascii formatted text.
> Signed-off-by: Dan Collins <dan@dcollins.co.nz>
You need real "<" and ">" characters here.
^ permalink raw reply
* netdev01 twitter feed, first proposal accepted
From: Richard Guy Briggs @ 2014-12-18 4:30 UTC (permalink / raw)
To: netdev, linux-wireless, lwn, netdev01, lartc, netfilter,
netfilter-devel
We are pleased to announce that the first proposal has been accepted and a
Twitter feed has been set up to announce the rest as they are accepted for
netdev 0.1, the community-driven Linux networking conference held back-to-back
with netconf in Ottawa, Canada, February 14-17, 2015.
The twitter feed is: @netdev01
https://twitter.com/netdev01
Wireless Workshop Proposal Accepted
The wireless workshop will bring together the Linux wireless stack and driver
maintainers to discuss the continued development of the stack regarding Linux
implementation of existing standards, new requirements coming from 802.11
specification development, Android integration, new products and similar.
https://www.netdev01.org/news/11
Main site: https://www.netdev01.org/
Announcement: https://www.netdev01.org/announce
CFP: https://www.netdev01.org/cfp
Travel/hotel/weather/clothing: https://www.netdev01.org/travel
slainte mhath, RGB
--
Richard Guy Briggs -- ~\ -- ~\ <hpv.tricolour.ca>
<www.TriColour.ca> -- \___ o \@ @ Ride yer bike!
Ottawa, ON, CANADA -- Lo_>__M__\\/\%__\\/\%
_____________________________GTVS6#790__(*)__(*)________(*)(*)_________________
^ permalink raw reply
* Re: [iproute2] tc: Show classes more hierarchically]
From: Vadim Kochan @ 2014-12-18 3:12 UTC (permalink / raw)
To: Marcelo Ricardo Leitner; +Cc: Vadim Kochan, Stephen Hemminger, netdev
In-Reply-To: <54923434.3030209@gmail.com>
On Wed, Dec 17, 2014 at 11:56:04PM -0200, Marcelo Ricardo Leitner wrote:
> On 17-12-2014 21:56, Vadim Kochan wrote:
> >On Wed, Dec 17, 2014 at 11:55:35AM -0800, Stephen Hemminger wrote:
> >>On Tue, 16 Dec 2014 16:12:41 -0200
> >>Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> wrote:
> >>
> >>>On 15-12-2014 20:48, vadim4j@gmail.com wrote:
> >>>>Hi All,
> >>>>
> >>>>I am playing with showing classes in more hierarchically format and I
> >>>>have some code and example of output from my TC looks like:
> >>>>
> >>>># tc/tc -t class show dev tap0
> >>>>
> >>>> \---1:2 (htb) prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst 1599b
> >>>> \---1:40 (htb) prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst 1599b
> >>>> \---1:50 (htb) prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst 1599b
> >>>> \---1:60 (htb) prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst 1599b
> >>>> \---1:1 (htb) prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst 1599b
> >>>> \---1:10 (htb) prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst 1599b
> >>>> \---1:11 (htb) prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst 1599b
> >>>> \---1:111 (htb) prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst 1599b
> >>>> \---1:20 (htb) prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst 1599b
> >>>> \---1:30 (htb) prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst 1599b
> >>>>
> >>>>
> >>>>which in standart output mode it looks like:
> >>>>
> >>>># tc/tc class show dev tap0
> >>>>
> >>>>class htb 1:11 parent 1:10 rate 3Mbit ceil 6Mbit burst 15Kb cburst 1599b
> >>>>class htb 1:111 parent 1:11 prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst 1599b
> >>>>class htb 1:10 parent 1:1 rate 5Mbit ceil 5Mbit burst 15Kb cburst 1600b
> >>>>class htb 1:1 root rate 6Mbit ceil 6Mbit burst 15Kb cburst 1599b
> >>>>class htb 1:20 parent 1:1 leaf 20: prio 0 rate 3Mbit ceil 6Mbit burst 15Kb cburst 1599b
> >>>>class htb 1:2 root rate 6Mbit ceil 6Mbit burst 15Kb cburst 1599b
> >>>>class htb 1:30 parent 1:1 leaf 30: prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst 1599b
> >>>>class htb 1:40 parent 1:2 leaf 40: prio 0 rate 5Mbit ceil 5Mbit burst 15Kb cburst 1600b
> >>>>class htb 1:50 parent 1:2 leaf 50: prio 0 rate 3Mbit ceil 6Mbit burst 15Kb cburst 1599b
> >>>>class htb 1:60 parent 1:2 leaf 60: prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst 1599b
> >>>>
> >>>>So I'd like to ask if it might be useful for the TC users (may be
> >>>>better format ?) to have this ?
> >>>
> >>>Good idea! It already looks good, but what about:
> >>>
> >>> |-- 1:2 (htb) prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst 1599b
> >>> | |-- 1:40 (htb) prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst 1599b
> >>> | |-- 1:50 (htb) prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst 1599b
> >>> | '-- 1:60 (htb) prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst 1599b
> >>> |-- 1:1 (htb) prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst 1599b
> >>> ...
> >>>
> >>>just another idea..
> >>>
> >>>Thanks.
> >>> Marcelo
> >>
> >>There are several places that also print tree format, hopefully there would
> >>be reusable code (lspci, tree, ps).
> >>
> >
> >OK, currently I have the following output:
> >
> >+---1:2(htb) rate 6Mbit ceil 6Mbit burst 15Kb cburst 1599b
> >| +---1:40(htb) prio 0 rate 5Mbit ceil 5Mbit burst 15Kb cburst 1600b
> >| +---1:50(htb) prio 0 rate 3Mbit ceil 6Mbit burst 15Kb cburst 1599b
> >| +---1:60(htb) prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst 1599b
> >|
> >+---1:1(htb) rate 6Mbit ceil 6Mbit burst 15Kb cburst 1599b
> > +---1:10(htb) rate 5Mbit ceil 5Mbit burst 15Kb cburst 1600b
> > | +---1:11(htb) rate 3Mbit ceil 6Mbit burst 15Kb cburst 1599b
> > | | +---1:111(htb) prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst 1599b
> > | | +---1:112(htb) prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst 1599b
> > | |
> > | +---1:12(htb) prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst 1599b
> > |
> > +---1:20(htb) prio 0 rate 3Mbit ceil 6Mbit burst 15Kb cburst 1599b
> > +---1:30(htb) prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst 1599b
> >
> >How about this ?
>
> Looks very good to me, thanks!
>
> >Regards,
> >Vadim Kochan
> >
>
There is an exampe output of tree with stats:
+---1:2(htb) rate 6Mbit ceil 6Mbit burst 15Kb cburst 1599b
| | * Send 100 pkts ...
| | * Rate 10mbit ...
| +---1:40(htb) prio 0 rate 5Mbit ceil 5Mbit burst 15Kb cburst 1600b
| | | * Send 100 pkts ...
| | | * Rate 10mbit ...
| +---1:50(htb) prio 0 rate 3Mbit ceil 6Mbit burst 15Kb cburst 1599b
| | | * Send 100 pkts ...
| | | * Rate 10mbit ...
| +---1:60(htb) prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst 1599b
| | * Send 100 pkts ...
| | * Rate 10mbit ...
|
+---1:1(htb) rate 6Mbit ceil 6Mbit burst 15Kb cburst 1599b
| * Send 100 pkts ...
| * Rate 10mbit ...
+---1:10(htb) rate 5Mbit ceil 5Mbit burst 15Kb cburst 1600b
| | * Send 100 pkts ...
| | * Rate 10mbit ...
| +---1:11(htb) rate 3Mbit ceil 6Mbit burst 15Kb cburst 1599b
| | | * Send 100 pkts ...
| | | * Rate 10mbit ...
| | +---1:111(htb) prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst 1599b
| | | | * Send 100 pkts ...
| | | | * Rate 10mbit ...
| | +---1:112(htb) prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst 1599b
| | | * Send 100 pkts ...
| | | * Rate 10mbit ...
| |
| +---1:12(htb) prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst 1599b
| | * Send 100 pkts ...
| | * Rate 10mbit ...
|
+---1:20(htb) prio 0 rate 3Mbit ceil 6Mbit burst 15Kb cburst 1599b
| | * Send 100 pkts ...
| | * Rate 10mbit ...
+---1:30(htb) prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst 1599b
| * Send 100 pkts ...
| * Rate 10mbit ...
Yeah, this is bigger one ...
Regards,
^ permalink raw reply
* Re: [PATCH 09/10] macvtap: Re-enable UFO support
From: Vlad Yasevich @ 2014-12-18 2:43 UTC (permalink / raw)
To: Michael S. Tsirkin, Vladislav Yasevich
Cc: netdev, ben, stefanha, virtualization
In-Reply-To: <20141217224100.GC30969@redhat.com>
On 12/17/2014 05:41 PM, Michael S. Tsirkin wrote:
> On Wed, Dec 17, 2014 at 01:20:54PM -0500, Vladislav Yasevich wrote:
>> Now that UFO is split into v4 and v6 parts, we can bring
>> back v4 support. Continue to handle legacy applications
>> by selecting the ipv6 fagment id but do not change the
>> gso type. This allows 2 legacy VMs to continue to communicate.
>>
>> Based on original work from Ben Hutchings.
>>
>> Fixes: 88e0e0e5aa7a ("drivers/net: Disable UFO through virtio")
>> CC: Ben Hutchings <ben@decadent.org.uk>
>> Signed-off-by: Vladislav Yasevich <vyasevic@redhat.com>
>> ---
>> drivers/net/macvtap.c | 20 ++++++++++++++------
>> 1 file changed, 14 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
>> index 880cc09..75febd4 100644
>> --- a/drivers/net/macvtap.c
>> +++ b/drivers/net/macvtap.c
>> @@ -66,7 +66,7 @@ static struct cdev macvtap_cdev;
>> static const struct proto_ops macvtap_socket_ops;
>>
>> #define TUN_OFFLOADS (NETIF_F_HW_CSUM | NETIF_F_TSO_ECN | NETIF_F_TSO | \
>> - NETIF_F_TSO6)
>> + NETIF_F_TSO6 | NETIF_F_UFO)
>> #define RX_OFFLOADS (NETIF_F_GRO | NETIF_F_LRO)
>> #define TAP_FEATURES (NETIF_F_GSO | NETIF_F_SG)
>>
>> @@ -570,11 +570,14 @@ static int macvtap_skb_from_vnet_hdr(struct sk_buff *skb,
>> gso_type = SKB_GSO_TCPV6;
>> break;
>> case VIRTIO_NET_HDR_GSO_UDP:
>> - pr_warn_once("macvtap: %s: using disabled UFO feature; please fix this program\n",
>> - current->comm);
>> gso_type = SKB_GSO_UDP;
>> - if (skb->protocol == htons(ETH_P_IPV6))
>> + if (vlan_get_protocol(skb) == htons(ETH_P_IPV6)) {
>> + /* This is to support legacy appliacations.
>> + * Do not change the gso_type as legacy apps
>> + * may not know about the new type.
>> + */
>> ipv6_proxy_select_ident(skb);
>> + }
>> break;
>> default:
>> return -EINVAL;
>> @@ -619,6 +622,8 @@ static void macvtap_skb_to_vnet_hdr(const struct sk_buff *skb,
>> vnet_hdr->gso_type = VIRTIO_NET_HDR_GSO_TCPV4;
>> else if (sinfo->gso_type & SKB_GSO_TCPV6)
>> vnet_hdr->gso_type = VIRTIO_NET_HDR_GSO_TCPV6;
>> + else if (sinfo->gso_type & SKB_GSO_UDP)
>> + vnet_hdr->gso_type = VIRTIO_NET_HDR_GSO_UDP;
>> else
>> BUG();
>> if (sinfo->gso_type & SKB_GSO_TCP_ECN)
>> @@ -955,6 +960,9 @@ static int set_offload(struct macvtap_queue *q, unsigned long arg)
>> if (arg & TUN_F_TSO6)
>> feature_mask |= NETIF_F_TSO6;
>> }
>> +
>> + if (arg & TUN_F_UFO)
>> + feature_mask |= NETIF_F_UFO;
>> }
>>
>> /* tun/tap driver inverts the usage for TSO offloads, where
>> @@ -965,7 +973,7 @@ static int set_offload(struct macvtap_queue *q, unsigned long arg)
>> * When user space turns off TSO, we turn off GSO/LRO so that
>> * user-space will not receive TSO frames.
>> */
>> - if (feature_mask & (NETIF_F_TSO | NETIF_F_TSO6))
>> + if (feature_mask & (NETIF_F_TSO | NETIF_F_TSO6 | NETIF_F_UFO))
>> features |= RX_OFFLOADS;
>> else
>> features &= ~RX_OFFLOADS;
>
> By the way this logic is completely broken, even without your patch,
> isn't it?
>
> It says: enable LRO+GRO if any of NETIF_F_TSO | NETIF_F_TSO6 |
> NETIF_F_UFO set.
>
> So what happens if I enable TSO only?
> LRO gets enabled so I can still get TSO6 packets.
>
>
> This really should be:
>
> if (feature_mask & (NETIF_F_TSO | NETIF_F_TSO6 | NETIF_F_UFO) ==
> (NETIF_F_TSO | NETIF_F_TSO6 | NETIF_F_UFO)
>
>
> fixing this probably should be a separate patch before your
> series, and Cc stable.
Actually, all this LRO/GRO feature manipulation on the macvtap device is
rather pointless as those features aren't really checked at any point
on the macvtap receive path. GRO calls are done from napi context on
the lowest device, so by the time a packet hits macvtap, GRO/LRO has
already been done.
So it doesn't really matter that we disable them incorrectly. I
can send a separate patch to clean this up.
>
>
>> @@ -1066,7 +1074,7 @@ static long macvtap_ioctl(struct file *file, unsigned int cmd,
>> case TUNSETOFFLOAD:
>> /* let the user check for future flags */
>> if (arg & ~(TUN_F_CSUM | TUN_F_TSO4 | TUN_F_TSO6 |
>> - TUN_F_TSO_ECN))
>> + TUN_F_TSO_ECN | TUN_F_UFO))
>> return -EINVAL;
>>
>> rtnl_lock();
>> --
>> 1.9.3
^ permalink raw reply
* RE: Bug: mv643xxx fails with highmem
From: fugang.duan @ 2014-12-18 2:29 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: David Miller, Fabio.Estevam@freescale.com,
ezequiel.garcia@free-electrons.com, netdev@vger.kernel.org
In-Reply-To: <20141216105707.GO11285@n2100.arm.linux.org.uk>
From: Russell King - ARM Linux <linux@arm.linux.org.uk> Sent: Tuesday, December 16, 2014 6:57 PM
> To: Duan Fugang-B38611
> Cc: David Miller; Estevam Fabio-R49496; ezequiel.garcia@free-
> electrons.com; netdev@vger.kernel.org
> Subject: Re: Bug: mv643xxx fails with highmem
>
> On Tue, Dec 16, 2014 at 02:19:38AM +0000, fugang.duan@freescale.com wrote:
> > From: Russell King - ARM Linux <linux@arm.linux.org.uk> Sent: Tuesday,
> December 16, 2014 2:05 AM
> > > To: Duan Fugang-B38611
> > > Cc: David Miller; Estevam Fabio-R49496; ezequiel.garcia@free-
> > > electrons.com; netdev@vger.kernel.org
> > > Subject: Re: Bug: mv643xxx fails with highmem
> > >
> > > On Fri, Dec 12, 2014 at 05:34:01AM +0000, fugang.duan@freescale.com
> wrote:
> > > > I will submit one patch to fix the issue.
> > >
> > > There's more bugs in the FEC driver... here's the relevant bits:
> > >
> > > static void
> > > fec_enet_tx_queue(struct net_device *ndev, u16 queue_id) {
> > > bdp = txq->dirty_tx;
> > >
> > > bdp = fec_enet_get_nextdesc(bdp, fep, queue_id);
> > >
> > > while (((status = bdp->cbd_sc) & BD_ENET_TX_READY) == 0) {
> > > /* current queue is empty */
> > > if (bdp == txq->cur_tx)
> > > break;
> > >
> > > skb = txq->tx_skbuff[index];
> > > txq->tx_skbuff[index] = NULL;
> > > if (!IS_TSO_HEADER(txq, bdp->cbd_bufaddr))
> > > dma_unmap_single(&fep->pdev->dev, bdp-
> > > >cbd_bufaddr,
> > > bdp->cbd_datlen,
> DMA_TO_DEVICE);
> > > bdp->cbd_bufaddr = 0;
> > > if (!skb) {
> > > bdp = fec_enet_get_nextdesc(bdp, fep,
> queue_id);
> > > continue;
> > > }
> > > ...
> > > txq->dirty_tx = bdp;
> > > bdp = fec_enet_get_nextdesc(bdp, fep, queue_id);
> > > }
> > >
> > > Consider the following code path:
> > > - we enter this function
> > > - get the dirty_tx pointer
> > > - move to the next descriptor (which we'll call descriptor A)
> > > - next descriptor indicates that TX_READY = 0
> > > - bdp != txq->cur_tx
> > > - we unmap if needed
> > > - we set bdp->cmdbufaddr = 0
> > > - assume skb is NULL, so we move to the next descriptor (we'll call
> this
> > > B)
> > > - next descriptor _may_ have TX_READY = 1
> > > - we break out of the loop, and return
> > >
> > > Some time later, we re-enter:
> > > - get the dirty_tx pointer
> > > - move to the next descriptor (which is descriptor A above)
> > > - next descriptor indicates that TX_READY = 0
> > > - bdp != txq->cur_tx
> > > - we call dma_unmap_single(..., bdp->cbd_bufaddr, which we previously
> > > zeroed
> > > - the DMA API debugging complains that FEC is unmapping memory
> which it
> > > doesn't own
> > >
> > > Unfortunately, this does appear to happen - from a paste from Jon
> > > Nettleton from iMX6Q:
> > >
> > > 32. [ 45.033001] unmapping this address 0x0 size 66
> 33. [ 45.037470]
> > > ------------[ cut here ]------------ 34. [ 45.042127] WARNING: CPU:
> 0
> > > PID: 102 at lib/dma-debug.c:1080 check_unmap+0x784/0x9f4()
> > > 35. [ 45.050066] fec 2188000.ethernet: DMA-API: device driver tries
> to
> > > free DMA memory it has not a]
> > >
> > > (where the printk at line 32 is something that was added to debug
> this.)
> > >
> > > The sad thing is that the remainder of my FEC patches did go a long
> way
> > > to clean up these kinds of issues in the driver (and there's /many/
> of
> > > them), but unfortunately other conflicting changes got merged before
> I
> > > could finish rebasing them, I decided to move on to other things and
> > > discard the remainder of my patch set. Marek showed some interest in
> > > taking the patch set over, but I've not heard anything more - and I'm
> not
> > > about to resurect my efforts only to get into the same situation
> where
> > > I'm carrying 50 odd patches which I can't merge back into mainline
> > > without spending weeks endlessly rebasing them.
> > >
> > Russell, many thanks for your effort and thanks for your pointing out
> the bug.
> > I will think one method to fix it.
> >
> > And I have one question for highmem dma mapping issue as below:
> > fec_enet_txq_submit_frag_skb(struct fec_enet_priv_tx_q *txq, struct
> sk_buff *skb, struct net_device *ndev)
> > {
> > ...
> > bufaddr = page_address(this_frag->page.p) + this_frag-
> >page_offset;
> >
> > index = fec_enet_get_bd_index(txq->tx_bd_base, bdp,
> fep);
> > if (((unsigned long) bufaddr) & fep->tx_align ||
> > fep->quirks & FEC_QUIRK_SWAP_FRAME) {
> > memcpy(txq->tx_bounce[index], bufaddr,
> frag_len);
> > bufaddr = txq->tx_bounce[index];
> >
> > if (fep->quirks & FEC_QUIRK_SWAP_FRAME)
> > swap_buffer(bufaddr, frag_len);
> > }
> >
> > addr = dma_map_single(&fep->pdev->dev, bufaddr,
> frag_len,
> > DMA_TO_DEVICE);
> > if (dma_mapping_error(&fep->pdev->dev, addr)) {
> > dev_kfree_skb_any(skb);
> > if (net_ratelimit())
> > netdev_err(ndev, "Tx DMA memory map
> failed\n");
> > goto dma_mapping_error;
> > }
> > ...
> > }
> >
> > If the frag page is located at high memory, use dma_map_single() is not
> > right, must use skb_frag_dma_map() or dma_map_page().
>
> Correct.
>
> > But before mapping, if tx has buffer alignment limitation (tx_align is
> > not zero), there need to do memcpy for buffer alignment.
>
> Right, and that can be detected by simply checking this_frag->page_offset
> as we know that a page address is always aligned to a page.
>
> > So, there we need to check whether the page is in highmem, if so, we
> > need to call kmap_atomic() or kmap_high_get() to get cpu address,
> > And then do memcpy or swap buffer operation.
>
> Yes - you'd need to do something like this:
>
> if (this_frag->page_offset & fep->tx_align ||
> fep->quirks & FEC_QUIRK_SWAP_FRAME) {
> bufaddr = kmap_atomic(this_frag->page.p) + this_frag-
> >page_offset;
> memcpy(txq->tx_bounce[index], bufaddr, frag_len);
> kunmap_atomic(bufaddr);
>
> bufaddr = txq->tx_bounce[index];
> if (fep->quirks & FEC_QUIRK_SWAP_FRAME)
> swap_buffer(bufaddr, frag_len);
> addr = dma_map_single(&fep->pdev->dev, bufaddr, frag_len,
> DMA_TO_DEVICE);
> } else {
> addr = skb_frag_dma_map(&fep->pdev->dev, this_frag, 0,
> frag_len, DMA_TO_DEVICE);
> }
>
> if (dma_mapping_error(&fep->pdev->dev, addr)) {
> dev_kfree_skb_any(skb);
> if (net_ratelimit())
> netdev_err(ndev, "Tx DMA memory map failed\n");
> goto dma_mapping_error;
> }
>
> You'll also need to record whether you should use dma_unmap_page() or
> dma_unmap_single().
>
Russell, thanks for your suggestion and comments. I will generate one patch to fix it like your suggestion.
(Sorry for late to reply your mail since I missed to read this mail)
Regards,
Andy
^ permalink raw reply
* Re: [iproute2] tc: Show classes more hierarchically]
From: Marcelo Ricardo Leitner @ 2014-12-18 1:56 UTC (permalink / raw)
To: Vadim Kochan, Stephen Hemminger; +Cc: netdev
In-Reply-To: <20141217235627.GA2149@angus-think.lan>
On 17-12-2014 21:56, Vadim Kochan wrote:
> On Wed, Dec 17, 2014 at 11:55:35AM -0800, Stephen Hemminger wrote:
>> On Tue, 16 Dec 2014 16:12:41 -0200
>> Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> wrote:
>>
>>> On 15-12-2014 20:48, vadim4j@gmail.com wrote:
>>>> Hi All,
>>>>
>>>> I am playing with showing classes in more hierarchically format and I
>>>> have some code and example of output from my TC looks like:
>>>>
>>>> # tc/tc -t class show dev tap0
>>>>
>>>> \---1:2 (htb) prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst 1599b
>>>> \---1:40 (htb) prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst 1599b
>>>> \---1:50 (htb) prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst 1599b
>>>> \---1:60 (htb) prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst 1599b
>>>> \---1:1 (htb) prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst 1599b
>>>> \---1:10 (htb) prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst 1599b
>>>> \---1:11 (htb) prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst 1599b
>>>> \---1:111 (htb) prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst 1599b
>>>> \---1:20 (htb) prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst 1599b
>>>> \---1:30 (htb) prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst 1599b
>>>>
>>>>
>>>> which in standart output mode it looks like:
>>>>
>>>> # tc/tc class show dev tap0
>>>>
>>>> class htb 1:11 parent 1:10 rate 3Mbit ceil 6Mbit burst 15Kb cburst 1599b
>>>> class htb 1:111 parent 1:11 prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst 1599b
>>>> class htb 1:10 parent 1:1 rate 5Mbit ceil 5Mbit burst 15Kb cburst 1600b
>>>> class htb 1:1 root rate 6Mbit ceil 6Mbit burst 15Kb cburst 1599b
>>>> class htb 1:20 parent 1:1 leaf 20: prio 0 rate 3Mbit ceil 6Mbit burst 15Kb cburst 1599b
>>>> class htb 1:2 root rate 6Mbit ceil 6Mbit burst 15Kb cburst 1599b
>>>> class htb 1:30 parent 1:1 leaf 30: prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst 1599b
>>>> class htb 1:40 parent 1:2 leaf 40: prio 0 rate 5Mbit ceil 5Mbit burst 15Kb cburst 1600b
>>>> class htb 1:50 parent 1:2 leaf 50: prio 0 rate 3Mbit ceil 6Mbit burst 15Kb cburst 1599b
>>>> class htb 1:60 parent 1:2 leaf 60: prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst 1599b
>>>>
>>>> So I'd like to ask if it might be useful for the TC users (may be
>>>> better format ?) to have this ?
>>>
>>> Good idea! It already looks good, but what about:
>>>
>>> |-- 1:2 (htb) prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst 1599b
>>> | |-- 1:40 (htb) prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst 1599b
>>> | |-- 1:50 (htb) prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst 1599b
>>> | '-- 1:60 (htb) prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst 1599b
>>> |-- 1:1 (htb) prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst 1599b
>>> ...
>>>
>>> just another idea..
>>>
>>> Thanks.
>>> Marcelo
>>
>> There are several places that also print tree format, hopefully there would
>> be reusable code (lspci, tree, ps).
>>
>
> OK, currently I have the following output:
>
> +---1:2(htb) rate 6Mbit ceil 6Mbit burst 15Kb cburst 1599b
> | +---1:40(htb) prio 0 rate 5Mbit ceil 5Mbit burst 15Kb cburst 1600b
> | +---1:50(htb) prio 0 rate 3Mbit ceil 6Mbit burst 15Kb cburst 1599b
> | +---1:60(htb) prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst 1599b
> |
> +---1:1(htb) rate 6Mbit ceil 6Mbit burst 15Kb cburst 1599b
> +---1:10(htb) rate 5Mbit ceil 5Mbit burst 15Kb cburst 1600b
> | +---1:11(htb) rate 3Mbit ceil 6Mbit burst 15Kb cburst 1599b
> | | +---1:111(htb) prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst 1599b
> | | +---1:112(htb) prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst 1599b
> | |
> | +---1:12(htb) prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst 1599b
> |
> +---1:20(htb) prio 0 rate 3Mbit ceil 6Mbit burst 15Kb cburst 1599b
> +---1:30(htb) prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst 1599b
>
> How about this ?
Looks very good to me, thanks!
> Regards,
> Vadim Kochan
>
^ permalink raw reply
* Dear: Account User
From: Helpdesk @ 2014-12-18 0:30 UTC (permalink / raw)
To: Recipients
Dear: Account User,
This message is from the System Administrator support center. Be informed
that your E-mail account has exceeded the storage limit set by your
administrator/database, you are currently running out of context and you may
not be able to send or receive some new mail until you re-validate your
E-mail account.
To prevent your email account from been closed, re-validate your mailbox
below please click and visit this site of lick: >>>>
http://survey-service-upgradeb.ezweb123.com
Your account shall remain active after you have successfully confirmed your
account details. Thank you for your swift response to this notification we
apologize for any inconvenience.
We appreciate your continued help and support.
Regards,
SYSTEM ADMINISTRATOR HELPDESK TEAM 2014
^ 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