* Re: [PATCH net v3] net: ipv6: allow explicitly choosing optimistic addresses
From: Lorenzo Colitti @ 2015-02-04 10:47 UTC (permalink / raw)
To: Erik Kline; +Cc: netdev@vger.kernel.org, Hannes Frederic Sowa
In-Reply-To: <CAAedzxoF2gJit1e05UJSOWX2RJwbA1PSbdABK3zgta-XtajJyw@mail.gmail.com>
On Wed, Feb 4, 2015 at 7:38 PM, Erik Kline <ek@google.com> wrote:
> One more thing I just noticed, though: if the interface and the
> address matches the supplied arguments but we don't like the flags we
> keep on processing all other addresses on that interface I think. Is
> that right? (Easy to fix in a follow on patch.)
What else would the code do? It loops over all the addresses on the
system in hash table order, not interface-by-interface.
^ permalink raw reply
* Re: [PATCH net v3] net: ipv6: allow explicitly choosing optimistic addresses
From: Erik Kline @ 2015-02-04 10:54 UTC (permalink / raw)
To: Lorenzo Colitti; +Cc: netdev@vger.kernel.org, Hannes Frederic Sowa
In-Reply-To: <CAKD1Yr18AvHChpSJau5O2GypDRZ39sGaDfnjV4f73C77gYCXVw@mail.gmail.com>
On Wed, Feb 4, 2015 at 7:47 PM, Lorenzo Colitti <lorenzo@google.com> wrote:
> On Wed, Feb 4, 2015 at 7:38 PM, Erik Kline <ek@google.com> wrote:
>> One more thing I just noticed, though: if the interface and the
>> address matches the supplied arguments but we don't like the flags we
>> keep on processing all other addresses on that interface I think. Is
>> that right? (Easy to fix in a follow on patch.)
>
> What else would the code do? It loops over all the addresses on the
> system in hash table order, not interface-by-interface.
<off_topic>
Well, I was wondering about:
hlist_for_each_entry_rcu(...) {
if (!net_eq(dev_net(ifp->idev->dev), net))
continue;
if (!ipv6_addr_equal(&ifp->addr, addr))
continue;
if (flags_testing && etc) { unlock; return 1; }
else break;
}
But the correctness of this depends on where else an identical IPv6
address might be assigned. Hard for me to say without more dedicated
time to study it.
</off_topic>
^ permalink raw reply
* [PATCH net v4] net: ipv6: allow explicitly choosing optimistic addresses
From: Erik Kline @ 2015-02-04 11:01 UTC (permalink / raw)
To: netdev; +Cc: lorenzo, hannes, Erik Kline
RFC 4429 ("Optimistic DAD") states that optimistic addresses
should be treated as deprecated addresses. From section 2.1:
Unless noted otherwise, components of the IPv6 protocol stack
should treat addresses in the Optimistic state equivalently to
those in the Deprecated state, indicating that the address is
available for use but should not be used if another suitable
address is available.
Optimistic addresses are indeed avoided when other addresses are
available (i.e. at source address selection time), but they have
not heretofore been available for things like explicit bind() and
sendmsg() with struct in6_pktinfo, etc.
This change makes optimistic addresses treated more like
deprecated addresses than tentative ones.
Signed-off-by: Erik Kline <ek@google.com>
---
include/net/addrconf.h | 3 +++
net/ipv6/addrconf.c | 19 +++++++++++++++++--
net/ipv6/ndisc.c | 4 +++-
3 files changed, 23 insertions(+), 3 deletions(-)
diff --git a/include/net/addrconf.h b/include/net/addrconf.h
index d13573b..80456f7 100644
--- a/include/net/addrconf.h
+++ b/include/net/addrconf.h
@@ -62,6 +62,9 @@ int addrconf_set_dstaddr(struct net *net, void __user *arg);
int ipv6_chk_addr(struct net *net, const struct in6_addr *addr,
const struct net_device *dev, int strict);
+int ipv6_chk_addr_and_flags(struct net *net, const struct in6_addr *addr,
+ const struct net_device *dev, int strict,
+ u32 banned_flags);
#if defined(CONFIG_IPV6_MIP6) || defined(CONFIG_IPV6_MIP6_MODULE)
int ipv6_chk_home_addr(struct net *net, const struct in6_addr *addr);
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index f7c8bbe..62900ae 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -1519,15 +1519,30 @@ static int ipv6_count_addresses(struct inet6_dev *idev)
int ipv6_chk_addr(struct net *net, const struct in6_addr *addr,
const struct net_device *dev, int strict)
{
+ return ipv6_chk_addr_and_flags(net, addr, dev, strict, IFA_F_TENTATIVE);
+}
+EXPORT_SYMBOL(ipv6_chk_addr);
+
+int ipv6_chk_addr_and_flags(struct net *net, const struct in6_addr *addr,
+ const struct net_device *dev, int strict,
+ u32 banned_flags)
+{
struct inet6_ifaddr *ifp;
unsigned int hash = inet6_addr_hash(addr);
+ u32 ifp_flags;
rcu_read_lock_bh();
hlist_for_each_entry_rcu(ifp, &inet6_addr_lst[hash], addr_lst) {
if (!net_eq(dev_net(ifp->idev->dev), net))
continue;
+ /* Decouple optimistic from tentative for evaluation here.
+ * Ban optimistic addresses explicitly, when required.
+ */
+ ifp_flags = (ifp->flags&IFA_F_OPTIMISTIC)
+ ? (ifp->flags&~IFA_F_TENTATIVE)
+ : ifp->flags;
if (ipv6_addr_equal(&ifp->addr, addr) &&
- !(ifp->flags&IFA_F_TENTATIVE) &&
+ !(ifp_flags&banned_flags) &&
(dev == NULL || ifp->idev->dev == dev ||
!(ifp->scope&(IFA_LINK|IFA_HOST) || strict))) {
rcu_read_unlock_bh();
@@ -1538,7 +1553,7 @@ int ipv6_chk_addr(struct net *net, const struct in6_addr *addr,
rcu_read_unlock_bh();
return 0;
}
-EXPORT_SYMBOL(ipv6_chk_addr);
+EXPORT_SYMBOL(ipv6_chk_addr_and_flags);
static bool ipv6_chk_same_addr(struct net *net, const struct in6_addr *addr,
struct net_device *dev)
diff --git a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c
index 6828667..113fc6c 100644
--- a/net/ipv6/ndisc.c
+++ b/net/ipv6/ndisc.c
@@ -655,7 +655,9 @@ static void ndisc_solicit(struct neighbour *neigh, struct sk_buff *skb)
struct in6_addr *target = (struct in6_addr *)&neigh->primary_key;
int probes = atomic_read(&neigh->probes);
- if (skb && ipv6_chk_addr(dev_net(dev), &ipv6_hdr(skb)->saddr, dev, 1))
+ if (skb && ipv6_chk_addr_and_flags(dev_net(dev), &ipv6_hdr(skb)->saddr,
+ dev, 1,
+ IFA_F_TENTATIVE|IFA_F_OPTIMISTIC))
saddr = &ipv6_hdr(skb)->saddr;
probes -= NEIGH_VAR(neigh->parms, UCAST_PROBES);
if (probes < 0) {
--
2.2.0.rc0.207.ga3a616c
^ permalink raw reply related
* Re: [PATCH net v3] net: ipv6: allow explicitly choosing optimistic addresses
From: Lorenzo Colitti @ 2015-02-04 11:05 UTC (permalink / raw)
To: Erik Kline; +Cc: netdev@vger.kernel.org, Hannes Frederic Sowa
In-Reply-To: <CAAedzxptQEX+c+khEmO7QvU+58+3W+iuOJ3O9zBfuWbWjFkakw@mail.gmail.com>
On Wed, Feb 4, 2015 at 7:54 PM, Erik Kline <ek@google.com> wrote:
> if (flags_testing && etc) { unlock; return 1; }
> else break;
Oh, I see. I suppose it's possible to fail early if strict == 1, yes.
AIUI it's not possible for the same address to be assigned twice to
the same interface with different prefix lengths (unlike IPv4, which
allows this). But it's possible for the same address to be assigned to
multiple interfaces, so you can't do it if strict == 0.
^ permalink raw reply
* [PATCH net 1/1] qlcnic: Fix NAPI poll routine for Tx completion
From: Shahed Shaikh @ 2015-02-04 10:41 UTC (permalink / raw)
To: davem; +Cc: netdev, Dept-GELinuxNICDev, Shahed Shaikh
From: Shahed Shaikh <shahed.shaikh@qlogic.com>
After d75b1ade567f ("net: less interrupt masking in NAPI")
driver's NAPI poll routine is expected to return
exact budget value if it wants to be re-called.
Signed-off-by: Shahed Shaikh <shahed.shaikh@qlogic.com>
Fixes: d75b1ade567f ("net: less interrupt masking in NAPI")
---
Hi Dave,
Please apply this patch to net
Thanks,
Shahed
---
drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c | 27 +++++++++++++++++++++--
1 files changed, 24 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c
index 18e5de7..4e1f58c 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c
@@ -967,7 +967,12 @@ static int qlcnic_poll(struct napi_struct *napi, int budget)
tx_complete = qlcnic_process_cmd_ring(adapter, tx_ring,
budget);
work_done = qlcnic_process_rcv_ring(sds_ring, budget);
- if ((work_done < budget) && tx_complete) {
+
+ /* Check if we need a repoll */
+ if (!tx_complete)
+ work_done = budget;
+
+ if (work_done < budget) {
napi_complete(&sds_ring->napi);
if (test_bit(__QLCNIC_DEV_UP, &adapter->state)) {
qlcnic_enable_sds_intr(adapter, sds_ring);
@@ -992,6 +997,9 @@ static int qlcnic_tx_poll(struct napi_struct *napi, int budget)
napi_complete(&tx_ring->napi);
if (test_bit(__QLCNIC_DEV_UP, &adapter->state))
qlcnic_enable_tx_intr(adapter, tx_ring);
+ } else {
+ /* As qlcnic_process_cmd_ring() returned 0, we need a repoll*/
+ work_done = budget;
}
return work_done;
@@ -1950,7 +1958,12 @@ static int qlcnic_83xx_msix_sriov_vf_poll(struct napi_struct *napi, int budget)
tx_complete = qlcnic_process_cmd_ring(adapter, tx_ring, budget);
work_done = qlcnic_83xx_process_rcv_ring(sds_ring, budget);
- if ((work_done < budget) && tx_complete) {
+
+ /* Check if we need a repoll */
+ if (!tx_complete)
+ work_done = budget;
+
+ if (work_done < budget) {
napi_complete(&sds_ring->napi);
qlcnic_enable_sds_intr(adapter, sds_ring);
}
@@ -1973,7 +1986,12 @@ static int qlcnic_83xx_poll(struct napi_struct *napi, int budget)
tx_complete = qlcnic_process_cmd_ring(adapter, tx_ring, budget);
work_done = qlcnic_83xx_process_rcv_ring(sds_ring, budget);
- if ((work_done < budget) && tx_complete) {
+
+ /* Check if we need a repoll */
+ if (!tx_complete)
+ work_done = budget;
+
+ if (work_done < budget) {
napi_complete(&sds_ring->napi);
qlcnic_enable_sds_intr(adapter, sds_ring);
}
@@ -1995,6 +2013,9 @@ static int qlcnic_83xx_msix_tx_poll(struct napi_struct *napi, int budget)
napi_complete(&tx_ring->napi);
if (test_bit(__QLCNIC_DEV_UP , &adapter->state))
qlcnic_enable_tx_intr(adapter, tx_ring);
+ } else {
+ /* need a repoll */
+ work_done = budget;
}
return work_done;
--
1.7.1
^ permalink raw reply related
* Re: Throughput regression with `tcp: refine TSO autosizing`
From: Michal Kazior @ 2015-02-04 11:35 UTC (permalink / raw)
To: Eric Dumazet; +Cc: linux-wireless, Network Development, eyalpe
In-Reply-To: <1422973660.907.10.camel@edumazet-glaptop2.roam.corp.google.com>
On 3 February 2015 at 15:27, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Tue, 2015-02-03 at 12:50 +0100, Michal Kazior wrote:
[...]
>> IOW:
>> - stretch acks / TSO defer don't seem to help much (when compared to
>> throughput results from yesterday)
>> - GRO helps
>> - disabling A-MSDU on sender helps
>> - net/master+GRO still doesn't reach the performance from before the
>> regression (~600mbps w/ GRO)
>>
>> You can grab logs and dumps here: http://www.filedropper.com/test2tar
>>
>
> Thanks for these traces.
>
> There is absolutely a problem at the sender, as we can see a big 2ms
> delay between reception of ACK and send of following packets.
> TCP stack should generate them immediately.
> Are you using some kind of netem qdisc ?
Both systems have identical setup:
; tc qdisc
qdisc pfifo_fast 0: dev eth0 root refcnt 2 bands 3 priomap 1 2 2 2 1
2 0 0 1 1 1 1 1 1 1 1
qdisc pfifo_fast 0: dev eth1 root refcnt 2 bands 3 priomap 1 2 2 2 1
2 0 0 1 1 1 1 1 1 1 1
qdisc mq 0: dev wlan1 root
qdisc pfifo_fast 0: dev wlan1 parent :1 bands 3 priomap 1 2 2 2 1 2 0
0 1 1 1 1 1 1 1 1
qdisc pfifo_fast 0: dev wlan1 parent :2 bands 3 priomap 1 2 2 2 1 2 0
0 1 1 1 1 1 1 1 1
qdisc pfifo_fast 0: dev wlan1 parent :3 bands 3 priomap 1 2 2 2 1 2 0
0 1 1 1 1 1 1 1 1
qdisc pfifo_fast 0: dev wlan1 parent :4 bands 3 priomap 1 2 2 2 1 2 0
0 1 1 1 1 1 1 1 1
> These 2ms delays, in a flow with a 5ms RTT are terrible.
>
> 06:54:57.408391 IP 192.168.1.2.5001 > 192.168.1.3.51645: Flags [.], ack 4294899240, win 11268, options [nop,nop,TS val 1053302 ecr 1052250], length 0
> 06:54:57.408418 IP 192.168.1.2.5001 > 192.168.1.3.51645: Flags [.], ack 4294910824, win 11268, options [nop,nop,TS val 1053303 ecr 1052251], length 0
> 06:54:57.408431 IP 192.168.1.2.5001 > 192.168.1.3.51645: Flags [.], ack 4294936888, win 11268, options [nop,nop,TS val 1053303 ecr 1052251], length 0
> 06:54:57.408453 IP 192.168.1.2.5001 > 192.168.1.3.51645: Flags [.], ack 4294962952, win 11268, options [nop,nop,TS val 1053303 ecr 1052251], length 0
> 06:54:57.408474 IP 192.168.1.2.5001 > 192.168.1.3.51645: Flags [.], ack 0, win 11268, options [nop,nop,TS val 1053303 ecr 1052251], length 0
> <this 2ms delay is not generated by TCP stack.>
> 06:54:57.410243 IP 192.168.1.3.51645 > 192.168.1.2.5001: Flags [.], seq 82536:83984, ack 1, win 457, options [nop,nop,TS val 1052256 ecr 1053303], length 1448
[...]
>
> Are packets TX completed after a timer or something ?
As far as ath10k is concerned - no timers here. Not sure about
firmware itself though.
> Some very heavy stuff might run from tasklet (or other softirq triggered) event.
>
> BTW, traces tend to show that you 'receive' multiple ACK in the same burst,
> its not clear if they are delayed at one side or the other.
>
> GRO should delay only GRO candidates. ACK packets are not GRO candidates.
>
> Have you tried to disable GSO on sender ?
I assume I do that via ethtool? This is my current setup on both systems:
; ethtool -k wlan1
Features for wlan1:
rx-checksumming: off [fixed]
tx-checksumming: on
tx-checksum-ipv4: off [fixed]
tx-checksum-ip-generic: on [fixed]
tx-checksum-ipv6: off [fixed]
tx-checksum-fcoe-crc: off [fixed]
tx-checksum-sctp: off [fixed]
scatter-gather: off
tx-scatter-gather: off [fixed]
tx-scatter-gather-fraglist: off [fixed]
tcp-segmentation-offload: off
tx-tcp-segmentation: off [fixed]
tx-tcp-ecn-segmentation: off [fixed]
tx-tcp6-segmentation: off [fixed]
udp-fragmentation-offload: off [fixed]
generic-segmentation-offload: off [requested on]
generic-receive-offload: on
large-receive-offload: off [fixed]
rx-vlan-offload: off [fixed]
tx-vlan-offload: off [fixed]
ntuple-filters: off [fixed]
receive-hashing: off [fixed]
highdma: off [fixed]
rx-vlan-filter: off [fixed]
vlan-challenged: off [fixed]
tx-lockless: off [fixed]
netns-local: on [fixed]
tx-gso-robust: off [fixed]
tx-fcoe-segmentation: off [fixed]
tx-gre-segmentation: off [fixed]
tx-ipip-segmentation: off [fixed]
tx-sit-segmentation: off [fixed]
tx-udp_tnl-segmentation: off [fixed]
fcoe-mtu: off [fixed]
tx-nocache-copy: off
loopback: off [fixed]
rx-fcs: off [fixed]
rx-all: off [fixed]
tx-vlan-stag-hw-insert: off [fixed]
rx-vlan-stag-hw-parse: off [fixed]
rx-vlan-stag-filter: off [fixed]
l2-fwd-offload: off [fixed]
busy-poll: off [fixed]
; ethtool -K wlan1 generic-segmentation-offload off
ethtool: bad command line argument(s)
For more information run ethtool -h
> (Or maybe wifi drivers should start to use skb->xmit_more as a signal to end aggregation)
This could work if your firmware/device supports this kind of thing.
To my understanding ath10k firmware doesn't.
Michał
^ permalink raw reply
* [PATCH] myri10ge: Delete an unnecessary check before the function call "kfree"
From: SF Markus Elfring @ 2015-02-04 11:36 UTC (permalink / raw)
To: Hyong-Youb Kim, netdev; +Cc: LKML, kernel-janitors, Julia Lawall
In-Reply-To: <5317A59D.4@users.sourceforge.net>
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Wed, 4 Feb 2015 12:32:14 +0100
The kfree() function tests whether its argument is NULL and then
returns immediately. Thus the test around the call is not needed.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
drivers/net/ethernet/myricom/myri10ge/myri10ge.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/myricom/myri10ge/myri10ge.c b/drivers/net/ethernet/myricom/myri10ge/myri10ge.c
index 71af98b..1412f5a 100644
--- a/drivers/net/ethernet/myricom/myri10ge/myri10ge.c
+++ b/drivers/net/ethernet/myricom/myri10ge/myri10ge.c
@@ -4226,8 +4226,7 @@ static void myri10ge_remove(struct pci_dev *pdev)
mtrr_del(mgp->mtrr, mgp->iomem_base, mgp->board_span);
#endif
myri10ge_free_slices(mgp);
- if (mgp->msix_vectors != NULL)
- kfree(mgp->msix_vectors);
+ kfree(mgp->msix_vectors);
dma_free_coherent(&pdev->dev, sizeof(*mgp->cmd),
mgp->cmd, mgp->cmd_bus);
--
2.2.2
^ permalink raw reply related
* [PATCH net-next] i40e: mark constant as ULL
From: Stefan Assmann @ 2015-02-04 11:41 UTC (permalink / raw)
To: netdev; +Cc: davem, e1000-devel, jeffrey.t.kirsher, sassmann
This avoids a compile error on 32bit.
Signed-off-by: Stefan Assmann <sassmann@kpanic.de>
---
drivers/net/ethernet/intel/i40e/i40e_lan_hmc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_lan_hmc.c b/drivers/net/ethernet/intel/i40e/i40e_lan_hmc.c
index 4627588..f221ace 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_lan_hmc.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_lan_hmc.c
@@ -908,7 +908,7 @@ static void i40e_write_qword(u8 *hmc_bits,
if (ce_info->width < 64)
mask = ((u64)1 << ce_info->width) - 1;
else
- mask = 0xFFFFFFFFFFFFFFFF;
+ mask = 0xFFFFFFFFFFFFFFFFULL;
/* don't swizzle the bits until after the mask because the mask bits
* will be in a different bit position on big endian machines
--
2.1.0
^ permalink raw reply related
* Re: [PATCH net v4] net: ipv6: allow explicitly choosing optimistic addresses
From: Lorenzo Colitti @ 2015-02-04 11:53 UTC (permalink / raw)
To: Erik Kline; +Cc: netdev@vger.kernel.org, Hannes Frederic Sowa
In-Reply-To: <1423047683-16267-1-git-send-email-ek@google.com>
On Wed, Feb 4, 2015 at 8:01 PM, Erik Kline <ek@google.com> wrote:
> + /* Decouple optimistic from tentative for evaluation here.
> + * Ban optimistic addresses explicitly, when required.
> + */
I don't find this comment particularly useful, but I suppose there's
no harm in having it.
> + ifp_flags = (ifp->flags&IFA_F_OPTIMISTIC)
> + ? (ifp->flags&~IFA_F_TENTATIVE)
> + : ifp->flags;
> if (ipv6_addr_equal(&ifp->addr, addr) &&
> - !(ifp->flags&IFA_F_TENTATIVE) &&
> + !(ifp_flags&banned_flags) &&
> (dev == NULL || ifp->idev->dev == dev ||
That looks correct now. It's also nicer than what I had proposed.
Adding the new ipv6_chk_addr_and_flags function is definitely less
churn than the alternative of updating all the callers of
ipv6_chk_addr (19 files) to pass in the extra argument. Not sure which
is preferred, the churn or the new function.
Acked-by: Lorenzo Colitti <lorenzo@google.com>
^ permalink raw reply
* Re: [PATCH v3 2/3] genetlink: disallow subscribing to unknown mcast groups
From: Bjørn Mork @ 2015-02-04 11:55 UTC (permalink / raw)
To: Johannes Berg; +Cc: netdev, Jeff Layton, Sedat Dilek, Johannes Berg
In-Reply-To: <1421404634-8973-2-git-send-email-johannes@sipsolutions.net>
Johannes Berg <johannes@sipsolutions.net> writes:
> diff --git a/net/netlink/genetlink.c b/net/netlink/genetlink.c
> index 2e11061ef885..c18d3f5624b2 100644
> --- a/net/netlink/genetlink.c
> +++ b/net/netlink/genetlink.c
> @@ -985,7 +985,7 @@ static struct genl_multicast_group genl_ctrl_groups[] = {
>
> static int genl_bind(struct net *net, int group)
> {
> - int i, err = 0;
> + int i, err = -ENOENT;
>
> down_read(&cb_lock);
> for (i = 0; i < GENL_FAM_TAB_SIZE; i++) {
This change cause serious problems for acpid, as reported on
https://bugzilla.kernel.org/show_bug.cgi?id=92121
The end user visible result is that acpid fails to detect events like AC
power disconnect, battery alarms etc, which can be a bit of a problem if
you trust a battery alarm to trigger an emergency hibernation. As I
happen to do...
Given the timing, I request that this patch is reverted for v3.19.
Thanks.
Sample acpid debug output, tracing the socket calls, running on a plain
v3.19-rc7:
nemi:/tmp# strace -s 128 -e trace=socket,bind,sendmsg,recvmsg -f acpid -l -d
socket(PF_LOCAL, SOCK_DGRAM|SOCK_CLOEXEC, 0) = 3
Deprecated /proc/acpi/event was not found. Trying netlink and the input layer...
input layer /dev/input/event0 (AT Translated Set 2 keyboard) opened successfully, fd 4
input layer /dev/input/event1 (Lid Switch) opened successfully, fd 5
input layer /dev/input/event10 (HDA Intel Dock Headphone) opened successfully, fd 6
input layer /dev/input/event11 (HDA Intel Headphone) opened successfully, fd 7
input layer /dev/input/event2 (Sleep Button) opened successfully, fd 8
input layer /dev/input/event3 (Power Button) opened successfully, fd 9
input layer /dev/input/event4 (ThinkPad Extra Buttons) opened successfully, fd 10
input layer /dev/input/event6 (Video Bus) opened successfully, fd 11
input layer /dev/input/event8 (HDA Intel Mic) opened successfully, fd 12
input layer /dev/input/event9 (HDA Intel Dock Mic) opened successfully, fd 13
inotify fd: 14
inotify wd: 1
socket(PF_NETLINK, SOCK_RAW|SOCK_CLOEXEC, NETLINK_GENERIC) = 15
bind(15, {sa_family=AF_NETLINK, pid=0, groups=00000000}, 12) = 0
sendmsg(15, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"$\0\0\0\20\0\5\0\21\10\322T\0\0\0\0\3\0\0\0\17\0\2\0acpi_event\0\0", 36}], msg_controllen=0, msg_flags=0}, 0) = 36
recvmsg(15, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"h\0\0\0\20\0\0\0\21\10\322T\314l\0\0\1\2\0\0\17\0\2\0acpi_event\0\0\6\0\1\0\23\0\0\0\10\0\3\0\1\0\0\0\10\0\4\0\0\0\0\0\10\0\5\0\1\0\0\0$\0\7\0 \0\1\0\10\0\2\0\2\0\0\0\22\0\1\0acpi_mc_group\0\0\0", 16384}], msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_CMSG_CLOEXEC) = 104
socket(PF_NETLINK, SOCK_RAW|SOCK_CLOEXEC, NETLINK_GENERIC) = 15
bind(15, {sa_family=AF_NETLINK, pid=0, groups=00000002}, 12) = -1 ENOENT (No such file or directory)
Cannot bind netlink socket: No such file or directory
acpid: cannot open generic netlink socket
socket(PF_LOCAL, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 16
bind(16, {sa_family=AF_LOCAL, sun_path="/var/run/acpid.socket"}, 110) = 0
acpid: starting up with netlink and the input layer
parsing conf file /etc/acpi/events/powerbtn-acpi-support
acpid: skipping non-file /etc/acpi/events/CVS
parsing conf file /etc/acpi/events/any
parsing conf file /etc/acpi/events/generic-hibernatebtn
parsing conf file /etc/acpi/events/low_battery
parsing conf file /etc/acpi/events/lidbtn
parsing conf file /etc/acpi/events/sleepbtn
acpid: 6 rules loaded
acpid: waiting for events: event logging is on
Bjørn
^ permalink raw reply
* Re: Throughput regression with `tcp: refine TSO autosizing`
From: Eric Dumazet @ 2015-02-04 11:57 UTC (permalink / raw)
To: Michal Kazior
Cc: linux-wireless, Network Development,
eyalpe-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb
In-Reply-To: <CA+BoTQmvUuFdfYF=wVMYxrf_nQZB5GCV=LvDZVvfs-3hAE4WKw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Wed, 2015-02-04 at 12:35 +0100, Michal Kazior wrote:
> > (Or maybe wifi drivers should start to use skb->xmit_more as a signal to end aggregation)
>
> This could work if your firmware/device supports this kind of thing.
> To my understanding ath10k firmware doesn't.
This is a pure software signal. You do not need firmware support.
Idea is the following :
Your driver gets a train of messages, coming from upper layers (TCP, IP,
qdisc)
It can know that a packet is not the last one, by looking at
skb->xmit_more.
Basically, aggregation logic could use this signal as a very clear
indicator you got the end of a train -> force the xmit right now.
To disable gso you would have to use :
ethtool -K wlan1 gso off
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: [PATCH v2] net: bluetooth: hci_sock: Use 'const void *' instead of 'void *' for 2nd parameter of hci_test_bit()
From: David Laight @ 2015-02-04 11:59 UTC (permalink / raw)
To: 'Chen Gang S', marcel@holtmann.org, gustavo@padovan.org,
johan.hedberg@gmail.com
Cc: David S. Miller, linux-bluetooth@vger.kernel.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <54CFE8BE.5030700@sunrus.com.cn>
From: Chen Gang S
> -static inline int hci_test_bit(int nr, void *addr)
> +static inline int hci_test_bit(int nr, const void *addr)
> {
> return *((__u32 *) addr + (nr >> 5)) & ((__u32) 1 << (nr & 31));
> }
Is there a 'standard' function lurking that will do the above.
On x86 the cpus 'bit test' instruction will handle bit numbers
greater than the word size - so it can be a single instruction.
David
^ permalink raw reply
* Re: [PATCH net-next] i40e: mark constant as ULL
From: Jeff Kirsher @ 2015-02-04 11:59 UTC (permalink / raw)
To: Stefan Assmann; +Cc: netdev, davem, e1000-devel
In-Reply-To: <1423050064-25087-1-git-send-email-sassmann@kpanic.de>
[-- Attachment #1: Type: text/plain, Size: 325 bytes --]
On Wed, 2015-02-04 at 12:41 +0100, Stefan Assmann wrote:
> This avoids a compile error on 32bit.
>
> Signed-off-by: Stefan Assmann <sassmann@kpanic.de>
> ---
> drivers/net/ethernet/intel/i40e/i40e_lan_hmc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Thanks Stefan, I will add your patch to my queue.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* [PATCH] net: fec: Delete unnecessary checks before the function call "kfree"
From: SF Markus Elfring @ 2015-02-04 12:00 UTC (permalink / raw)
To: netdev; +Cc: LKML, kernel-janitors, Julia Lawall
In-Reply-To: <5317A59D.4@users.sourceforge.net>
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Wed, 4 Feb 2015 12:56:42 +0100
The kfree() function tests whether its argument is NULL and then
returns immediately. Thus the test around the call is not needed.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
drivers/net/ethernet/freescale/fec_main.c | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
index 1c7a7e4..29fd7e3 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -2584,12 +2584,9 @@ static void fec_enet_free_queue(struct net_device *ndev)
}
for (i = 0; i < fep->num_rx_queues; i++)
- if (fep->rx_queue[i])
- kfree(fep->rx_queue[i]);
-
+ kfree(fep->rx_queue[i]);
for (i = 0; i < fep->num_tx_queues; i++)
- if (fep->tx_queue[i])
- kfree(fep->tx_queue[i]);
+ kfree(fep->tx_queue[i]);
}
static int fec_enet_alloc_queue(struct net_device *ndev)
--
2.2.2
^ permalink raw reply related
* RE: [PATCH v2] net: bluetooth: hci_sock: Use 'const void *' instead of 'void *' for 2nd parameter of hci_test_bit()
From: David Laight @ 2015-02-04 12:13 UTC (permalink / raw)
To: 'Chen Gang S', Joe Perches
Cc: marcel-kz+m5ild9QBg9hUCZPvPmw@public.gmane.org,
gustavo-THi1TnShQwVAfugRpC6u6w@public.gmane.org,
johan.hedberg-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
David S. Miller,
linux-bluetooth-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <54D03996.1070503-/B7AUNIrSHOPt1CcHtbs0g@public.gmane.org>
From: Gang S
> On 2/3/15 10:32, Chen Gang S wrote:
> > On 2/3/15 05:20, Joe Perches wrote:
> >> On Tue, 2015-02-03 at 05:14 +0800, Chen Gang S wrote:
> >>> hci_test_bit() does not modify 2nd parameter, so it is better to let it
> >>> be constant, or may cause build warning. The related warning (with
> >>> allmodconfig under xtensa):
> >> []
> >>> diff --git a/net/bluetooth/hci_sock.c b/net/bluetooth/hci_sock.c
> >> []
> >>> @@ -46,7 +46,7 @@ struct hci_pinfo {
> >>> unsigned short channel;
> >>> };
> >>>
> >>> -static inline int hci_test_bit(int nr, void *addr)
> >>> +static inline int hci_test_bit(int nr, const void *addr)
> >>> {
> >>> return *((__u32 *) addr + (nr >> 5)) & ((__u32) 1 << (nr & 31));
> >>> }
> >>
> >> It's probably better to use const __u32 * here too, but the
> >> real thing I wonder is whether or not there's an issue with
> >> one of the 2 uses of this function.
> >>
> >> One of them passes a unsigned long *, the other a u32 *.
> >>
> >> $ git grep -w hci_test_bit
> >> net/bluetooth/hci_sock.c:static inline int hci_test_bit(int nr, void *addr)
> >> net/bluetooth/hci_sock.c: if (!hci_test_bit(flt_event, &flt->event_mask))
> >> net/bluetooth/hci_sock.c: !hci_test_bit(ocf & HCI_FLT_OCF_BITS,
> >> net/bluetooth/hci_sock.c- &hci_sec_filter.ocf_mask[ogf])) &&
> >>
> >> hci_sec_filter.ocf_mask is __u32
> >> but flt->event_mask is unsigned long.
> >>
> >> Any possible issue here on 64-bit systems?
> >>
> >
> > For me, it can not cause issue on 64-bit systems. hci_test_bit() treats
> > 'addr' as "__u32 *", and has to use the pointer to do something.
> >
>
> 'event_mask' is intended to type cast to "__u32 *" within 'hci_sock.c'.
> So for me, "const __u32 *" is better than "const void *" for 2nd
> parameter of hci_test_bit().
>
> If what I said above is correct, and also if necessary, I shall patch v3
> for it.
How are the bits set in the first place?
If the array is ever indexed as long [] then the code above is unlikely
to be testing the correct bits.
David
^ permalink raw reply
* Re: Invalid timestamp? causing tight ack loop (hundreds of thousands of packets / sec)
From: Eric Dumazet @ 2015-02-04 12:20 UTC (permalink / raw)
To: Avery Fay; +Cc: netdev, Neal Cardwell
In-Reply-To: <CAO-X30shOhH7tN+msRvbLreeUvZesKARqyU0Lnm3_xoeea9uaQ@mail.gmail.com>
On Wed, 2015-02-04 at 00:35 -0800, Avery Fay wrote:
> Sure, https://dl.dropboxusercontent.com/u/9777748/loop.pcap.gz
Nice, something is really broken on this peer (not a linux one for
sure), or some really buggy middlebox.
The strange [P.] frame with no payload has a wrong sequence number
anyway, so we send back a duplicate ack.
1 0.000000 128.61.57.205 -> 174.36.240.86 TCP 74 34574 > https [SYN] Seq=0 Win=65535 Len=0 MSS=1380 SACK_PERM=1 TSval=3985707 TSecr=0 WS=256
2 0.000008 174.36.240.86 -> 128.61.57.205 TCP 74 https > 34574 [SYN, ACK] Seq=0 Ack=1 Win=28960 Len=0 MSS=1460 SACK_PERM=1 TSval=3311875276 TSecr=3985707 WS=128
3 0.019057 128.61.57.205 -> 174.36.240.86 TCP 66 34574 > https [ACK] Seq=1 Ack=1 Win=87808 Len=0 TSval=3985710 TSecr=3311875276
4 0.019111 128.61.57.205 -> 174.36.240.86 TCP 66 [TCP Dup ACK 3#1] 34574 > https [ACK] Seq=1 Ack=1 Win=87808 Len=0 TSval=3985710 TSecr=3311875276
5 0.037637 128.61.57.205 -> 174.36.240.86 SSL 292 Client Hello
6 0.037644 174.36.240.86 -> 128.61.57.205 TCP 66 https > 34574 [ACK] Seq=1 Ack=227 Win=30080 Len=0 TSval=3311875285 TSecr=3985712
7 0.037699 174.36.240.86 -> 128.61.57.205 TLSv1.2 2802 Server Hello
8 0.037706 174.36.240.86 -> 128.61.57.205 TLSv1.2 585 Certificate
9 0.074710 174.36.240.86 -> 128.61.57.205 TCP 585 [TCP Retransmission] https > 34574 [PSH, ACK] Seq=2737 Ack=227 Win=30080 Len=519 TSval=3311875295 TSecr=3985712[Reassembly error, protocol TCP: New fragment overlaps ol
d data (retransmission?)]
10 0.294707 174.36.240.86 -> 128.61.57.205 TLSv1.2 1434 [TCP Retransmission] Server Hello
11 0.734711 174.36.240.86 -> 128.61.57.205 TLSv1.2 1434 [TCP Retransmission] Server Hello
12 1.614707 174.36.240.86 -> 128.61.57.205 TLSv1.2 1434 [TCP Retransmission] Server Hello
13 3.378705 174.36.240.86 -> 128.61.57.205 TLSv1.2 1434 [TCP Retransmission] Server Hello
14 6.910707 174.36.240.86 -> 128.61.57.205 TLSv1.2 1434 [TCP Retransmission] Server Hello
15 10.097427 128.61.57.205 -> 174.36.240.86 TCP 66 34574 > https [FIN, ACK] Seq=227 Ack=1 Win=87808 Len=0 TSval=3986717 TSecr=3311875285
16 10.097456 174.36.240.86 -> 128.61.57.205 TCP 66 https > 34574 [FIN, ACK] Seq=3256 Ack=228 Win=30080 Len=0 TSval=3311877800 TSecr=3986717
17 10.111945 128.61.57.205 -> 174.36.240.86 TCP 78 [TCP Dup ACK 15#1] 34574 > https [PSH, ACK] Seq=228 Ack=1 Win=87808 Len=0 TSval=3985712 TSecr=3311875276 SLE=3256 SRE=3256
18 10.111950 174.36.240.86 -> 128.61.57.205 TCP 66 [TCP Dup ACK 16#1] https > 34574 [ACK] Seq=3257 Ack=228 Win=30080 Len=0 TSval=3311877804 TSecr=3986717
19 10.111952 128.61.57.205 -> 174.36.240.86 TCP 66 [TCP Dup ACK 15#2] 34574 > https [PSH, ACK] Seq=228 Ack=1 Win=87808 Len=0 TSval=3985712 TSecr=3311875276
20 10.111955 174.36.240.86 -> 128.61.57.205 TCP 66 [TCP Dup ACK 16#2] https > 34574 [ACK] Seq=3257 Ack=228 Win=30080 Len=0 TSval=3311877804 TSecr=3986717
21 10.126312 128.61.57.205 -> 174.36.240.86 TCP 86 [TCP Dup ACK 15#3] 34574 > https [PSH, ACK] Seq=228 Ack=1 Win=87808 Len=0 TSval=3985712 TSecr=3311875276 SLE=3257 SRE=3257 SLE=3256 SRE=3256
22 10.126317 174.36.240.86 -> 128.61.57.205 TCP 66 [TCP Dup ACK 16#3] https > 34574 [ACK] Seq=3257 Ack=228 Win=30080 Len=0 TSval=3311877807 TSecr=3986717
23 10.126360 128.61.57.205 -> 174.36.240.86 TCP 66 [TCP Dup ACK 15#4] 34574 > https [PSH, ACK] Seq=228 Ack=1 Win=87808 Len=0 TSval=3985712 TSecr=3311875276
24 10.126362 174.36.240.86 -> 128.61.57.205 TCP 66 [TCP Dup ACK 16#4] https > 34574 [ACK] Seq=3257 Ack=228 Win=30080 Len=0 TSval=3311877807 TSecr=3986717
25 10.126364 128.61.57.205 -> 174.36.240.86 TCP 66 [TCP Dup ACK 15#5] 34574 > https [PSH, ACK] Seq=228 Ack=1 Win=87808 Len=0 TSval=3985712 TSecr=3311875276
26 10.126365 174.36.240.86 -> 128.61.57.205 TCP 66 [TCP Dup ACK 16#5] https > 34574 [ACK] Seq=3257 Ack=228 Win=30080 Len=0 TSval=3311877807 TSecr=3986717
27 10.126366 128.61.57.205 -> 174.36.240.86 TCP 66 [TCP Dup ACK 15#6] 34574 > https [PSH, ACK] Seq=228 Ack=1 Win=87808 Len=0 TSval=3985712 TSecr=3311875276
28 10.126367 174.36.240.86 -> 128.61.57.205 TCP 66 [TCP Dup ACK 16#6] https > 34574 [ACK] Seq=3257 Ack=228 Win=30080 Len=0 TSval=3311877807 TSecr=3986717
29 10.140709 128.61.57.205 -> 174.36.240.86 TCP 66 [TCP Dup ACK 15#7] 34574 > https [PSH, ACK] Seq=228 Ack=1 Win=87808 Len=0 TSval=3985712 TSecr=3311875276
30 10.140714 174.36.240.86 -> 128.61.57.205 TCP 66 [TCP Dup ACK 16#7] https > 34574 [ACK] Seq=3257 Ack=228 Win=30080 Len=0 TSval=3311877811 TSecr=3986717
Neal patches definitely would solve this issue.
^ permalink raw reply
* [PATCH] netxen: Delete an unnecessary check before the function call "kfree"
From: SF Markus Elfring @ 2015-02-04 12:21 UTC (permalink / raw)
To: Manish Chopra, Rajesh Borundia, Sony Chacko, netdev
Cc: LKML, kernel-janitors, Julia Lawall
In-Reply-To: <5317A59D.4@users.sourceforge.net>
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Wed, 4 Feb 2015 13:17:48 +0100
The kfree() function tests whether its argument is NULL and then
returns immediately. Thus the test around the call is not needed.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
drivers/net/ethernet/qlogic/netxen/netxen_nic_main.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/netxen/netxen_nic_main.c b/drivers/net/ethernet/qlogic/netxen/netxen_nic_main.c
index a47fe67..7d1b524 100644
--- a/drivers/net/ethernet/qlogic/netxen/netxen_nic_main.c
+++ b/drivers/net/ethernet/qlogic/netxen/netxen_nic_main.c
@@ -176,9 +176,7 @@ netxen_alloc_sds_rings(struct netxen_recv_context *recv_ctx, int count)
static void
netxen_free_sds_rings(struct netxen_recv_context *recv_ctx)
{
- if (recv_ctx->sds_rings != NULL)
- kfree(recv_ctx->sds_rings);
-
+ kfree(recv_ctx->sds_rings);
recv_ctx->sds_rings = NULL;
}
--
2.2.2
^ permalink raw reply related
* Re: Throughput regression with `tcp: refine TSO autosizing`
From: Michal Kazior @ 2015-02-04 12:22 UTC (permalink / raw)
To: Eric Dumazet; +Cc: linux-wireless, Network Development, eyalpe
In-Reply-To: <1423051045.907.108.camel@edumazet-glaptop2.roam.corp.google.com>
On 4 February 2015 at 12:57, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Wed, 2015-02-04 at 12:35 +0100, Michal Kazior wrote:
>
>> > (Or maybe wifi drivers should start to use skb->xmit_more as a signal to end aggregation)
>>
>> This could work if your firmware/device supports this kind of thing.
>> To my understanding ath10k firmware doesn't.
>
> This is a pure software signal. You do not need firmware support.
>
> Idea is the following :
>
> Your driver gets a train of messages, coming from upper layers (TCP, IP,
> qdisc)
>
> It can know that a packet is not the last one, by looking at
> skb->xmit_more.
>
> Basically, aggregation logic could use this signal as a very clear
> indicator you got the end of a train -> force the xmit right now.
There's no way to tell ath10k firmware: "xmit right now". The firmware
does all tx aggregation logic by itself. Host driver just submits a
frame and hopes it'll get out soon. It's not even a tx-ring you'd
expect. Each frame has a host assigned id which firmware then uses in
tx completion.
> To disable gso you would have to use :
>
> ethtool -K wlan1 gso off
Oh, thanks! This works. However I can't turn it on:
; ethtool -K wlan1 gso on
Could not change any device features
..so I guess it makes no sense to re-run tests because:
; ethtool -k wlan1 | grep generic
tx-checksum-ip-generic: on [fixed]
generic-segmentation-offload: off [requested on]
generic-receive-offload: on
And this seems to never change.
Michał
^ permalink raw reply
* [PATCH] net: core/dev: fix sparse warning
From: Lad Prabhakar @ 2015-02-04 12:25 UTC (permalink / raw)
To: David S. Miller, netdev; +Cc: linux-kernel, Eric Dumazet, Lad, Prabhakar
From: "Lad, Prabhakar" <prabhakar.csengg@gmail.com>
this patch fixes following sparse warning:
net/core/dev.c: In function 'validate_xmit_skb_list':
net/core/dev.c:2720: warning: 'tail' may be used uninitialized in this function
Although its a false positive, as head is assigned to NULL in the
beginning, due which later in the loop tail is assigned to skb->prev.
Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
---
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 8ce0d1a..c736467 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2717,7 +2717,7 @@ out_null:
struct sk_buff *validate_xmit_skb_list(struct sk_buff *skb, struct net_device *dev)
{
- struct sk_buff *next, *head = NULL, *tail;
+ struct sk_buff *next, *head = NULL, *tail = NULL;
for (; skb != NULL; skb = next) {
next = skb->next;
--
1.9.1
^ permalink raw reply related
* [PATCH] net: ethernet: ti/cpsw-common.c: fix sparse warning
From: Lad Prabhakar @ 2015-02-04 12:31 UTC (permalink / raw)
To: David S. Miller, netdev; +Cc: linux-kernel, Tony Lindgren, Lad, Prabhakar
From: "Lad, Prabhakar" <prabhakar.csengg@gmail.com>
this patch fixes following sparse warning:
cpsw-common.c:23:5: warning: symbol 'cpsw_am33xx_cm_get_macid' was not declared. Should it be static?
Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
---
drivers/net/ethernet/ti/cpsw-common.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/ethernet/ti/cpsw-common.c b/drivers/net/ethernet/ti/cpsw-common.c
index 763ada1..f595094 100644
--- a/drivers/net/ethernet/ti/cpsw-common.c
+++ b/drivers/net/ethernet/ti/cpsw-common.c
@@ -17,6 +17,8 @@
#include <linux/regmap.h>
#include <linux/mfd/syscon.h>
+#include "cpsw.h"
+
#define AM33XX_CTRL_MAC_LO_REG(offset, id) ((offset) + 0x8 * (id))
#define AM33XX_CTRL_MAC_HI_REG(offset, id) ((offset) + 0x8 * (id) + 0x4)
--
1.9.1
^ permalink raw reply related
* Re: low vxlan throughput with tso enabled
From: Reiner Herrmann @ 2015-02-04 12:34 UTC (permalink / raw)
To: Tom Herbert; +Cc: Linux Netdev List, svens, Vittorio Curcio
In-Reply-To: <CA+mtBx-7Q1O8KMgmcoKnHurj7DP-4jugkKuqt3b=XaMga2-NEg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 6220 bytes --]
On 02/03/2015 05:26 PM, Tom Herbert wrote:
> On Tue, Feb 3, 2015 at 7:50 AM, Reiner Herrmann
> <reiner.herrmann@sophos.com> wrote:
>> I have a vxlan tunnel established between two network interfaces, which
>> both have a MTU of 1500. The vxlan interfaces have the same MTU.
>> With TSO enabled, I observe low throughput with TCP connections (<100 kB/s).
>> Disabling TSO works around this issue and throughput is as expected.
>> Can someone please explain how TSO is influencing the tunnel to cause
>> such a difference?
> Please provide more information. What NIC? What is the link rate? What
> are you running to test. Also report 'ethtool -k' of both tunnel and
> Ethernet interfaces, and tcpdump on the interfaces (to see GSO
> packets).
Both are GBit NICs (it can be reproduced with different GBit NICs).
One has a link rate of 100 Mbps, the other 1000 Mbps.
To test the throughput, I'm using iperf (in TCP mode) between the two vxlan
interfaces.
I attached captures of the Ethernet interfaces from both devices, one with TSO
enabled on both vxlan interfaces (low throughput), and one with TSO disabled
on the vxlan interface of the iperf client (high throughput).
And below is the ethtool information you asked for.
Thank you for having a look.
Endpoint 1:
===========
Features for eth0:
rx-checksumming: on
tx-checksumming: on
tx-checksum-ipv4: off [fixed]
tx-checksum-ip-generic: on
tx-checksum-ipv6: off [fixed]
tx-checksum-fcoe-crc: off [fixed]
tx-checksum-sctp: off [fixed]
scatter-gather: on
tx-scatter-gather: on
tx-scatter-gather-fraglist: off [fixed]
tcp-segmentation-offload: on
tx-tcp-segmentation: on
tx-tcp-ecn-segmentation: off [fixed]
tx-tcp6-segmentation: on
udp-fragmentation-offload: off [fixed]
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: off [fixed]
rx-vlan-offload: on
tx-vlan-offload: on
ntuple-filters: off [fixed]
receive-hashing: on
highdma: on [fixed]
rx-vlan-filter: on [fixed]
vlan-challenged: off [fixed]
tx-lockless: off [fixed]
netns-local: off [fixed]
tx-gso-robust: off [fixed]
tx-fcoe-segmentation: off [fixed]
tx-gre-segmentation: off [fixed]
tx-udp_tnl-segmentation: off [fixed]
tx-mpls-segmentation: off [fixed]
fcoe-mtu: off [fixed]
tx-nocache-copy: off
loopback: off [fixed]
rx-fcs: off
rx-all: off
tx-vlan-stag-hw-insert: off [fixed]
rx-vlan-stag-hw-parse: off [fixed]
rx-vlan-stag-filter: off [fixed]
Features for vxlan0:
rx-checksumming: on
tx-checksumming: on
tx-checksum-ipv4: off [fixed]
tx-checksum-ip-generic: on
tx-checksum-ipv6: off [fixed]
tx-checksum-fcoe-crc: off [fixed]
tx-checksum-sctp: off [fixed]
scatter-gather: on
tx-scatter-gather: on
tx-scatter-gather-fraglist: off [fixed]
tcp-segmentation-offload: on
tx-tcp-segmentation: on
tx-tcp-ecn-segmentation: on
tx-tcp6-segmentation: on
udp-fragmentation-offload: on
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: off [fixed]
rx-vlan-offload: off [fixed]
tx-vlan-offload: on
ntuple-filters: off [fixed]
receive-hashing: off [fixed]
highdma: off [fixed]
rx-vlan-filter: off [fixed]
vlan-challenged: off [fixed]
tx-lockless: on [fixed]
netns-local: on [fixed]
tx-gso-robust: off [fixed]
tx-fcoe-segmentation: off [fixed]
tx-gre-segmentation: off [fixed]
tx-udp_tnl-segmentation: off [fixed]
tx-mpls-segmentation: off [fixed]
fcoe-mtu: off [fixed]
tx-nocache-copy: off
loopback: off [fixed]
rx-fcs: off [fixed]
rx-all: off [fixed]
tx-vlan-stag-hw-insert: on
rx-vlan-stag-hw-parse: off [fixed]
rx-vlan-stag-filter: off [fixed]
Endpoint 2:
===========
Features for eth0:
rx-checksumming: on
tx-checksumming: on
tx-checksum-ipv4: off [fixed]
tx-checksum-ip-generic: on
tx-checksum-ipv6: off [fixed]
tx-checksum-fcoe-crc: off [fixed]
tx-checksum-sctp: off [fixed]
scatter-gather: on
tx-scatter-gather: on
tx-scatter-gather-fraglist: off [fixed]
tcp-segmentation-offload: on
tx-tcp-segmentation: on
tx-tcp-ecn-segmentation: off [fixed]
tx-tcp6-segmentation: on
udp-fragmentation-offload: off [fixed]
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: off [fixed]
rx-vlan-offload: on
tx-vlan-offload: on
ntuple-filters: off [fixed]
receive-hashing: on
highdma: on [fixed]
rx-vlan-filter: off [fixed]
vlan-challenged: off [fixed]
tx-lockless: off [fixed]
netns-local: off [fixed]
tx-gso-robust: off [fixed]
tx-fcoe-segmentation: off [fixed]
tx-gre-segmentation: off [fixed]
tx-ipip-segmentation: off [fixed]
tx-sit-segmentation: off [fixed]
tx-udp_tnl-segmentation: off [fixed]
tx-mpls-segmentation: off [fixed]
fcoe-mtu: off [fixed]
tx-nocache-copy: off
loopback: off [fixed]
rx-fcs: off
rx-all: off
tx-vlan-stag-hw-insert: off [fixed]
rx-vlan-stag-hw-parse: off [fixed]
rx-vlan-stag-filter: off [fixed]
l2-fwd-offload: off [fixed]
busy-poll: off [fixed]
Features for vxlan0:
rx-checksumming: on
tx-checksumming: on
tx-checksum-ipv4: off [fixed]
tx-checksum-ip-generic: on
tx-checksum-ipv6: off [fixed]
tx-checksum-fcoe-crc: off [fixed]
tx-checksum-sctp: off [fixed]
scatter-gather: on
tx-scatter-gather: on
tx-scatter-gather-fraglist: off [fixed]
tcp-segmentation-offload: on
tx-tcp-segmentation: on
tx-tcp-ecn-segmentation: on
tx-tcp6-segmentation: on
udp-fragmentation-offload: on
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: off [fixed]
rx-vlan-offload: off [fixed]
tx-vlan-offload: on
ntuple-filters: off [fixed]
receive-hashing: off [fixed]
highdma: off [fixed]
rx-vlan-filter: off [fixed]
vlan-challenged: off [fixed]
tx-lockless: on [fixed]
netns-local: off [fixed]
tx-gso-robust: off [fixed]
tx-fcoe-segmentation: off [fixed]
tx-gre-segmentation: off [fixed]
tx-ipip-segmentation: off [fixed]
tx-sit-segmentation: off [fixed]
tx-udp_tnl-segmentation: off [fixed]
tx-mpls-segmentation: off [fixed]
fcoe-mtu: off [fixed]
tx-nocache-copy: off
loopback: off [fixed]
rx-fcs: off [fixed]
rx-all: off [fixed]
tx-vlan-stag-hw-insert: on
rx-vlan-stag-hw-parse: off [fixed]
rx-vlan-stag-filter: off [fixed]
l2-fwd-offload: off [fixed]
busy-poll: off [fixed]
[-- Attachment #2: device1_eth0_tso_off.pcap.xz --]
[-- Type: application/x-xz, Size: 338104 bytes --]
[-- Attachment #3: device1_eth0_tso_on.pcap.xz --]
[-- Type: application/x-xz, Size: 31604 bytes --]
[-- Attachment #4: device2_eth0_tso_off.pcap.xz --]
[-- Type: application/x-xz, Size: 334164 bytes --]
[-- Attachment #5: device2_eth0_tso_on.pcap.xz --]
[-- Type: application/x-xz, Size: 35744 bytes --]
^ permalink raw reply
* Re: Throughput regression with `tcp: refine TSO autosizing`
From: Eric Dumazet @ 2015-02-04 12:38 UTC (permalink / raw)
To: Michal Kazior; +Cc: linux-wireless, Network Development, eyalpe
In-Reply-To: <CA+BoTQ=BDcQ779uKCuX+f40=4npXVF4MTQnpjKimNYAxPsxBoQ@mail.gmail.com>
On Wed, 2015-02-04 at 13:22 +0100, Michal Kazior wrote:
> On 4 February 2015 at 12:57, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
> > To disable gso you would have to use :
> >
> > ethtool -K wlan1 gso off
>
> Oh, thanks! This works. However I can't turn it on:
>
> ; ethtool -K wlan1 gso on
> Could not change any device features
>
> ..so I guess it makes no sense to re-run tests because:
>
> ; ethtool -k wlan1 | grep generic
> tx-checksum-ip-generic: on [fixed]
> generic-segmentation-offload: off [requested on]
> generic-receive-offload: on
>
> And this seems to never change.
GSO requires SG (Scatter Gather)
Are you sure this hardware has no SG support ?
^ permalink raw reply
* Re: [PATCH] net: core/dev: fix sparse warning
From: Eric Dumazet @ 2015-02-04 12:41 UTC (permalink / raw)
To: Lad Prabhakar; +Cc: David S. Miller, netdev, linux-kernel, Eric Dumazet
In-Reply-To: <1423052746-3688-1-git-send-email-prabhakar.csengg@gmail.com>
On Wed, 2015-02-04 at 12:25 +0000, Lad Prabhakar wrote:
> From: "Lad, Prabhakar" <prabhakar.csengg@gmail.com>
>
> this patch fixes following sparse warning:
> net/core/dev.c: In function 'validate_xmit_skb_list':
> net/core/dev.c:2720: warning: 'tail' may be used uninitialized in this function
>
> Although its a false positive, as head is assigned to NULL in the
> beginning, due which later in the loop tail is assigned to skb->prev.
>
> Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
> ---
> 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 8ce0d1a..c736467 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -2717,7 +2717,7 @@ out_null:
>
> struct sk_buff *validate_xmit_skb_list(struct sk_buff *skb, struct net_device *dev)
> {
> - struct sk_buff *next, *head = NULL, *tail;
> + struct sk_buff *next, *head = NULL, *tail = NULL;
>
> for (; skb != NULL; skb = next) {
> next = skb->next;
Which gcc/sparse versions are you using ?
I do not see this warning here.
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
4.8.2-19ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.8 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib
--enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--enable-gnu-unique-object --disable-libmudflap --enable-plugin
--with-system-zlib --disable-browser-plugin --enable-java-awt=gtk
--enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre
--enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64
--with-arch-directory=amd64
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1)
$ sparse --version
0.4.5-rc1
^ permalink raw reply
* Re: low vxlan throughput with tso enabled
From: Reiner Herrmann @ 2015-02-04 12:42 UTC (permalink / raw)
To: Rick Jones, netdev; +Cc: svens, Vittorio Curcio
In-Reply-To: <54D0F8FF.1090204@hp.com>
On 02/03/2015 05:36 PM, Rick Jones wrote:
> I've been under the impression that one generally wants the MTU of a tunnel interface to be no more than the MTU of the physical interface over which it runs, less the
> size of the encapsulation headers used by the tunnel. What happens when you make the MTU of the tunnel interface 1400 bytes instead of 1500?
Lowering the MTU also brings throughput back to normal, but I'm interested in
why disabling TSO also seems to help (even with the same MTU).
^ permalink raw reply
* [PATCH net-next 0/3] Add support in ethtool to get expansion ROM version
From: Hariprasad Shenai @ 2015-02-04 12:49 UTC (permalink / raw)
To: netdev; +Cc: davem, ben, leedom, anish, nirranjan, kumaras, Hariprasad Shenai
Hi
This series adds support to get expansion ROM version via ethtool getdrvinfo.
PATCH 1/3 ("ethtool: rename reserved1 memeber in ethtool_drvinfo for expansion
ROM version") is created against net-next tree.
PATCH 2/3 ("cxgb4: Add support in cxgb4 to get expansion rom version via
ethtool") is created against net-next tree.
PATCH 3/3 ("ethtool: Add support to get expansion ROM version in ethtool
getdrvinfo") is created against ethtool tree.
We have included all the maintainers of respective trees. Kindly review the
change and let us know in case of any review comments.
Thanks
Hariprasad Shenai (3):
ethtool: rename reserved1 memeber in ethtool_drvinfo for expansion
ROM version
cxgb4: Add support in cxgb4 to get expansion rom version via ethtool
ethtool: Add support to get expansion ROM version in ethtool getdrvinfo
drivers/net/ethernet/chelsio/cxgb4/cxgb4.h | 1 +
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 9 +++++
drivers/net/ethernet/chelsio/cxgb4/t4_hw.c | 37 +++++++++++++++++++++++
drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h | 8 +++++
include/uapi/linux/ethtool.h | 3 +-
5 files changed, 57 insertions(+), 1 deletions(-)
---
ethtool-copy.h | 3 ++-
ethtool.c | 2 ++
2 files changed, 4 insertions(+), 1 deletions(-)
^ 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