* Re: [PATCH v2 1/1] tcp: fixing TLP's FIN recovery
From: David Miller @ 2014-10-07 20:17 UTC (permalink / raw)
To: joshhunt00
Cc: per.hurtig, eric.dumazet, panweiping3, nanditad, netdev,
anna.brunstrom, mohammad.rajiullah, ncardwell, sergei.shtylyov
In-Reply-To: <CAKA=qzZ+L67Z4O7DY0hR_N=5VFSZ2_Dn0to+8WLqnpfgQg+00Q@mail.gmail.com>
From: Josh Hunt <joshhunt00@gmail.com>
Date: Tue, 7 Oct 2014 10:03:29 -0500
> On Thu, Jun 12, 2014 at 1:06 PM, David Miller <davem@davemloft.net> wrote:
>> From: Per Hurtig <per.hurtig@kau.se>
>> Date: Thu, 12 Jun 2014 17:08:32 +0200
>>
>>> Fix to a problem observed when losing a FIN segment that does not
>>> contain data. In such situations, TLP is unable to recover from
>>> *any* tail loss and instead adds at least PTO ms to the
>>> retransmission process, i.e., RTO = RTO + PTO.
>>>
>>> Signed-off-by: Per Hurtig <per.hurtig@kau.se>
>>
>> Applied, thanks.
>
> Can we queue this up for stable? 2cd0d743b05e87 (tcp: fix
> tcp_match_skb_to_sack() for unaligned SACK at end of an skb) is
> already in stable and based on the changelog was put in place to fix a
> case that this patch introduced:
>
> "This was visible now because the recently simplified TLP logic in
> bef1909ee3ed1c ("tcp: fixing TLP's FIN recovery") could find that 0-byte
> skb at the end of the write queue, and now that we do not check that
> skb's length we could send it as a TLP probe."
>
> However, the patch to fix TLP's FIN recovery is not in -stable.
Queued up for -stable, thanks.
^ permalink raw reply
* [PATCH 1/1 net-next] af_unix: remove NULL assignment on static
From: Fabian Frederick @ 2014-10-07 20:16 UTC (permalink / raw)
To: linux-kernel; +Cc: Fabian Frederick, David S. Miller, netdev
static values are automatically initialized to NULL
Signed-off-by: Fabian Frederick <fabf@skynet.be>
---
net/unix/garbage.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/unix/garbage.c b/net/unix/garbage.c
index 9bc73f8..99f7012 100644
--- a/net/unix/garbage.c
+++ b/net/unix/garbage.c
@@ -258,7 +258,7 @@ static void inc_inflight_move_tail(struct unix_sock *u)
list_move_tail(&u->link, &gc_candidates);
}
-static bool gc_in_progress = false;
+static bool gc_in_progress;
#define UNIX_INFLIGHT_TRIGGER_GC 16000
void wait_for_unix_gc(void)
--
1.9.3
^ permalink raw reply related
* Re: [PATCH] net: Add ndo_gso_check
From: David Miller @ 2014-10-07 20:15 UTC (permalink / raw)
To: therbert; +Cc: netdev, gerlitz.or
In-Reply-To: <CA+mtBx9u9j0m+VWJLN-Svs2ZeZpUMdP6aLdNbcAFYGzgebektQ@mail.gmail.com>
From: Tom Herbert <therbert@google.com>
Date: Tue, 7 Oct 2014 11:13:08 -0700
> I don't think there are any outstanding objections to this patch.
> Will you be able to apply it or do you need something more to be done?
Making it compile would be nice:
drivers/net/macvtap.c: In function ‘macvtap_handle_frame’:
drivers/net/macvtap.c:301:2: warning: passing argument 1 of ‘netif_needs_gso’ from incompatible pointer type [enabled by default]
In file included from include/linux/etherdevice.h:26:0,
from drivers/net/macvtap.c:1:
include/linux/netdevice.h:3554:20: note: expected ‘struct net_device *’ but argument is of type ‘struct sk_buff *’
drivers/net/macvtap.c:301:2: warning: passing argument 2 of ‘netif_needs_gso’ makes pointer from integer without a cast [enabled by default]
In file included from include/linux/etherdevice.h:26:0,
from drivers/net/macvtap.c:1:
include/linux/netdevice.h:3554:20: note: expected ‘struct sk_buff *’ but argument is of type ‘netdev_features_t’
drivers/net/macvtap.c:301:2: error: too few arguments to function ‘netif_needs_gso’
In file included from include/linux/etherdevice.h:26:0,
from drivers/net/macvtap.c:1:
include/linux/netdevice.h:3554:20: note: declared here
^ permalink raw reply
* [PATCH 1/1 net-next] wimax: convert printk to pr_foo()
From: Fabian Frederick @ 2014-10-07 20:12 UTC (permalink / raw)
To: linux-kernel
Cc: Fabian Frederick, Inaky Perez-Gonzalez, linux-wimax,
David S. Miller, netdev
Use current logging functions and add module name prefix.
Signed-off-by: Fabian Frederick <fabf@skynet.be>
---
Compiled but untested.
net/wimax/id-table.c | 2 +-
net/wimax/op-msg.c | 9 ++++-----
net/wimax/op-reset.c | 3 +--
net/wimax/op-rfkill.c | 3 +--
net/wimax/op-state-get.c | 3 +--
net/wimax/stack.c | 7 +++----
net/wimax/wimax-internal.h | 6 ++++++
7 files changed, 17 insertions(+), 16 deletions(-)
diff --git a/net/wimax/id-table.c b/net/wimax/id-table.c
index 72273ab..a21508d 100644
--- a/net/wimax/id-table.c
+++ b/net/wimax/id-table.c
@@ -137,7 +137,7 @@ void wimax_id_table_release(void)
#endif
spin_lock(&wimax_id_table_lock);
list_for_each_entry(wimax_dev, &wimax_id_table, id_table_node) {
- printk(KERN_ERR "BUG: %s wimax_dev %p ifindex %d not cleared\n",
+ pr_err("BUG: %s wimax_dev %p ifindex %d not cleared\n",
__func__, wimax_dev, wimax_dev->net_dev->ifindex);
WARN_ON(1);
}
diff --git a/net/wimax/op-msg.c b/net/wimax/op-msg.c
index c278b33..54aa146 100644
--- a/net/wimax/op-msg.c
+++ b/net/wimax/op-msg.c
@@ -189,7 +189,7 @@ const void *wimax_msg_data_len(struct sk_buff *msg, size_t *size)
nla = nlmsg_find_attr(nlh, sizeof(struct genlmsghdr),
WIMAX_GNL_MSG_DATA);
if (nla == NULL) {
- printk(KERN_ERR "Cannot find attribute WIMAX_GNL_MSG_DATA\n");
+ pr_err("Cannot find attribute WIMAX_GNL_MSG_DATA\n");
return NULL;
}
*size = nla_len(nla);
@@ -211,7 +211,7 @@ const void *wimax_msg_data(struct sk_buff *msg)
nla = nlmsg_find_attr(nlh, sizeof(struct genlmsghdr),
WIMAX_GNL_MSG_DATA);
if (nla == NULL) {
- printk(KERN_ERR "Cannot find attribute WIMAX_GNL_MSG_DATA\n");
+ pr_err("Cannot find attribute WIMAX_GNL_MSG_DATA\n");
return NULL;
}
return nla_data(nla);
@@ -232,7 +232,7 @@ ssize_t wimax_msg_len(struct sk_buff *msg)
nla = nlmsg_find_attr(nlh, sizeof(struct genlmsghdr),
WIMAX_GNL_MSG_DATA);
if (nla == NULL) {
- printk(KERN_ERR "Cannot find attribute WIMAX_GNL_MSG_DATA\n");
+ pr_err("Cannot find attribute WIMAX_GNL_MSG_DATA\n");
return -EINVAL;
}
return nla_len(nla);
@@ -343,8 +343,7 @@ int wimax_gnl_doit_msg_from_user(struct sk_buff *skb, struct genl_info *info)
d_fnstart(3, NULL, "(skb %p info %p)\n", skb, info);
result = -ENODEV;
if (info->attrs[WIMAX_GNL_MSG_IFIDX] == NULL) {
- printk(KERN_ERR "WIMAX_GNL_MSG_FROM_USER: can't find IFIDX "
- "attribute\n");
+ pr_err("WIMAX_GNL_MSG_FROM_USER: can't find IFIDX attribute\n");
goto error_no_wimax_dev;
}
ifindex = nla_get_u32(info->attrs[WIMAX_GNL_MSG_IFIDX]);
diff --git a/net/wimax/op-reset.c b/net/wimax/op-reset.c
index eb45807..a420791 100644
--- a/net/wimax/op-reset.c
+++ b/net/wimax/op-reset.c
@@ -107,8 +107,7 @@ int wimax_gnl_doit_reset(struct sk_buff *skb, struct genl_info *info)
d_fnstart(3, NULL, "(skb %p info %p)\n", skb, info);
result = -ENODEV;
if (info->attrs[WIMAX_GNL_RESET_IFIDX] == NULL) {
- printk(KERN_ERR "WIMAX_GNL_OP_RFKILL: can't find IFIDX "
- "attribute\n");
+ pr_err("WIMAX_GNL_OP_RFKILL: can't find IFIDX attribute\n");
goto error_no_wimax_dev;
}
ifindex = nla_get_u32(info->attrs[WIMAX_GNL_RESET_IFIDX]);
diff --git a/net/wimax/op-rfkill.c b/net/wimax/op-rfkill.c
index 403078d..7d73054 100644
--- a/net/wimax/op-rfkill.c
+++ b/net/wimax/op-rfkill.c
@@ -421,8 +421,7 @@ int wimax_gnl_doit_rfkill(struct sk_buff *skb, struct genl_info *info)
d_fnstart(3, NULL, "(skb %p info %p)\n", skb, info);
result = -ENODEV;
if (info->attrs[WIMAX_GNL_RFKILL_IFIDX] == NULL) {
- printk(KERN_ERR "WIMAX_GNL_OP_RFKILL: can't find IFIDX "
- "attribute\n");
+ pr_err("WIMAX_GNL_OP_RFKILL: can't find IFIDX attribute\n");
goto error_no_wimax_dev;
}
ifindex = nla_get_u32(info->attrs[WIMAX_GNL_RFKILL_IFIDX]);
diff --git a/net/wimax/op-state-get.c b/net/wimax/op-state-get.c
index 995c08c..e6788d2 100644
--- a/net/wimax/op-state-get.c
+++ b/net/wimax/op-state-get.c
@@ -49,8 +49,7 @@ int wimax_gnl_doit_state_get(struct sk_buff *skb, struct genl_info *info)
d_fnstart(3, NULL, "(skb %p info %p)\n", skb, info);
result = -ENODEV;
if (info->attrs[WIMAX_GNL_STGET_IFIDX] == NULL) {
- printk(KERN_ERR "WIMAX_GNL_OP_STATE_GET: can't find IFIDX "
- "attribute\n");
+ pr_err("WIMAX_GNL_OP_STATE_GET: can't find IFIDX attribute\n");
goto error_no_wimax_dev;
}
ifindex = nla_get_u32(info->attrs[WIMAX_GNL_STGET_IFIDX]);
diff --git a/net/wimax/stack.c b/net/wimax/stack.c
index ec8b577..3f816e2 100644
--- a/net/wimax/stack.c
+++ b/net/wimax/stack.c
@@ -191,8 +191,8 @@ void __check_new_state(enum wimax_st old_state, enum wimax_st new_state,
unsigned int allowed_states_bm)
{
if (WARN_ON(((1 << new_state) & allowed_states_bm) == 0)) {
- printk(KERN_ERR "SW BUG! Forbidden state change %u -> %u\n",
- old_state, new_state);
+ pr_err("SW BUG! Forbidden state change %u -> %u\n",
+ old_state, new_state);
}
}
@@ -602,8 +602,7 @@ int __init wimax_subsys_init(void)
wimax_gnl_ops,
wimax_gnl_mcgrps);
if (unlikely(result < 0)) {
- printk(KERN_ERR "cannot register generic netlink family: %d\n",
- result);
+ pr_err("cannot register generic netlink family: %d\n", result);
goto error_register_family;
}
diff --git a/net/wimax/wimax-internal.h b/net/wimax/wimax-internal.h
index b445b82..733c4bf 100644
--- a/net/wimax/wimax-internal.h
+++ b/net/wimax/wimax-internal.h
@@ -30,6 +30,12 @@
#define __WIMAX_INTERNAL_H__
#ifdef __KERNEL__
+#ifdef pr_fmt
+#undef pr_fmt
+#endif
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
#include <linux/device.h>
#include <net/wimax.h>
--
1.9.3
^ permalink raw reply related
* Re: Quota in __qdisc_run()
From: Jesper Dangaard Brouer @ 2014-10-07 20:07 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: Eric Dumazet, David Miller, hannes, netdev, therbert, fw,
dborkman, jhs, alexander.duyck, john.r.fastabend, dave.taht, toke
In-Reply-To: <20141007203700.00e883a1@redhat.com>
On Tue, 7 Oct 2014 20:37:00 +0200
Jesper Dangaard Brouer <brouer@redhat.com> wrote:
> On Tue, 07 Oct 2014 10:32:12 -0700
> Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
> > On Tue, 2014-10-07 at 13:19 -0400, David Miller wrote:
> >
> > > Yes, this makes sense, do a full qdisc_restart() cycle without boundaries,
> > > then check how much quota was used afterwards to guard the outermost loop.
> >
> > I am testing this, and also am testing the xmit_more patch for I40E.
>
> Check, I'm also testing both yours and Hannes patch.
>
> Results at:
> http://people.netfilter.org/hawk/qdisc/measure18_restore_quota_fairness/
> http://people.netfilter.org/hawk/qdisc/measure19_restore_quota_erics/
> http://people.netfilter.org/hawk/qdisc/measure20_no_quota_baseline_at_git_02c0fc1/
These tests are with ixgbe with a single TXQ, in-order to measure the
effect of HoL, by taking advantage of the high prio queue of pfifo_fast.
(Cmdline trick for a single TXQ: "ethtool -L eth4 combined 1")
In case GSO=off TSO=off, Hannes "wins" with 0.04ms
http://people.netfilter.org/hawk/qdisc/measure19_restore_quota_erics/compare_rr_latency_eric_vs_hannes_NoneXSO.png
which I guess we should not be concerned with.
In case GSO=on TSO=off, the diff is max 0.01ms (to Hannes advantage ;-))
Notice the extreme zoom level:
http://people.netfilter.org/hawk/qdisc/measure19_restore_quota_erics/compare_rr_latency_eric_vs_hannes_GSO.png
In case GSO=on TSO=on, there are some spikes, where Eric's version have
the highest spike.
http://people.netfilter.org/hawk/qdisc/measure19_restore_quota_erics/compare_rr_latency_eric_vs_hannes_TSO.png
Again nothing we should worry about.
Thus, guess we can safely go with Eric's solution, even-thought Hannes
version consistently shows less HoL blocking and less sever spikes, as
the difference is so small. I'm ACKing Eric's version...
We do need this patch, as can be seen by the baseline test at git
commit 02c0fc1. Where some bandwidth unfairness to the UDP flows
happens, but only in the case GSO=off TSO=off (others are fine).
http://people.netfilter.org/hawk/qdisc/measure20_no_quota_baseline_at_git_02c0fc1/NoneXSO_10Gbit_base_02c0fc1_bandwidth_totals_unfairness.png
Kind of strange, but it went away in the two quota tests.
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Sr. Network Kernel Developer at Red Hat
Author of http://www.iptv-analyzer.org
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: [PATCH net-next] icmp6: Add new icmpv6 type for RPL control message
From: David Miller @ 2014-10-07 19:55 UTC (permalink / raw)
To: hannes; +Cc: simon.vincent, netdev
In-Reply-To: <1412639626.712591.175897305.2FA01596@webmail.messagingengine.com>
From: Hannes Frederic Sowa <hannes@stressinduktion.org>
Date: Tue, 07 Oct 2014 01:53:46 +0200
> Might be possible, but I would favor to get rid of the printk or move
> the test for informational icmp notifications up.
> Some of the type < 128 icmp (non-informal) packets we also report to
> user space, so we cannot just add them to a blacklist.
So basically:
diff --git a/net/ipv6/icmp.c b/net/ipv6/icmp.c
index 141e1f3..97ae700 100644
--- a/net/ipv6/icmp.c
+++ b/net/ipv6/icmp.c
@@ -777,12 +777,12 @@ static int icmpv6_rcv(struct sk_buff *skb)
break;
default:
- LIMIT_NETDEBUG(KERN_DEBUG "icmpv6: msg of unknown type\n");
-
/* informational */
if (type & ICMPV6_INFOMSG_MASK)
break;
+ LIMIT_NETDEBUG(KERN_DEBUG "icmpv6: msg of unknown type\n");
+
/*
* error of unknown type.
* must pass to upper level
^ permalink raw reply related
* Re: [ovs-dev] linux-next: Tree for Oct 7 (openvswitch)
From: Andy Zhou @ 2014-10-07 19:45 UTC (permalink / raw)
To: Randy Dunlap
Cc: Stephen Rothwell, Linux-Next, dev@openvswitch.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <54341BD7.3070207@infradead.org>
This issue should have been fixed with commit
7c5df8fa1921450d2210db9928f43cf4f414982c
Fix a openvswitch compilation error when CONFIG_INET is not set:
=====================================================
In file included from include/net/geneve.h:4:0,
from net/openvswitch/flow_netlink.c:45:
include/net/udp_tunnel.h: In function 'udp_tunnel_hand
>> include/net/udp_tunnel.h:100:2: error: implicit dec
>> return iptunnel_handle_offloads(skb, udp_csum,
>> ^
>> >> include/net/udp_tunnel.h:100:2: warnin
>> >> cc1: some warnings being treated as
=====================================================
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Andy Zhou <azhou@nicira.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
On Tue, Oct 7, 2014 at 9:59 AM, Randy Dunlap <rdunlap@infradead.org> wrote:
> On 10/07/14 01:44, Stephen Rothwell wrote:
>> Hi all,
>>
>> Changes since 20141003:
>>
>
> on i386 or x86_64:
>
> In file included from ../include/net/geneve.h:4:0,
> from ../net/openvswitch/flow_netlink.c:45:
> ../include/net/udp_tunnel.h: In function 'udp_tunnel_handle_offloads':
> ../include/net/udp_tunnel.h:100:2: error: implicit declaration of function 'iptunnel_handle_offloads' [-Werror=implicit-function-declaration]
> return iptunnel_handle_offloads(skb, udp_csum, type);
> ^
> ../include/net/udp_tunnel.h:100:2: warning: return makes pointer from integer without a cast [enabled by default]
>
>
>
> --
> ~Randy
> _______________________________________________
> dev mailing list
> dev@openvswitch.org
> http://openvswitch.org/mailman/listinfo/dev
^ permalink raw reply
* Re: [PATCH V1 net-next 1/2] pgtable: Add API to query if write combining is available
From: David Miller @ 2014-10-07 19:44 UTC (permalink / raw)
To: ogerlitz; +Cc: netdev, amirv, jackm, moshel, talal, yevgenyp
In-Reply-To: <1412497342-12451-2-git-send-email-ogerlitz@mellanox.com>
From: Or Gerlitz <ogerlitz@mellanox.com>
Date: Sun, 5 Oct 2014 11:22:21 +0300
> From: Moshe Lazer <moshel@mellanox.com>
>
> Currently the kernel write-combining interface provides a best effort
> mechanism in which the caller simply invokes pgprot_writecombine().
>
> If write combining is available, the region is mapped for it, otherwise
> the region is (silently) mapped as non-cached.
>
> In some cases, however, the calling driver must know if write combining
> is available, so a silent best effort mechanism is not sufficient.
>
> Add writecombine_available(), which returns true if the system
> supports write combining and false if it doesn't.
>
> Signed-off-by: Moshe Lazer <moshel@mellanox.com>
> Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
> Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
This needs some ACKs from MM developers.
But also the situation is more complicated than a simple boolean test.
On some platforms you have to test first whether the range you are
trying to write combine can legally be marked in that way. The DRM
layer has all of these per-arch tests to do this properly.
#if defined(__i386__) || defined(__x86_64__)
if (map->type == _DRM_REGISTERS && !(map->flags & _DRM_WRITE_COMBINING))
tmp = pgprot_noncached(tmp);
else
tmp = pgprot_writecombine(tmp);
#elif defined(__powerpc__)
pgprot_val(tmp) |= _PAGE_NO_CACHE;
if (map->type == _DRM_REGISTERS)
pgprot_val(tmp) |= _PAGE_GUARDED;
#elif defined(__ia64__)
if (efi_range_is_wc(vma->vm_start, vma->vm_end -
vma->vm_start))
tmp = pgprot_writecombine(tmp);
else
tmp = pgprot_noncached(tmp);
#elif defined(__sparc__) || defined(__arm__) || defined(__mips__)
tmp = pgprot_noncached(tmp);
#endif
^ permalink raw reply
* Re: sunvnet and ->xmit_more
From: David Miller @ 2014-10-07 19:38 UTC (permalink / raw)
To: sowmini.varadhan; +Cc: netdev, david.stevens, Raghuram.Kothakota
In-Reply-To: <20141007192922.GA31406@oracle.com>
From: Sowmini Varadhan <sowmini.varadhan@oracle.com>
Date: Tue, 7 Oct 2014 15:29:22 -0400
> I'm not sure how this can be useful to sunvnet- in sunvnet's case
> we send the TX indication at the *start* of a burst, so if xmit_more
> was set, sure- we can send out another packet immediately, and
> avoid another START message (which we already do today), but
> nothing else to be gained from xmit_more?
If you defer that __vnet_tx_trigger() call through all the ->xmit_more
SKBs, then you are less likely to see the DRING_STOPPED event from the
peer which will make you have to send a START again.
So, for an xmit_more burst of 3, instead of:
->ndo_start_xmit()
__vnet_tx_trigger()
->ndo_start_xmit()
IRQ -> vnet_ack() -> STOPPED
->ndo_start_xmit()
__vnet_tx_trigger()
You would do something like:
->ndo_start_xmit()
->ndo_start_xmit()
->ndo_start_xmit()
__vnet_tx_trigger()
> BTW, I have most of the NAPI done, getting it stress-tested etc
> (the recent jumbo commit added a few more races between vnet_port_remove
> and vnet_start_xmit, thanks to the extra clean_timer) but I figure
> I might as well fully test this internally since net-next is closed
> for the moment anyway?
Yeah no rush.
^ permalink raw reply
* Re: Quota in __qdisc_run()
From: Jesper Dangaard Brouer @ 2014-10-07 19:34 UTC (permalink / raw)
To: Eric Dumazet
Cc: David Miller, hannes, netdev, therbert, fw, dborkman, jhs,
alexander.duyck, john.r.fastabend, dave.taht, toke, brouer
In-Reply-To: <1412709015.11091.158.camel@edumazet-glaptop2.roam.corp.google.com>
On Tue, 07 Oct 2014 12:10:15 -0700
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Tue, 2014-10-07 at 20:03 +0200, Jesper Dangaard Brouer wrote:
>
> > According to my measurements, at 10Gbit/s TCP_STREAM test the BQL limit
> > is 381528 bytes / 1514 = 252 packets, that will (potentially) be bulk
> > dequeued at once (with your version of the patch).
> >
>
> That's because you use a single queue maybe ?
No, I just double checked.
I was using a single netperf TCP_STREAM with GRO=off TSO=off.
> Here we have limits around 2 TSO packets.
Which should be approx 128k
Just tested with GRO=on TSO=on single TCP_STREAM, which is weird as I
should hit your 2xTSO limit right, and inflight shows 408780.
And I do have (which I guess is the 2xTSO):
/proc/sys/net/ipv4/tcp_limit_output_bytes:131072
$ grep -H . /sys/class/net/eth4/queues/tx-*/byte_queue_limits/{inflight,limit}
/sys/class/net/eth4/queues/tx-0/byte_queue_limits/inflight:0
/sys/class/net/eth4/queues/tx-10/byte_queue_limits/inflight:0
/sys/class/net/eth4/queues/tx-11/byte_queue_limits/inflight:0
/sys/class/net/eth4/queues/tx-1/byte_queue_limits/inflight:0
/sys/class/net/eth4/queues/tx-2/byte_queue_limits/inflight:0
/sys/class/net/eth4/queues/tx-3/byte_queue_limits/inflight:0
/sys/class/net/eth4/queues/tx-4/byte_queue_limits/inflight:0
/sys/class/net/eth4/queues/tx-5/byte_queue_limits/inflight:0
/sys/class/net/eth4/queues/tx-6/byte_queue_limits/inflight:0
/sys/class/net/eth4/queues/tx-7/byte_queue_limits/inflight:0
/sys/class/net/eth4/queues/tx-8/byte_queue_limits/inflight:408780
/sys/class/net/eth4/queues/tx-9/byte_queue_limits/inflight:0
/sys/class/net/eth4/queues/tx-0/byte_queue_limits/limit:340848
/sys/class/net/eth4/queues/tx-10/byte_queue_limits/limit:340650
/sys/class/net/eth4/queues/tx-11/byte_queue_limits/limit:367902
/sys/class/net/eth4/queues/tx-1/byte_queue_limits/limit:272520
/sys/class/net/eth4/queues/tx-2/byte_queue_limits/limit:204390
/sys/class/net/eth4/queues/tx-3/byte_queue_limits/limit:162856
/sys/class/net/eth4/queues/tx-4/byte_queue_limits/limit:158314
/sys/class/net/eth4/queues/tx-5/byte_queue_limits/limit:136260
/sys/class/net/eth4/queues/tx-6/byte_queue_limits/limit:140802
/sys/class/net/eth4/queues/tx-7/byte_queue_limits/limit:152258
/sys/class/net/eth4/queues/tx-8/byte_queue_limits/limit:340650
/sys/class/net/eth4/queues/tx-9/byte_queue_limits/limit:340650
Strange...
> Even with only 4 tx queues I have :
>
> # sar -n DEV 3 3 |grep eth1
> 12:05:19 PM eth1 147217.67 809066.67 9488.71 1196207.78 0.00 0.00 0.00
> 12:05:22 PM eth1 145958.00 807822.33 9407.48 1194366.73 0.00 0.00 0.00
> 12:05:25 PM eth1 147502.33 804739.33 9507.26 1189804.23 0.00 0.00 0.33
> Average: eth1 146892.67 807209.44 9467.82 1193459.58 0.00 0.00 0.11
>
>
> grep . /sys/class/net/eth1/queues/tx*/byte_queue_limits/{inflight,limit}
> /sys/class/net/eth1/queues/tx-0/byte_queue_limits/inflight:115064
> /sys/class/net/eth1/queues/tx-1/byte_queue_limits/inflight:0
> /sys/class/net/eth1/queues/tx-2/byte_queue_limits/inflight:0
> /sys/class/net/eth1/queues/tx-3/byte_queue_limits/inflight:0
> /sys/class/net/eth1/queues/tx-0/byte_queue_limits/limit:102952
> /sys/class/net/eth1/queues/tx-1/byte_queue_limits/limit:124148
> /sys/class/net/eth1/queues/tx-2/byte_queue_limits/limit:102952
> /sys/class/net/eth1/queues/tx-3/byte_queue_limits/limit:136260
Guess this is okay, 115064 / 1514 = 76 pkts which is closer to the 64 weight_p.
> > It seems to have the potential to exceed the weight_p(64) quite a lot.
> > And with e.g. TX ring size 512, we also also challenge the drivers at
> > this early adoption phase of tailptr writes. Just saying...
> >
>
> Yep, but remind we want to squeeze bugs out of the drivers, then add
> additional knobs later.
Okay, for squeezing out bugs, then I understand this more aggressive
bulking strategy. I'm all in then!
> Whatever limit we choose in core networking stack (being 64 packets for
> example), hardware might have different constraints that need to be
> taken care of in the driver.
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Sr. Network Kernel Developer at Red Hat
Author of http://www.iptv-analyzer.org
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: sunvnet and ->xmit_more
From: Sowmini Varadhan @ 2014-10-07 19:29 UTC (permalink / raw)
To: David Miller; +Cc: netdev, david.stevens, Raghuram.Kothakota
In-Reply-To: <20141007.151849.84417269004453869.davem@davemloft.net>
On (10/07/14 15:18), David Miller wrote:
>
> David and others working on sunvnet, I just wanted to point out that
> in the net-next tree there is a new facility that can improve
> performance quite a bit in sunvnet.
>
> Basically in the ->ndo_start_xmit() handler, if you see skb->xmit_more
> set then the stack is telling you that it guarentees that another
> packet will be given to you immediately when ->ndo_start_xmit()
> returns.
>
> This means that, unless you have filled up your TX queue, you can
> defer the TX indication to the device.
I'm not sure how this can be useful to sunvnet- in sunvnet's case
we send the TX indication at the *start* of a burst, so if xmit_more
was set, sure- we can send out another packet immediately, and
avoid another START message (which we already do today), but
nothing else to be gained from xmit_more?
BTW, I have most of the NAPI done, getting it stress-tested etc
(the recent jumbo commit added a few more races between vnet_port_remove
and vnet_start_xmit, thanks to the extra clean_timer) but I figure
I might as well fully test this internally since net-next is closed
for the moment anyway?
>
> For example, in the virtio_net driver the test is:
>
> if (__netif_subqueue_stopped(dev, qnum) || !skb->xmit_more)
> virtqueue_kick(sq->vq);
>
> The pktgen module also has a new "burst" parameter you can use to test
> out this facility directly, and the qdisc layer has heuristics for
> dequeueing multiple packets at a time for normal traffic.
>
> Just FYI...
> --
> 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
* sunvnet and ->xmit_more
From: David Miller @ 2014-10-07 19:18 UTC (permalink / raw)
To: netdev; +Cc: david.stevens, Raghuram.Kothakota, sowmini.varadhan
David and others working on sunvnet, I just wanted to point out that
in the net-next tree there is a new facility that can improve
performance quite a bit in sunvnet.
Basically in the ->ndo_start_xmit() handler, if you see skb->xmit_more
set then the stack is telling you that it guarentees that another
packet will be given to you immediately when ->ndo_start_xmit()
returns.
This means that, unless you have filled up your TX queue, you can
defer the TX indication to the device.
For example, in the virtio_net driver the test is:
if (__netif_subqueue_stopped(dev, qnum) || !skb->xmit_more)
virtqueue_kick(sq->vq);
The pktgen module also has a new "burst" parameter you can use to test
out this facility directly, and the qdisc layer has heuristics for
dequeueing multiple packets at a time for normal traffic.
Just FYI...
^ permalink raw reply
* Re: [PATCH] Update Intel Ethernet Driver maintainers list
From: David Miller @ 2014-10-07 19:13 UTC (permalink / raw)
To: jeffrey.t.kirsher
Cc: alexander.h.duyck, netdev, matthew.vick, alexander.duyck
In-Reply-To: <1412373876.2408.18.camel@jtkirshe-mobl>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Fri, 03 Oct 2014 15:04:36 -0700
> On Fri, 2014-10-03 at 14:45 -0700, Alexander Duyck wrote:
>> I will no longer be working for Intel as of today. As such I am removing
>> myself from the maintainers list and adding my replacement, Matthew Vick
>> as he will be taking over maintenance of the fm10k driver.
>>
>> Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
>
> Acked-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
>
> Dave, no need to wait for a pull request on this one. :-) We will miss
> you Alex.
Applied.
^ permalink raw reply
* Re: bridge: Save frag_max_size between PRE_ROUTING and POST_ROUTING
From: David Miller @ 2014-10-07 19:13 UTC (permalink / raw)
To: herbert; +Cc: fw, netfilter-devel, bsd, stephen, netdev, eric.dumazet, davidn
In-Reply-To: <20141005040022.GA14118@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Sun, 5 Oct 2014 12:00:22 +0800
> bridge: Save frag_max_size between PRE_ROUTING and POST_ROUTING
>
> As we may defragment the packet in IPv4 PRE_ROUTING and refragment
> it after POST_ROUTING we should save the value of frag_max_size.
>
> This is still very wrong as the bridge is supposed to leave the
> packets intact, meaning that the right thing to do is to use the
> original frag_list for fragmentation.
>
> Unfortunately we don't currently guarantee that the frag_list is
> left untouched throughout netfilter so until this changes this is
> the best we can do.
>
> There is also a spot in FORWARD where it appears that we can
> forward a packet without going through fragmentation, mark it
> so that we can fix it later.
>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Applied, thanks Herbert.
^ permalink raw reply
* Re: Quota in __qdisc_run()
From: Eric Dumazet @ 2014-10-07 19:10 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: David Miller, hannes, netdev, therbert, fw, dborkman, jhs,
alexander.duyck, john.r.fastabend, dave.taht, toke
In-Reply-To: <20141007200329.5d20a27e@redhat.com>
On Tue, 2014-10-07 at 20:03 +0200, Jesper Dangaard Brouer wrote:
> According to my measurements, at 10Gbit/s TCP_STREAM test the BQL limit
> is 381528 bytes / 1514 = 252 packets, that will (potentially) be bulk
> dequeued at once (with your version of the patch).
>
That's because you use a single queue maybe ?
In reality, 10Gbe NIC are used in multiqueue mode ...
Here we have limits around 2 TSO packets.
Even with only 4 tx queues I have :
# sar -n DEV 3 3 |grep eth1
12:05:19 PM eth1 147217.67 809066.67 9488.71 1196207.78 0.00 0.00 0.00
12:05:22 PM eth1 145958.00 807822.33 9407.48 1194366.73 0.00 0.00 0.00
12:05:25 PM eth1 147502.33 804739.33 9507.26 1189804.23 0.00 0.00 0.33
Average: eth1 146892.67 807209.44 9467.82 1193459.58 0.00 0.00 0.11
grep . /sys/class/net/eth1/queues/tx*/byte_queue_limits/{inflight,limit}
/sys/class/net/eth1/queues/tx-0/byte_queue_limits/inflight:115064
/sys/class/net/eth1/queues/tx-1/byte_queue_limits/inflight:0
/sys/class/net/eth1/queues/tx-2/byte_queue_limits/inflight:0
/sys/class/net/eth1/queues/tx-3/byte_queue_limits/inflight:0
/sys/class/net/eth1/queues/tx-0/byte_queue_limits/limit:102952
/sys/class/net/eth1/queues/tx-1/byte_queue_limits/limit:124148
/sys/class/net/eth1/queues/tx-2/byte_queue_limits/limit:102952
/sys/class/net/eth1/queues/tx-3/byte_queue_limits/limit:136260
> It seems to have the potential to exceed the weight_p(64) quite a lot.
> And with e.g. TX ring size 512, we also also challenge the drivers at
> this early adoption phase of tailptr writes. Just saying...
>
Yep, but remind we want to squeeze bugs out of the drivers, then add
additional knobs later.
Whatever limit we choose in core networking stack (being 64 packets for
example), hardware might have different constraints that need to be
taken care of in the driver.
^ permalink raw reply
* Re: [PATCH] net: Add ndo_gso_check
From: Tom Herbert @ 2014-10-07 19:10 UTC (permalink / raw)
To: David Miller
Cc: Alexei Starovoitov, Eric Dumazet, Jesse Gross, Or Gerlitz,
Alexander Duyck, John Fastabend, Jeff Kirsher, Linux Netdev List,
Thomas Graf, Pravin B Shelar, Andy Zhou
In-Reply-To: <20141007.145117.1442458821633299880.davem@davemloft.net>
On Tue, Oct 7, 2014 at 11:51 AM, David Miller <davem@davemloft.net> wrote:
>
> From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
> Date: Tue, 7 Oct 2014 11:15:32 -0700
>
> > but if HW has programmable parser it should be able to take advantage
> > of it and UNNECESSARY is an established model.
>
> Strongly disagree.
Another problem with UNNECESSARY is that the stack has no way to
validate what the HW is doing. If HW starts setting UNNECESSARY for
packets with bad checksums, this sort of bug can be really difficult
to detect. With CHECKSUM_COMPLETE it's much harder to have undetected
false positives like this, especially when we need to include pseudo
header in validation. UNNECESSARY really shouldn't be considered
robust for deployment IMO.
^ permalink raw reply
* Re: [PATCH v2 7/7] driver-core: add preferred async probe option for built-in and modules
From: Luis R. Rodriguez @ 2014-10-07 19:07 UTC (permalink / raw)
To: Tejun Heo
Cc: Greg Kroah-Hartman, Dmitry Torokhov, Takashi Iwai,
Arjan van de Ven, Tom Gundersen, Robert Milasan, werner,
Oleg Nesterov, hare, Benjamin Poirier, Santosh Rastapur,
Petr Mladek, dbueso, linux-kernel@vger.kernel.org, Tetsuo Handa,
Joseph Salisbury, Kay Sievers, One Thousand Gnomes, Tim Gardner,
Pierre Fersing, Andrew Morton, Nagalakshmi Nandigama, Praveen
In-Reply-To: <CAB=NE6V_1yyYPhzbV_yRzt7fg=_8yF2YYNBz4qH_2TbH0nozcw@mail.gmail.com>
On Tue, Oct 7, 2014 at 11:55 AM, Luis R. Rodriguez <mcgrof@suse.com> wrote:
> OK I'll just kill bus.enable_kern_async=1 to enable built-in async
> probe support *and* also have prefer_async_probe *always* be
> respected, whether modular or not.
Well and I just realized you *do* want to flush, so will throw that in
too without an option to skip it.
Luis
^ permalink raw reply
* Re: [net-next PATCH v1 1/3] net: sched: af_packet support for direct ring access
From: Neil Horman @ 2014-10-07 18:59 UTC (permalink / raw)
To: Hannes Frederic Sowa
Cc: John Fastabend, Daniel Borkmann, John Fastabend,
Jesper Dangaard Brouer, John W. Linville, Florian Westphal,
gerlitz.or, netdev, john.ronciak, amirv, eric.dumazet, danny.zhou,
Willem de Bruijn
In-Reply-To: <1412637971.706532.175886517.077550BE@webmail.messagingengine.com>
On Tue, Oct 07, 2014 at 01:26:11AM +0200, Hannes Frederic Sowa wrote:
> Hi John,
>
> On Mon, Oct 6, 2014, at 22:37, John Fastabend wrote:
> > > I find the six additional ndo ops a bit worrisome as we are adding more
> > > and more subsystem specific ndoops to this struct. I would like to see
> > > some unification here, but currently cannot make concrete proposals,
> > > sorry.
> >
> > I agree it seems like a bit much. One thought was to split the ndo
> > ops into categories. Switch ops, MACVLAN ops, basic ops and with this
> > userspace queue ops. This sort of goes along with some of the switch
> > offload work which is going to add a handful more ops as best I can
> > tell.
>
> Thanks for your mail, you answered all of my questions.
>
> Have you looked at <https://code.google.com/p/kernel/wiki/ProjectUnetq>?
> Willem (also in Cc) used sysfs files which get mmaped to represent the
> tx/rx descriptors. The representation was independent of the device and
> IIRC the prototype used a write(fd, "", 1) to signal the kernel it
> should proceed with tx. I agree, it would be great to be syscall-free
> here.
>
> For the semantics of the descriptors we could also easily generate files
> in sysfs. I thought about something like tracepoints already do for
> representing the data in the ringbuffer depending on the event:
>
> -- >8 --
> # cat /sys/kernel/debug/tracing/events/net/net_dev_queue/format
> name: net_dev_queue
> ID: 1006
> format:
> field:unsigned short common_type; offset:0; size:2;
> signed:0;
> field:unsigned char common_flags; offset:2; size:1;
> signed:0;
> field:unsigned char common_preempt_count; offset:3;
> size:1; signed:0;
> field:int common_pid; offset:4; size:4; signed:1;
>
> field:void * skbaddr; offset:8; size:8; signed:0;
> field:unsigned int len; offset:16; size:4; signed:0;
> field:__data_loc char[] name; offset:20; size:4;
> signed:1;
>
> print fmt: "dev=%s skbaddr=%p len=%u", __get_str(name), REC->skbaddr,
> REC->len
> -- >8 --
>
> Maybe the macros from tracing are reusable (TP_STRUCT__entry), e.g.
> endianess would need to be added. Hopefully there is already a user
> space parser somewhere in the perf sources. An easier to parse binary
> representation could be added easily and maybe even something vDSO alike
> if people care about that.
>
> Maybe this open/mmap per queue also kills some of the ndo_ops?
>
> Bye,
> Hannes
>
John-
I don't know if its of use to you here, but I was experimenting awhile
ago with af_packet memory mapping, using the protection bits in the page tables
as a doorbell mechanism. I scrapped the work as the performance bottleneck for
af_packet wasn't found in the syscall trap time, but it occurs to me, it might
be useful for you here, in that, using this mechanism, if you keep the transmit
ring non-empty, you only encur the cost of a single trap to start the transmit
process. Let me know if you want to see it.
Neil
^ permalink raw reply
* Re: [PATCH v2 7/7] driver-core: add preferred async probe option for built-in and modules
From: Luis R. Rodriguez @ 2014-10-07 18:55 UTC (permalink / raw)
To: Tejun Heo
Cc: Greg Kroah-Hartman, Dmitry Torokhov, Takashi Iwai,
Arjan van de Ven, Tom Gundersen, Robert Milasan, werner,
Oleg Nesterov, hare, Benjamin Poirier, Santosh Rastapur,
Petr Mladek, dbueso, linux-kernel@vger.kernel.org, Tetsuo Handa,
Joseph Salisbury, Kay Sievers, One Thousand Gnomes, Tim Gardner,
Pierre Fersing, Andrew Morton, Nagalakshmi Nandigama, Praveen
In-Reply-To: <20141007175503.GE31328@mtj.dyndns.org>
On Tue, Oct 7, 2014 at 10:55 AM, Tejun Heo <tj@kernel.org> wrote:
> Hello,
>
> On Tue, Oct 07, 2014 at 07:50:10PM +0200, Luis R. Rodriguez wrote:
>> On Tue, Oct 07, 2014 at 01:34:04PM -0400, Tejun Heo wrote:
>> > But you can create a new workqueue and queue all the async probing
>> > work items there and flush the workqueue right after
>> > async_synchronize_full().
>>
>> On second thought I would prefer to avoid this, I see this being good
>> to help with old userspace but other than that I don't see a requirement
>> for new userspace. Do you?
>
> Hmmm... we batch up and do everything parallel, so I'm not sure how
> much gain we'd be looking at by not waiting for at the end before
> jumping into the userland. Also, it's a bit of an orthogonal issue.
> If we wanna skip such synchornization point before passing control to
> userland, why are we applying that to this but not
> async_synchronize_full() which has a far larger impact? It's weird to
> synchronize one while not the other, so yeah, if there are actual
> benefits we can consider it but let's do it separately.
OK I'll just kill bus.enable_kern_async=1 to enable built-in async
probe support *and* also have prefer_async_probe *always* be
respected, whether modular or not.
Luis
^ permalink raw reply
* Re: [PATCH] net: Add ndo_gso_check
From: David Miller @ 2014-10-07 18:51 UTC (permalink / raw)
To: alexei.starovoitov
Cc: eric.dumazet, therbert, jesse, gerlitz.or, alexander.h.duyck,
john.r.fastabend, jeffrey.t.kirsher, netdev, tgraf, pshelar,
azhou
In-Reply-To: <CAADnVQL_6tEhgQE9aCLe-icG4pyS1dMECGhiQ7+OHEao1GXk3g@mail.gmail.com>
From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Date: Tue, 7 Oct 2014 11:15:32 -0700
> but if HW has programmable parser it should be able to take advantage
> of it and UNNECESSARY is an established model.
Strongly disagree.
^ permalink raw reply
* Re: [PATCH net-next v2 1/1] tipc: fix bug in multicast congestion handling
From: David Miller @ 2014-10-07 18:50 UTC (permalink / raw)
To: jon.maloy
Cc: netdev, paul.gortmaker, erik.hugne, ying.xue, maloy,
tipc-discussion
In-Reply-To: <1412705554-24252-1-git-send-email-jon.maloy@ericsson.com>
From: Jon Maloy <jon.maloy@ericsson.com>
Date: Tue, 7 Oct 2014 14:12:34 -0400
> One aim of commit 50100a5e39461b2a61d6040e73c384766c29975d ("tipc:
> use pseudo message to wake up sockets after link congestion") was
> to handle link congestion abatement in a uniform way for both unicast
> and multicast transmit. However, the latter doesn't work correctly,
> and has been broken since the referenced commit was applied.
>
> If a user now sends a burst of multicast messages that is big
> enough to cause broadcast link congestion, it will be put to sleep,
> and not be waked up when the congestion abates as it should be.
>
> This has two reasons. First, the flag that is used, TIPC_WAKEUP_USERS,
> is set correctly, but in the wrong field. Instead of setting it in the
> 'action_flags' field of the arrival node struct, it is by mistake set
> in the dummy node struct that is owned by the broadcast link, where it
> will never tested for. Second, we cannot use the same flag for waking
> up unicast and multicast users, since the function tipc_node_unlock()
> needs to pick the wakeup pseudo messages to deliver from different
> queues. It must hence be able to distinguish between the two cases.
>
> This commit solves this problem by adding a new flag
> TIPC_WAKEUP_BCAST_USERS, and a new function tipc_bclink_wakeup_user().
> The latter is to be called by tipc_node_unlock() when the named flag,
> now set in the correct field, is encountered.
>
> v2: using explicit 'unsigned int' declaration instead of 'uint', as
> per comment from David Miller.
>
> Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Applied, thanks Jon.
^ permalink raw reply
* Re: [PATCH] net: Add ndo_gso_check
From: Eric Dumazet @ 2014-10-07 18:50 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Tom Herbert, Jesse Gross, Or Gerlitz, Alexander Duyck,
John Fastabend, Jeff Kirsher, David Miller, Linux Netdev List,
Thomas Graf, Pravin Shelar, Andy Zhou
In-Reply-To: <CAADnVQL_6tEhgQE9aCLe-icG4pyS1dMECGhiQ7+OHEao1GXk3g@mail.gmail.com>
On Tue, 2014-10-07 at 11:15 -0700, Alexei Starovoitov wrote:
> csum_partial() is in asm already. probably not much more can be squeezed.
Again this is wrong assumption. Its assembly and damn slow.
Take a look at commit 99f0b958b194f7d88973f1c2190d207e0a2c7e79
for details.
^ permalink raw reply
* Re: macvlan: optimizing the receive path?
From: David Miller @ 2014-10-07 18:49 UTC (permalink / raw)
To: jbaron; +Cc: vyasevich, netdev, kaber
In-Reply-To: <5434246E.1000403@akamai.com>
From: Jason Baron <jbaron@akamai.com>
Date: Tue, 07 Oct 2014 13:35:42 -0400
> So if there are no objections, I will post as a formal patch.
No objections from me, thanks for all the info.
^ permalink raw reply
* Re: [PATCH] net: Add ndo_gso_check
From: David Miller @ 2014-10-07 18:47 UTC (permalink / raw)
To: alexei.starovoitov
Cc: therbert, jesse, gerlitz.or, alexander.h.duyck, john.r.fastabend,
jeffrey.t.kirsher, netdev, tgraf, pshelar, azhou
In-Reply-To: <CAADnVQJUhEmER7C_OOs0dM_mD8REbYT89SG1dfu2b79AUn9eow@mail.gmail.com>
From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Date: Tue, 7 Oct 2014 10:18:25 -0700
> On Tue, Oct 7, 2014 at 10:05 AM, David Miller <davem@davemloft.net> wrote:
>> From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
>> Date: Tue, 7 Oct 2014 09:50:50 -0700
>>
>>> CHECKSUM_COMPLETE is a burden on software.
>>
>> I totally disagree, it's the most software friendly checksumming
>> offload mechanism possible. I wish every card did it.
>>
>> CHECKSUM_COMPLETE means that any sub-protocol or tunneling mechanism
>> can be trivially supported without any modifications to hardware, and
>> it therefore makes checksum offloading of new protocols require no
>> hardware changes whatsoever.
>
> yes, of course. My point is that if HW can parse the packet and validate
> csum it should do that, since it's faster for the stack on top.
> HW can fall back to CHECKSUM_COMPLETE if it fails to parse, for example.
> I think some NICs do exactly that.
I am totally against boolean "yes/no" protocol specific checksum
validation by HW.
It's not faster. You have to look at the pseudo-header and bring it into
the CPU cache _anyways_, so negating it and 2's complementing it into
the CHECKSUM_COMPLETE value for validation is free.
There is no performance advantage whatsoever to use another checksumming
scheme.
^ permalink raw reply
* Re: Quota in __qdisc_run()
From: Jesper Dangaard Brouer @ 2014-10-07 18:37 UTC (permalink / raw)
To: Eric Dumazet
Cc: David Miller, hannes, netdev, therbert, fw, dborkman, jhs,
alexander.duyck, john.r.fastabend, dave.taht, toke, brouer
In-Reply-To: <1412703132.11091.144.camel@edumazet-glaptop2.roam.corp.google.com>
On Tue, 07 Oct 2014 10:32:12 -0700
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Tue, 2014-10-07 at 13:19 -0400, David Miller wrote:
>
> > Yes, this makes sense, do a full qdisc_restart() cycle without boundaries,
> > then check how much quota was used afterwards to guard the outermost loop.
>
> I am testing this, and also am testing the xmit_more patch for I40E.
Check, I'm also testing both yours and Hannes patch.
Results at:
http://people.netfilter.org/hawk/qdisc/measure18_restore_quota_fairness/
http://people.netfilter.org/hawk/qdisc/measure19_restore_quota_erics/
http://people.netfilter.org/hawk/qdisc/measure20_no_quota_baseline_at_git_02c0fc1/
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Sr. Network Kernel Developer at Red Hat
Author of http://www.iptv-analyzer.org
LinkedIn: http://www.linkedin.com/in/brouer
^ 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