* 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
* 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: 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: [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: [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 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: 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
* [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: [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] 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 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
* Re: [PATCH 1/1 net-next] af_unix: remove NULL assignment on static
From: David Miller @ 2014-10-07 20:18 UTC (permalink / raw)
To: fabf; +Cc: linux-kernel, netdev
In-Reply-To: <1412712996-4672-1-git-send-email-fabf@skynet.be>
From: Fabian Frederick <fabf@skynet.be>
Date: Tue, 7 Oct 2014 22:16:36 +0200
> static values are automatically initialized to NULL
>
> Signed-off-by: Fabian Frederick <fabf@skynet.be>
Isn't there some implementation room given to compilers
as to the representation of true and false?
^ permalink raw reply
* [PATCH 1/1 net-next] net: rfkill: kernel-doc warning fixes
From: Fabian Frederick @ 2014-10-07 20:20 UTC (permalink / raw)
To: linux-kernel
Cc: Fabian Frederick, John W. Linville, Johannes Berg,
David S. Miller, linux-wireless, netdev
s/state/blocked
Signed-off-by: Fabian Frederick <fabf@skynet.be>
---
net/rfkill/core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/rfkill/core.c b/net/rfkill/core.c
index b3b16c0..fa7cd79 100644
--- a/net/rfkill/core.c
+++ b/net/rfkill/core.c
@@ -329,7 +329,7 @@ static atomic_t rfkill_input_disabled = ATOMIC_INIT(0);
/**
* __rfkill_switch_all - Toggle state of all switches of given type
* @type: type of interfaces to be affected
- * @state: the new state
+ * @blocked: the new state
*
* This function sets the state of all switches of given type,
* unless a specific switch is claimed by userspace (in which case,
@@ -353,7 +353,7 @@ static void __rfkill_switch_all(const enum rfkill_type type, bool blocked)
/**
* rfkill_switch_all - Toggle state of all switches of given type
* @type: type of interfaces to be affected
- * @state: the new state
+ * @blocked: the new state
*
* Acquires rfkill_global_mutex and calls __rfkill_switch_all(@type, @state).
* Please refer to __rfkill_switch_all() for details.
--
1.9.3
^ permalink raw reply related
* Re: r8168 is needed to enter P-state: Package State 6 (pc6)onHaswell hardware
From: Francois Romieu @ 2014-10-07 20:16 UTC (permalink / raw)
To: Ceriel Jacobs; +Cc: Hayes Wang, nic_swsd, netdev@vger.kernel.org
In-Reply-To: <5433C33B.2060700@crashplan.pro>
Ceriel Jacobs <linux-ide@crashplan.pro> :
> Francois Romieu schreef op 07-10-14 om 00:13:
[...]
> >Realtek's r8168 driver defaults to CONFIG_ASPM=1
>
> # modinfo r8168 suggests the opposite (ASPM is disabled by default):
> version: 8.039.00-NAPI
> parm: aspm:Enable ASPM. (int)
$ grep CONFIG_ASPM src/Makefile
CONFIG_ASPM = y
$ less src/r8168_n.c
[...]
#ifdef CONFIG_ASPM
static int aspm = 1;
#else
static int aspm = 0;
#endif
[...]
> Francois, what do you mean with "current kernel", the latest Ubuntu mainline
> kernel or something different?
Sorry. I meant current mainline as seen from git but anything close like
v3.15.x, v3.16.y or v3.17.k should be fine (patch applies).
--
Ueimor
^ permalink raw reply
* Re: sunvnet and ->xmit_more
From: David L Stevens @ 2014-10-07 20:22 UTC (permalink / raw)
To: David Miller, netdev; +Cc: Raghuram.Kothakota, sowmini.varadhan
In-Reply-To: <20141007.151849.84417269004453869.davem@davemloft.net>
On 10/07/2014 03:18 PM, 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.
Yes, that looks interesting. Thanks!
+-DLS
^ permalink raw reply
* Re: r8168 is needed to enter P-state: Package State 6(pc6)onHaswellhardware
From: Francois Romieu @ 2014-10-07 20:17 UTC (permalink / raw)
To: Hayes Wang; +Cc: Ceriel Jacobs, nic_swsd, netdev@vger.kernel.org
In-Reply-To: <0835B3720019904CB8F7AA43166CEEB2526B88@RTITMBSV03.realtek.com.tw>
Hayes Wang <hayeswang@realtek.com> :
[...]
> When enabling the ASPM, it would influence the thrpughput. It is hard to
> choose performance or power saving. Therefore, we reserve the config
> to let the user determines it.
Mmmm...
How do Realtek's devices behave if Config{2, 3} + MISC registers are
configured for ASPM whereas PCI config space registers aren't ?
--
Ueimor
^ permalink raw reply
* Re: [PATCH 1/1 net-next] af_unix: remove NULL assignment on static
From: Hannes Frederic Sowa @ 2014-10-07 20:26 UTC (permalink / raw)
To: David Miller; +Cc: fabf, linux-kernel, netdev
In-Reply-To: <20141007.161832.453892039501955243.davem@davemloft.net>
On Di, 2014-10-07 at 16:18 -0400, David Miller wrote:
> From: Fabian Frederick <fabf@skynet.be>
> Date: Tue, 7 Oct 2014 22:16:36 +0200
>
> > static values are automatically initialized to NULL
> >
> > Signed-off-by: Fabian Frederick <fabf@skynet.be>
>
> Isn't there some implementation room given to compilers
> as to the representation of true and false?
No, the standard requests implementations to implement false as 0 and
true as 1.
In case of assignments e.g. INT_MAX to _Bool (=bool) it will implicitly
converted to 1, so one can omit the often used !! with booleans.
Bye,
Hannes
^ permalink raw reply
* Re: [PATCH net-next] icmp6: Add new icmpv6 type for RPL control message
From: Hannes Frederic Sowa @ 2014-10-07 20:26 UTC (permalink / raw)
To: David Miller; +Cc: simon.vincent, netdev
In-Reply-To: <20141007.155545.116517484203308074.davem@davemloft.net>
On Di, 2014-10-07 at 15:55 -0400, David Miller wrote:
> 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
Yep, can you take care of this?
Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Thanks! :)
^ permalink raw reply
* Re: [PATCH] net: Add ndo_gso_check
From: Alexei Starovoitov @ 2014-10-07 20:28 UTC (permalink / raw)
To: David Miller
Cc: Tom Herbert, Jesse Gross, gerlitz.or@gmail.com, Alexander Duyck,
John Fastabend, Jeff Kirsher, netdev@vger.kernel.org, Thomas Graf,
Pravin Shelar, Andy Zhou
In-Reply-To: <20141007.144752.657165589422333613.davem@davemloft.net>
On Tue, Oct 7, 2014 at 11:47 AM, David Miller <davem@davemloft.net> wrote:
>
> 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.
ok, forget faster/slower argument for a second.
Why is it a bad thing to have HW verifying checksums?
Tom's argument of difficult bugs in firmware is valid, but there can be bugs
in hw too and in kernel stack...
Also NICs do verify csum already. What are we saying here? Stop doing it?
I can trust only kernel stack to verify csum?
btw, just remembered why COMPLETE is slow in the datacenter...
virtio doesn't have support for it. Packets going into tap without
VIRTIO_NET_HDR_F_DATA_VALID, so guests have to do whole
packet csum.
^ permalink raw reply
* [PATCH net-next] i40e: skb->xmit_more support
From: Eric Dumazet @ 2014-10-07 20:30 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Daniel Borkmann, Jeff Kirsher
From: Eric Dumazet <edumazet@google.com>
Support skb->xmit_more in i40e is straightforward : we need to move
around i40e_maybe_stop_tx() call to correctly test netif_xmit_stopped()
before taking the decision to not kick the NIC.
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
drivers/net/ethernet/intel/i40e/i40e_txrx.c | 90 +++++++++---------
1 file changed, 46 insertions(+), 44 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_txrx.c b/drivers/net/ethernet/intel/i40e/i40e_txrx.c
index 267992b3de8a..3195d82e4942 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_txrx.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_txrx.c
@@ -2053,6 +2053,47 @@ static void i40e_create_tx_ctx(struct i40e_ring *tx_ring,
}
/**
+ * __i40e_maybe_stop_tx - 2nd level check for tx stop conditions
+ * @tx_ring: the ring to be checked
+ * @size: the size buffer we want to assure is available
+ *
+ * Returns -EBUSY if a stop is needed, else 0
+ **/
+static inline int __i40e_maybe_stop_tx(struct i40e_ring *tx_ring, int size)
+{
+ netif_stop_subqueue(tx_ring->netdev, tx_ring->queue_index);
+ /* Memory barrier before checking head and tail */
+ smp_mb();
+
+ /* Check again in a case another CPU has just made room available. */
+ if (likely(I40E_DESC_UNUSED(tx_ring) < size))
+ return -EBUSY;
+
+ /* A reprieve! - use start_queue because it doesn't call schedule */
+ netif_start_subqueue(tx_ring->netdev, tx_ring->queue_index);
+ ++tx_ring->tx_stats.restart_queue;
+ return 0;
+}
+
+/**
+ * i40e_maybe_stop_tx - 1st level check for tx stop conditions
+ * @tx_ring: the ring to be checked
+ * @size: the size buffer we want to assure is available
+ *
+ * Returns 0 if stop is not needed
+ **/
+#ifdef I40E_FCOE
+int i40e_maybe_stop_tx(struct i40e_ring *tx_ring, int size)
+#else
+static int i40e_maybe_stop_tx(struct i40e_ring *tx_ring, int size)
+#endif
+{
+ if (likely(I40E_DESC_UNUSED(tx_ring) >= size))
+ return 0;
+ return __i40e_maybe_stop_tx(tx_ring, size);
+}
+
+/**
* i40e_tx_map - Build the Tx descriptor
* @tx_ring: ring to send buffer on
* @skb: send buffer
@@ -2195,8 +2236,12 @@ static void i40e_tx_map(struct i40e_ring *tx_ring, struct sk_buff *skb,
tx_ring->next_to_use = i;
+ i40e_maybe_stop_tx(tx_ring, DESC_NEEDED);
/* notify HW of packet */
- writel(i, tx_ring->tail);
+ if (!skb->xmit_more ||
+ netif_xmit_stopped(netdev_get_tx_queue(tx_ring->netdev,
+ tx_ring->queue_index)))
+ writel(i, tx_ring->tail);
return;
@@ -2218,47 +2263,6 @@ dma_error:
}
/**
- * __i40e_maybe_stop_tx - 2nd level check for tx stop conditions
- * @tx_ring: the ring to be checked
- * @size: the size buffer we want to assure is available
- *
- * Returns -EBUSY if a stop is needed, else 0
- **/
-static inline int __i40e_maybe_stop_tx(struct i40e_ring *tx_ring, int size)
-{
- netif_stop_subqueue(tx_ring->netdev, tx_ring->queue_index);
- /* Memory barrier before checking head and tail */
- smp_mb();
-
- /* Check again in a case another CPU has just made room available. */
- if (likely(I40E_DESC_UNUSED(tx_ring) < size))
- return -EBUSY;
-
- /* A reprieve! - use start_queue because it doesn't call schedule */
- netif_start_subqueue(tx_ring->netdev, tx_ring->queue_index);
- ++tx_ring->tx_stats.restart_queue;
- return 0;
-}
-
-/**
- * i40e_maybe_stop_tx - 1st level check for tx stop conditions
- * @tx_ring: the ring to be checked
- * @size: the size buffer we want to assure is available
- *
- * Returns 0 if stop is not needed
- **/
-#ifdef I40E_FCOE
-int i40e_maybe_stop_tx(struct i40e_ring *tx_ring, int size)
-#else
-static int i40e_maybe_stop_tx(struct i40e_ring *tx_ring, int size)
-#endif
-{
- if (likely(I40E_DESC_UNUSED(tx_ring) >= size))
- return 0;
- return __i40e_maybe_stop_tx(tx_ring, size);
-}
-
-/**
* i40e_xmit_descriptor_count - calculate number of tx descriptors needed
* @skb: send buffer
* @tx_ring: ring to send buffer on
@@ -2372,8 +2376,6 @@ static netdev_tx_t i40e_xmit_frame_ring(struct sk_buff *skb,
i40e_tx_map(tx_ring, skb, first, tx_flags, hdr_len,
td_cmd, td_offset);
- i40e_maybe_stop_tx(tx_ring, DESC_NEEDED);
-
return NETDEV_TX_OK;
out_drop:
^ permalink raw reply related
* [PATCH 1/1 net-next] netlabel: kernel-doc warning fix
From: Fabian Frederick @ 2014-10-07 20:31 UTC (permalink / raw)
To: linux-kernel; +Cc: Fabian Frederick, Paul Moore, David S. Miller, netdev
no secid argument in netlbl_cfg_unlbl_static_del
Signed-off-by: Fabian Frederick <fabf@skynet.be>
---
net/netlabel/netlabel_kapi.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/net/netlabel/netlabel_kapi.c b/net/netlabel/netlabel_kapi.c
index 0b4692d..a845cd4 100644
--- a/net/netlabel/netlabel_kapi.c
+++ b/net/netlabel/netlabel_kapi.c
@@ -246,7 +246,6 @@ int netlbl_cfg_unlbl_static_add(struct net *net,
* @addr: IP address in network byte order (struct in[6]_addr)
* @mask: address mask in network byte order (struct in[6]_addr)
* @family: address family
- * @secid: LSM secid value for the entry
* @audit_info: NetLabel audit information
*
* Description:
--
1.9.3
^ permalink raw reply related
* Re: [PATCH] net: Add ndo_gso_check
From: David Miller @ 2014-10-07 20:32 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: <CAADnVQKKv43aBFCCaEypAosCf+8K64A2oyYEtxw4jQqY0npV5g@mail.gmail.com>
From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Date: Tue, 7 Oct 2014 13:28:01 -0700
> On Tue, Oct 7, 2014 at 11:47 AM, David Miller <davem@davemloft.net> wrote:
>>
>> 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.
>
> ok, forget faster/slower argument for a second.
> Why is it a bad thing to have HW verifying checksums?
Because you have to change the damn hardware and/or firmware for every
new protocol.
COMPLETE works on _EVERYTHING_ we could ever invent.
^ permalink raw reply
* Re: [PATCH 1/1 net-next] af_unix: remove NULL assignment on static
From: Guenter Roeck @ 2014-10-07 20:33 UTC (permalink / raw)
To: David Miller; +Cc: fabf, linux-kernel, netdev
In-Reply-To: <20141007.161832.453892039501955243.davem@davemloft.net>
On Tue, Oct 07, 2014 at 04:18:32PM -0400, David Miller wrote:
> From: Fabian Frederick <fabf@skynet.be>
> Date: Tue, 7 Oct 2014 22:16:36 +0200
>
> > static values are automatically initialized to NULL
> >
> > Signed-off-by: Fabian Frederick <fabf@skynet.be>
>
> Isn't there some implementation room given to compilers
> as to the representation of true and false?
Not for true/false.
C99 standard, section 7.16:
...
The remaining three macros are suitable for use in #if preprocessing
directives. They are
true
which expands to the integer constant 1,
false
which expands to the integer constant 0, and
...
No idea where the NULL comes into the picture, though.
Guenter
^ permalink raw reply
* Re: [PATCH net-next] icmp6: Add new icmpv6 type for RPL control message
From: David Miller @ 2014-10-07 20:35 UTC (permalink / raw)
To: hannes; +Cc: simon.vincent, netdev
In-Reply-To: <1412713590.11600.5.camel@localhost>
From: Hannes Frederic Sowa <hannes@stressinduktion.org>
Date: Tue, 07 Oct 2014 22:26:30 +0200
> Yep, can you take care of this?
>
> Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Of course, done.
^ permalink raw reply
* Re: [PATCH net-next] i40e: skb->xmit_more support
From: David Miller @ 2014-10-07 20:37 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, dborkman, jeffrey.t.kirsher
In-Reply-To: <1412713823.11091.166.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 07 Oct 2014 13:30:23 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> Support skb->xmit_more in i40e is straightforward : we need to move
> around i40e_maybe_stop_tx() call to correctly test netif_xmit_stopped()
> before taking the decision to not kick the NIC.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Intel folks, if I could get a quick review of this that would be great.
Thanks.
^ 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