* Re: [patch 1/2 v2 -next] cxgb4: potential shift wrapping bug
From: David Miller @ 2014-10-08 20:08 UTC (permalink / raw)
To: dan.carpenter; +Cc: hariprasad, netdev, kernel-janitors
In-Reply-To: <20141008134317.GA12036@mwanda>
From: Dan Carpenter <dan.carpenter@oracle.com>
Date: Wed, 8 Oct 2014 16:43:17 +0300
> "cntxt_id" is an unsigned int but "udb" is a u64 so there is a potential
> shift wrapping bug here.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] i40e: skb->xmit_more support
From: David Miller @ 2014-10-08 20:04 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>
Applied, thanks everyone.
^ permalink raw reply
* Re: [PATCH 0/2] net: fs_enet: Remove non NAPI RX and add NAPI for TX
From: David Miller @ 2014-10-08 20:03 UTC (permalink / raw)
To: christophe.leroy
Cc: pantelis.antoniou, vbordug, linux-kernel, linuxppc-dev, netdev
In-Reply-To: <20141007130454.13EF21AB266@localhost.localdomain>
From: Christophe Leroy <christophe.leroy@c-s.fr>
Date: Tue, 7 Oct 2014 15:04:53 +0200 (CEST)
> When using a MPC8xx as a router, 'perf' shows a significant time spent in
> fs_enet_interrupt() and fs_enet_start_xmit().
> 'perf annotate' shows that the time spent in fs_enet_start_xmit is indeed spent
> between spin_unlock_irqrestore() and the following instruction, hence in
> interrupt handling. This is due to the TX complete interrupt that fires after
> each transmitted packet.
> This patchset first remove all non NAPI handling as NAPI has become the only
> mode for RX, then adds NAPI for handling TX complete.
> This improves NAT TCP throughput by 21% on MPC885 with FEC.
>
> Tested on MPC885 with FEC.
>
> [PATCH 1/2] net: fs_enet: Remove non NAPI RX
> [PATCH 2/2] net: fs_enet: Add NAPI TX
>
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Series applied, thanks.
Any particular reason you didn't just put the TX reclaim calls into
the existing NAPI handler?
That's what other drivers do, because TX reclaim can make SKBs
available for RX packet receive on the local cpu. So generally you
have one NAPI context that first does any pending TX reclaim, then
polls the RX ring for new packets.
^ permalink raw reply
* Re: [PATCH v4 net-next] r8169:add support for RTL8168EP
From: David Miller @ 2014-10-08 19:59 UTC (permalink / raw)
To: hau; +Cc: netdev, nic_swsd, linux-kernel
In-Reply-To: <1412665841-7338-1-git-send-email-hau@realtek.com>
From: Chun-Hao Lin <hau@realtek.com>
Date: Tue, 7 Oct 2014 15:10:41 +0800
> RTL8168EP is Realtek PCIe Gigabit Ethernet controller with DASH support.
> It is a successor chip of RTL8168DP.
>
> For RTL8168EP, the read/write ocp register is via eri channel type 2, so I
> move ocp_xxx() related functions under rtl_eri_xxx. And use r8168dp_ocp_xxx()
> for RTL8168DP ocp read/write, r8168ep_ocp_xxx() for RTL8168EP ocp read/write.
>
> The way of checking dash enable is different with RTL8168DP. I use
> r8168dp_check_dash()for RTL8168DP and r8168ep_check_dash() for RTL8168EP,
> to check if dash is enabled.
>
> The driver_start() and driver_stop() of RTL8168EP is also different with
> RTL8168DP. I use rtl8168dp_driver_xxx() for RTL8168DP and
> rtl8168ep_driver_xxx for RTL8168EP.
>
> Right now, RTL8168EP phy mcu did not need firmware code patch, so I did not
> add firmware code for it.
> so I did not add firmware code for it.
>
> Signed-off-by: Chun-Hao Lin <hau@realtek.com>
I'll apply this, but if Francois has more feedback please work on it
with follow-on changes.
Thank you.
^ permalink raw reply
* Re: [PATCH net-next] r8152: use mutex for hw settings
From: David Miller @ 2014-10-08 19:45 UTC (permalink / raw)
To: hayeswang; +Cc: netdev, nic_swsd, linux-kernel, linux-usb
In-Reply-To: <1394712342-15778-58-Taiwan-albertk@realtek.com>
From: Hayes Wang <hayeswang@realtek.com>
Date: Tue, 7 Oct 2014 13:36:30 +0800
> Use mutex to avoid that the serial hw settings would be interrupted
> by other settings. Although there is no problem now, it makes the
> driver more safe.
>
> Signed-off-by: Hayes Wang <hayeswang@realtek.com>
I think a much simpler fix is to take rtnl_lock() in the workqueue
function and suspend/resume ops.
Every other place you are adding the mutex already holds the RTNL
mutex.
^ permalink raw reply
* Re: [Patch net] net_sched: copy exts->type in tcf_exts_change()
From: David Miller @ 2014-10-08 19:41 UTC (permalink / raw)
To: xiyou.wangcong; +Cc: netdev, jhs, john.fastabend
In-Reply-To: <1412641314-17335-1-git-send-email-xiyou.wangcong@gmail.com>
From: Cong Wang <xiyou.wangcong@gmail.com>
Date: Mon, 6 Oct 2014 17:21:54 -0700
> We need to copy exts->type when committing the change, otherwise
> it would be always 0. This is a quick fix for -net and -stable,
> for net-next tcf_exts will be removed.
>
> Fixes: commit 33be627159913b094bb578e83 ("net_sched: act: use standard struct list_head")
> Reported-by: Jamal Hadi Salim <jhs@mojatatu.com>
> Cc: Jamal Hadi Salim <jhs@mojatatu.com>
> Cc: John Fastabend <john.fastabend@gmail.com>
> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Ok, applied and queued up for -stable, I'll sort out the merge hassles
with net-next too.
^ permalink raw reply
* Re: [PATCH RFC v3 net 2/2] ipv6: Avoid restarting fib6_lookup() for RTF_CACHE hit case
From: David Miller @ 2014-10-08 19:32 UTC (permalink / raw)
To: kafai; +Cc: netdev, hannes
In-Reply-To: <1412640315-22472-3-git-send-email-kafai@fb.com>
From: Martin KaFai Lau <kafai@fb.com>
Date: Mon, 6 Oct 2014 17:05:15 -0700
> When there is a RTF_CACHE hit, no need to redo fib6_lookup()
> with reachable=0.
>
> Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
> Signed-off-by: Martin KaFai Lau <kafai@fb.com>
Ok this looks fine, and I can see how there is a dependency with patch
#1.
But I also want to point out how this change show my point about
BACKTRACK() even more. Read this function after this patch is
applied and someone auditing might say "oh, 'out' label is now
unused, we can remove it"
Again, hidden control flow is really bad, and we've had very serious
bugs in the past because of it (which we've fixed by ditching the
side effect causing macros in favor of properly designed inline
functions).
Trying to be constructive, why don't we go in a direction like
the following?
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index a318dd89..99612c5 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -772,6 +772,26 @@ int rt6_route_rcv(struct net_device *dev, u8 *opt, int len,
}
#endif
+static struct fib6_node *rt6_backtrack(struct net *net, struct rt6_info *rt, struct fib6_node *fn, const struct in6_addr *saddr)
+{
+ if (rt == net->ipv6.ip6_null_entry) {
+ struct fib6_node *pn;
+
+ while (1) {
+ if (fn->fn_flags & RTN_TL_ROOT)
+ break;
+ pn = fn->parent;
+ if (FIB6_SUBTREE(pn) && FIB6_SUBTREE(pn) != fn)
+ fn = fib6_lookup(FIB6_SUBTREE(pn), NULL, saddr);
+ else
+ fn = pn;
+ if (fn->fn_flags & RTN_RTINFO)
+ break;
+ }
+ }
+ return fn;
+}
+
#define BACKTRACK(__net, saddr) \
do { \
if (rt == __net->ipv6.ip6_null_entry) { \
@@ -934,10 +954,15 @@ restart:
rt = rt6_select(fn, oif, strict | reachable);
if (rt->rt6i_nsiblings)
rt = rt6_multipath_select(rt, fl6, oif, strict | reachable);
- BACKTRACK(net, &fl6->saddr);
- if (rt == net->ipv6.ip6_null_entry ||
- rt->rt6i_flags & RTF_CACHE)
- goto out;
+ fn = rt6_backtrack(net, rt, fn, &fl6->saddr);
+ if (rt == net->ipv6.ip6_null_entry) {
+ if (fn->fn_flags & RTN_TL_ROOT)
+ goto out;
+ if (fn->fn_flags & RTN_RTINFO)
+ goto restart;
+ }
+ if (rt->rt6i_flags & RTF_CACHE)
+ goto out1;
dst_hold(&rt->dst);
read_unlock_bh(&table->tb6_lock);
@@ -974,6 +999,7 @@ out:
reachable = 0;
goto restart_2;
}
+out1:
dst_hold(&rt->dst);
read_unlock_bh(&table->tb6_lock);
out2:
^ permalink raw reply related
* Re: [PATCH RFC v3 net 1/2] ipv6: Remove the net->ipv6.ip6_null_entry check
From: David Miller @ 2014-10-08 19:08 UTC (permalink / raw)
To: kafai; +Cc: netdev, hannes
In-Reply-To: <1412640315-22472-2-git-send-email-kafai@fb.com>
From: Martin KaFai Lau <kafai@fb.com>
Date: Mon, 6 Oct 2014 17:05:14 -0700
> The above BACKTRACK have already caught the rt == net->ipv6.ip6_null_entry case
>
> Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
> Signed-off-by: Martin KaFai Lau <kafai@fb.com>
...
> @@ -936,8 +936,7 @@ restart:
> if (rt->rt6i_nsiblings)
> rt = rt6_multipath_select(rt, fl6, oif, strict | reachable);
> BACKTRACK(net, &fl6->saddr);
> - if (rt == net->ipv6.ip6_null_entry ||
> - rt->rt6i_flags & RTF_CACHE)
> + if (rt->rt6i_flags & RTF_CACHE)
> goto out;
>
> dst_hold(&rt->dst);
I think this is sort of going in the wrong direction.
The BACKTRACK() macro hides a lot of side effects inside of it's
implementation, and worst of all it hides a change of control flow
with it's "goto out;" and "goto restart;"
I'd rather see us clean this up in some way that someone auditing this
code won't be tricked into missing the control flow side effects, than
adding more dependencies upon BACKTRACK()'s implementation.
Thanks.
^ permalink raw reply
* Re: [PATCH net] bna: page allocation during interrupts to use a mempool.
From: Eric Dumazet @ 2014-10-08 19:04 UTC (permalink / raw)
To: Eric Wheeler; +Cc: Shahed Shaikh, Stephen Hemminger, netdev, Rasesh Mody
In-Reply-To: <alpine.DEB.2.00.1410081157470.16668@ware.dreamhost.com>
On Wed, 2014-10-08 at 12:01 -0700, Eric Wheeler wrote:
> On Tue, 7 Oct 2014, Eric Dumazet wrote:
>
> > On Tue, 2014-10-07 at 17:48 -0700, Eric Wheeler wrote:
> >
> >> Just += unmap->vector.len still did not work (same backtrace), so I've
> >> rebuilt with PAGE_SIZE<<2 and so far so good. I'll let it run all night
> >> and see if we get any problems.
> >
> > Further inspection of the driver told me that unmap->vector.len should
> > be 16384 already. (same than PAGE_SIZE << 2)
> > (set at line 304, drivers/net/ethernet/brocade/bna/bnad.c)
> >
> > So you might hit memory fragmentation issues.
> >
> > Do you have CONFIG_COMPACTION=y in your .config ?
>
> We're still having the backtrace.
What is the output of
free
cat /proc/sys/vm/min_free_kbytes
cat /proc/buddyinfo
^ permalink raw reply
* Re: [PATCH V3.18] rtlwifi: Fix possible unaligned array in ether_addr_copy()
From: David Miller @ 2014-10-08 19:00 UTC (permalink / raw)
To: Larry.Finger; +Cc: linville, linux-wireless, troy_tan, netdev
In-Reply-To: <1412790295-27858-1-git-send-email-Larry.Finger@lwfinger.net>
From: Larry Finger <Larry.Finger@lwfinger.net>
Date: Wed, 8 Oct 2014 12:44:55 -0500
> Two macros used to copy BSSID information use ether_addr_copy(), thus
> the arrays must be 2-byte aligned. In one case, the array could become
> unaligned if the struct containing it were changed. Use the __unaligned(2)
> attribute to retain the necessary alignment. In addition, the magic number
> used to specify the size of the array is replaced by ETH_ALEN.
>
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Acked-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* Re: [PATCH net] bna: page allocation during interrupts to use a mempool.
From: Eric Wheeler @ 2014-10-08 19:07 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Shahed Shaikh, Stephen Hemminger, netdev, Rasesh Mody
In-Reply-To: <1412731718.11091.175.camel@edumazet-glaptop2.roam.corp.google.com>
On Tue, 7 Oct 2014, Eric Dumazet wrote:
> On Tue, 2014-10-07 at 17:48 -0700, Eric Wheeler wrote:
>
>> Just += unmap->vector.len still did not work (same backtrace), so I've
>> rebuilt with PAGE_SIZE<<2 and so far so good. I'll let it run all night
>> and see if we get any problems.
>
> Further inspection of the driver told me that unmap->vector.len should
> be 16384 already. (same than PAGE_SIZE << 2)
> (set at line 304, drivers/net/ethernet/brocade/bna/bnad.c)
>
> So you might hit memory fragmentation issues.
>
> Do you have CONFIG_COMPACTION=y in your .config ?
yes.
-e
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH net] bna: page allocation during interrupts to use a mempool.
From: Eric Wheeler @ 2014-10-08 19:01 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Shahed Shaikh, Stephen Hemminger, netdev, Rasesh Mody
In-Reply-To: <1412731718.11091.175.camel@edumazet-glaptop2.roam.corp.google.com>
On Tue, 7 Oct 2014, Eric Dumazet wrote:
> On Tue, 2014-10-07 at 17:48 -0700, Eric Wheeler wrote:
>
>> Just += unmap->vector.len still did not work (same backtrace), so I've
>> rebuilt with PAGE_SIZE<<2 and so far so good. I'll let it run all night
>> and see if we get any problems.
>
> Further inspection of the driver told me that unmap->vector.len should
> be 16384 already. (same than PAGE_SIZE << 2)
> (set at line 304, drivers/net/ethernet/brocade/bna/bnad.c)
>
> So you might hit memory fragmentation issues.
>
> Do you have CONFIG_COMPACTION=y in your .config ?
We're still having the backtrace.
Here's nstat -a :
IpInReceives 305249739 0.0
IpInAddrErrors 1100 0.0
IpInDelivers 305232139 0.0
IpOutRequests 256712718 0.0
IpOutNoRoutes 197 0.0
IcmpInErrors 10241 0.0
IcmpInCsumErrors 4200 0.0
IcmpInTimeExcds 9753 0.0
IcmpInEchoReps 247 0.0
IcmpInTimestamps 241 0.0
IcmpOutErrors 10325 0.0
IcmpOutTimeExcds 9792 0.0
IcmpOutEchoReps 286 0.0
IcmpOutTimestamps 247 0.0
IcmpMsgInType0 241 0.0
IcmpMsgInType3 9753 0.0
IcmpMsgInType8 247 0.0
IcmpMsgOutType0 247 0.0
IcmpMsgOutType3 9792 0.0
IcmpMsgOutType8 286 0.0
TcpActiveOpens 9585 0.0
TcpPassiveOpens 1233 0.0
TcpAttemptFails 8119 0.0
TcpEstabResets 165 0.0
TcpInSegs 305269357 0.0
TcpOutSegs 745563105 0.0
TcpRetransSegs 9118 0.0
TcpOutRsts 74110 0.0
UdpInDatagrams 81957 0.0
UdpOutDatagrams 141536 0.0
Ip6InReceives 348168 0.0
Ip6InNoRoutes 1 0.0
Ip6InDelivers 303971 0.0
Ip6OutRequests 168344 0.0
Ip6InMcastPkts 183943 0.0
Ip6OutMcastPkts 7976 0.0
Ip6InOctets 867026250 0.0
Ip6OutOctets 843515112 0.0
Ip6InMcastOctets 23885658 0.0
Ip6OutMcastOctets 733912 0.0
Ip6InNoECTPkts 348168 0.0
Icmp6InMsgs 139747 0.0
Icmp6OutMsgs 4120 0.0
Icmp6InGroupMembQueries 3306 0.0
Icmp6InRouterAdvertisements 135646 0.0
Icmp6InNeighborAdvertisements 795 0.0
Icmp6OutRouterSolicits 187 0.0
Icmp6OutNeighborSolicits 77 0.0
Icmp6OutMLDv2Reports 3856 0.0
Icmp6InType130 3306 0.0
Icmp6InType134 135646 0.0
Icmp6InType136 795 0.0
Icmp6OutType133 187 0.0
Icmp6OutType135 77 0.0
Icmp6OutType143 3856 0.0
TcpExtSyncookiesFailed 5 0.0
TcpExtPruneCalled 3694 0.0
TcpExtTW 882 0.0
TcpExtPAWSEstab 3 0.0
TcpExtDelayedACKs 974539 0.0
TcpExtDelayedACKLocked 21365 0.0
TcpExtDelayedACKLost 2071 0.0
TcpExtTCPPrequeued 84806172 0.0
TcpExtTCPDirectCopyFromBacklog 687333144 0.0
TcpExtTCPDirectCopyFromPrequeue 2733255078 0.0
TcpExtTCPPrequeueDropped 915 0.0
TcpExtTCPHPHits 85972078 0.0
TcpExtTCPHPHitsToUser 790722 0.0
TcpExtTCPPureAcks 119419354 0.0
TcpExtTCPHPAcks 72305521 0.0
TcpExtTCPRenoRecovery 36 0.0
TcpExtTCPSackRecovery 431 0.0
TcpExtTCPFACKReorder 8 0.0
TcpExtTCPSACKReorder 51 0.0
TcpExtTCPTSReorder 41 0.0
TcpExtTCPFullUndo 67 0.0
TcpExtTCPPartialUndo 62 0.0
TcpExtTCPDSACKUndo 176 0.0
TcpExtTCPLossUndo 11 0.0
TcpExtTCPLostRetransmit 10 0.0
TcpExtTCPSackFailures 6 0.0
TcpExtTCPFastRetrans 715 0.0
TcpExtTCPForwardRetrans 411 0.0
TcpExtTCPSlowStartRetrans 495 0.0
TcpExtTCPTimeouts 3517 0.0
TcpExtTCPLossProbes 2143 0.0
TcpExtTCPLossProbeRecovery 908 0.0
TcpExtTCPRenoRecoveryFail 3 0.0
TcpExtTCPSchedulerFailed 245 0.0
TcpExtTCPRcvCollapsed 21549 0.0
TcpExtTCPDSACKOldSent 1891 0.0
TcpExtTCPDSACKRecv 1662 0.0
TcpExtTCPAbortOnData 28 0.0
TcpExtTCPAbortOnClose 242 0.0
TcpExtTCPAbortOnTimeout 18 0.0
TcpExtTCPDSACKIgnoredNoUndo 928 0.0
TcpExtTCPSpuriousRTOs 5 0.0
TcpExtTCPSackShifted 479 0.0
TcpExtTCPSackMerged 498 0.0
TcpExtTCPSackShiftFallback 2934 0.0
TcpExtIPReversePathFilter 9407 0.0
TcpExtTCPRetransFail 582 0.0
TcpExtTCPRcvCoalesce 23709443 0.0
TcpExtTCPOFOQueue 19162 0.0
TcpExtTCPChallengeACK 8098 0.0
TcpExtTCPSpuriousRtxHostQueues 2932 0.0
TcpExtTCPAutoCorking 56870637 0.0
IpExtInMcastPkts 87288 0.0
IpExtOutMcastPkts 146507 0.0
IpExtInBcastPkts 16682 0.0
IpExtInOctets 54665312000 0.0
IpExtOutOctets 3365913113553 0.0
IpExtInMcastOctets 2765660 0.0
IpExtOutMcastOctets 4688240 0.0
IpExtInBcastOctets 3651661 0.0
IpExtInNoECTPkts 313364477 0.0
--
Eric Wheeler, President eWheeler, Inc. dba Global Linux Security
888-LINUX26 (888-546-8926) Fax: 503-716-3878 PO Box 25107
www.GlobalLinuxSecurity.pro Linux since 1996! Portland, OR 97298
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* [PATCH 1/1 net-next] netlabel: directly return netlbl_unlabel_genl_init()
From: Fabian Frederick @ 2014-10-08 18:37 UTC (permalink / raw)
To: linux-kernel; +Cc: Fabian Frederick, Paul Moore, David S. Miller, netdev
No need to store netlbl_unlabel_genl_init result and test it before returning.
Signed-off-by: Fabian Frederick <fabf@skynet.be>
---
net/netlabel/netlabel_user.c | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/net/netlabel/netlabel_user.c b/net/netlabel/netlabel_user.c
index 1e779bb..adf8b79 100644
--- a/net/netlabel/netlabel_user.c
+++ b/net/netlabel/netlabel_user.c
@@ -71,11 +71,7 @@ int __init netlbl_netlink_init(void)
if (ret_val != 0)
return ret_val;
- ret_val = netlbl_unlabel_genl_init();
- if (ret_val != 0)
- return ret_val;
-
- return 0;
+ return netlbl_unlabel_genl_init();
}
/*
--
1.9.1
^ permalink raw reply related
* Micrel KSZ8031 - phy link missing
From: Angelo Dureghello @ 2014-10-08 18:28 UTC (permalink / raw)
To: netdev
Dear,
i am trying to figure out why, moving to kernel 3.16.2, i have phy-link
missing.
I have an arm-corex AM1808 (TI OMAPL-138/DAVINCI) cpu based board, using
Micrel KSZ8031.
.....
Bad block table not found for chip 0
Bad block table not found for chip 0
Scanning device for bad blocks
Bad block table written to 0x000007fe0000, version 0x01
Bad block table written to 0x000007fc0000, version 0x01
8 cmdlinepart partitions found on MTD device davinci_nand.0
Creating 8 MTD partitions on "davinci_nand.0":
0x000000000000-0x000000020000 : "u-boot-env"
0x000000020000-0x000000180000 : "u-boot"
0x000000180000-0x0000001a0000 : "bootparms"
0x0000001a0000-0x000000200000 : "factory-info"
EMAC: device MAC address: 00:08:e1:03:2a:c5
GPIO LEDs: old hardware revision detected
0x000000200000-0x000000600000 : "kernel"
0x000000600000-0x000000700000 : "config"
0x000000700000-0x000004300000 : "rootfs"
0x000004300000-0x000007f00000 : "update"
davinci_nand davinci_nand.0: controller rev. 2.5
davinci_mdio davinci_mdio.0: Runtime PM disabled, clock forced on.
davinci_mdio davinci_mdio.0: davinci mdio revision 1.5
davinci_mdio davinci_mdio.0: detected phy mask fffffffc
libphy: davinci_mdio.0: probed
davinci_mdio davinci_mdio.0: phy[0]: device davinci_mdio-0:00, driver
Micrel KSZ8031
davinci_mdio davinci_mdio.0: phy[1]: device davinci_mdio-0:01, driver
Micrel KSZ8031
omap_rtc da830-rtc: rtc core: registered da830-rtc as rtc0
da830-rtc: RTC power up reset detected
da830-rtc: already running
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
TCP: cubic registered
NET: Registered protocol family 17
Key type dns_resolver registered
UBI: attaching mtd6 to ubi0
UBI: scanning is finished
UBI: attached mtd6 (name "rootfs", size 60 MiB) to ubi0
UBI: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes
UBI: min./max. I/O unit sizes: 2048/2048, sub-page size 2048
UBI: VID header offset: 2048 (aligned 2048), data offset: 4096
UBI: good PEBs: 480, bad PEBs: 0, corrupted PEBs: 0
UBI: user volume: 1, internal volumes: 1, max. volumes count: 128
UBI: max/mean erase counter: 2/0, WL threshold: 4096, image sequence
number: 1732378828
UBI: available PEBs: 0, total reserved PEBs: 480, PEBs reserved for bad
PEB handling: 20
UBI: background thread "ubi_bgt0d" started, PID 978
davinci_emac davinci_emac.1: Runtime PM disabled, clock forced on.
davinci_emac davinci_emac.1: Runtime PM disabled, clock forced on.
davinci_emac davinci_emac.1: Runtime PM disabled, clock forced on.
input: gpio-keys as /devices/platform/gpio-keys.0/input/input0
omap_rtc da830-rtc: setting system clock to 2014-10-08 18:19:00 UTC
(1412792340)
ALSA device list:
No soundcards found.
UBIFS: background thread "ubifs_bgt0_0" started, PID 988
UBIFS: mounted UBI device 0, volume 0, name "rootfs"
UBIFS: LEB size: 126976 bytes (124 KiB), min./max. I/O unit sizes: 2048
bytes/2048 bytes
UBIFS: FS size: 56504320 bytes (53 MiB, 445 LEBs), journal size 9023488
bytes (8 MiB, 72 LEBs)
UBIFS: reserved for root: 0 bytes (0 KiB)
UBIFS: media format: w4/r0 (latest is w4/r0), UUID
3946B77C-1A15-4675-B537-F22C6CABE24F, small LPT model
VFS: Mounted root (ubifs filesystem) on device 0:13.
devtmpfs: mounted
Freeing unused kernel memory: 140K (c05ad000 - c05d0000)
Please wait: booting...
Populating /dev using udev: udevd[1008]: starting version 182
done
Starting System Watchdog service: done
Mounting configuration partition...
Checking that all configuration is in place...
Done
Starting LED service: done
Setting time zone...
UTC
Time zone set
Starting network...
davinci_mdio davinci_mdio.0: resetting idled controller
net eth0: attached PHY driver [Micrel KSZ8031]
(mii_bus:phy_addr=davinci_mdio-0:00, id=221556)
udhcpc (v1.20.2) started
Sending discover...
Sending discover...
Sending discover...
No lease, failing
Adjusting output audio levels
...
It says no lease. But i verified that even setting a fixed ip, board is
not reachable.
Tracing inside phy.c i don't see the link to come up. Nothing seen on WS.
As far as you know, there can be some bug open for davinci-emac and micrel ?
Many thanks
Angelo
^ permalink raw reply
* Re: [PATCH net-next] i40e: skb->xmit_more support
From: Jeff Kirsher @ 2014-10-08 18:16 UTC (permalink / raw)
To: David Miller; +Cc: gregory.v.rose, eric.dumazet, netdev, dborkman
In-Reply-To: <20141008.133509.184049487346908540.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 734 bytes --]
On Wed, 2014-10-08 at 13:35 -0400, David Miller wrote:
> From: Greg Rose <gregory.v.rose@intel.com>
> Date: Wed, 8 Oct 2014 10:02:58 -0700
>
> > On Tue, 7 Oct 2014 13:30:23 -0700
> > Eric Dumazet <eric.dumazet@gmail.com> wrote:
> >
> >> 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>
> >
> > Looks good to me.
>
> Jeff, ok for me to apply this directly now?
>
> Thanks.
Yes, please do.
Acked-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* [PATCH V3.18] rtlwifi: Fix possible unaligned array in ether_addr_copy()
From: Larry Finger @ 2014-10-08 17:44 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, troy_tan, Larry Finger, netdev
Two macros used to copy BSSID information use ether_addr_copy(), thus
the arrays must be 2-byte aligned. In one case, the array could become
unaligned if the struct containing it were changed. Use the __unaligned(2)
attribute to retain the necessary alignment. In addition, the magic number
used to specify the size of the array is replaced by ETH_ALEN.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
---
drivers/net/wireless/rtlwifi/wifi.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/rtlwifi/wifi.h b/drivers/net/wireless/rtlwifi/wifi.h
index 976667a..6866dcf 100644
--- a/drivers/net/wireless/rtlwifi/wifi.h
+++ b/drivers/net/wireless/rtlwifi/wifi.h
@@ -1370,7 +1370,7 @@ struct rtl_mac {
bool rdg_en;
/*AP*/
- u8 bssid[6];
+ u8 bssid[ETH_ALEN] __aligned(2);
u32 vendor;
u8 mcs[16]; /* 16 bytes mcs for HT rates. */
u32 basic_rates; /* b/g rates */
--
1.8.4.5
^ permalink raw reply related
* Re: Quota in __qdisc_run()
From: John Fastabend @ 2014-10-08 17:38 UTC (permalink / raw)
To: Eric Dumazet
Cc: Jesper Dangaard Brouer, David Miller, netdev, therbert, hannes,
fw, dborkman, jhs, alexander.duyck, john.r.fastabend, dave.taht,
toke
In-Reply-To: <1412686038.11091.111.camel@edumazet-glaptop2.roam.corp.google.com>
On 10/07/2014 05:47 AM, Eric Dumazet wrote:
> On Tue, 2014-10-07 at 09:34 +0200, Jesper Dangaard Brouer wrote:
>> On Fri, 03 Oct 2014 16:30:44 -0700 Eric Dumazet <eric.dumazet@gmail.com> wrote:
>>
>>> Another problem we need to address is the quota in __qdisc_run()
>>> is no longer meaningfull, if each qdisc_restart() can pump many packets.
>>
>> I fully agree. My earlier "magic" packet limit was covering/pampering
>> over this issue.
>
> Although quota was multiplied by 7 or 8 in worst case ?
>
>>
>>> An idea would be to use the bstats (or cpu_qstats if applicable)
>>
>> Please elaborate some more, as I don't completely follow (feel free to
>> show with a patch ;-)).
>>
>
> I was hoping John could finish the percpu stats before I do that.
What stats are you referring to? I assume the remaining stats in the
xmit path mostly in sch_generic.c? By the way I need to do another
review of the classifier code paths but I believe we could drop the
ingress qdisc lock now (finally)...
Also some clean up in sch_generic.c could help this. Notes for
myself mostly,
dev_requeue_skb() can be a void its return value is always 0
the users of handle_dev_cpu_collision and sch_direct_xmit
don't use the qlen for anything returning any positive
integer looks like it would work.
Thanks,
John
--
John Fastabend Intel Corporation
^ permalink raw reply
* Re: [PATCH net-next] i40e: skb->xmit_more support
From: David Miller @ 2014-10-08 17:35 UTC (permalink / raw)
To: gregory.v.rose; +Cc: eric.dumazet, netdev, dborkman, jeffrey.t.kirsher
In-Reply-To: <20141008100258.00006afd@intel.com>
From: Greg Rose <gregory.v.rose@intel.com>
Date: Wed, 8 Oct 2014 10:02:58 -0700
> On Tue, 7 Oct 2014 13:30:23 -0700
> Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
>> 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>
>
> Looks good to me.
Jeff, ok for me to apply this directly now?
Thanks.
^ permalink raw reply
* Re: [net-next PATCH v1 1/3] net: sched: af_packet support for direct ring access
From: John Fastabend @ 2014-10-08 17:20 UTC (permalink / raw)
To: Neil Horman
Cc: Hannes Frederic Sowa, John Fastabend, Daniel Borkmann,
Jesper Dangaard Brouer, John W. Linville, Florian Westphal,
gerlitz.or, netdev, john.ronciak, amirv, eric.dumazet, danny.zhou,
Willem de Bruijn
In-Reply-To: <20141007185940.GE27719@hmsreliant.think-freely.org>
On 10/07/2014 11:59 AM, Neil Horman wrote:
> On Tue, Oct 07, 2014 at 01:26:11AM +0200, Hannes Frederic Sowa wrote:
>> Hi John,
>>
>> On Mon, Oct 6, 2014, at 22:37, John Fastabend wrote:
>>>> I find the six additional ndo ops a bit worrisome as we are adding more
>>>> and more subsystem specific ndoops to this struct. I would like to see
>>>> some unification here, but currently cannot make concrete proposals,
>>>> sorry.
>>>
>>> I agree it seems like a bit much. One thought was to split the ndo
>>> ops into categories. Switch ops, MACVLAN ops, basic ops and with this
>>> userspace queue ops. This sort of goes along with some of the switch
>>> offload work which is going to add a handful more ops as best I can
>>> tell.
>>
>> Thanks for your mail, you answered all of my questions.
>>
>> Have you looked at <https://code.google.com/p/kernel/wiki/ProjectUnetq>?
>> Willem (also in Cc) used sysfs files which get mmaped to represent the
>> tx/rx descriptors. The representation was independent of the device and
>> IIRC the prototype used a write(fd, "", 1) to signal the kernel it
>> should proceed with tx. I agree, it would be great to be syscall-free
>> here.
>>
>> For the semantics of the descriptors we could also easily generate files
>> in sysfs. I thought about something like tracepoints already do for
>> representing the data in the ringbuffer depending on the event:
>>
>> -- >8 --
>> # cat /sys/kernel/debug/tracing/events/net/net_dev_queue/format
>> name: net_dev_queue
>> ID: 1006
>> format:
>> field:unsigned short common_type; offset:0; size:2;
>> signed:0;
>> field:unsigned char common_flags; offset:2; size:1;
>> signed:0;
>> field:unsigned char common_preempt_count; offset:3;
>> size:1; signed:0;
>> field:int common_pid; offset:4; size:4; signed:1;
>>
>> field:void * skbaddr; offset:8; size:8; signed:0;
>> field:unsigned int len; offset:16; size:4; signed:0;
>> field:__data_loc char[] name; offset:20; size:4;
>> signed:1;
>>
>> print fmt: "dev=%s skbaddr=%p len=%u", __get_str(name), REC->skbaddr,
>> REC->len
>> -- >8 --
>>
>> Maybe the macros from tracing are reusable (TP_STRUCT__entry), e.g.
>> endianess would need to be added. Hopefully there is already a user
>> space parser somewhere in the perf sources. An easier to parse binary
>> representation could be added easily and maybe even something vDSO alike
>> if people care about that.
>>
>> Maybe this open/mmap per queue also kills some of the ndo_ops?
>>
>> Bye,
>> Hannes
>>
>
>
> John-
> I don't know if its of use to you here, but I was experimenting awhile
> ago with af_packet memory mapping, using the protection bits in the page tables
> as a doorbell mechanism. I scrapped the work as the performance bottleneck for
> af_packet wasn't found in the syscall trap time, but it occurs to me, it might
> be useful for you here, in that, using this mechanism, if you keep the transmit
> ring non-empty, you only encur the cost of a single trap to start the transmit
> process. Let me know if you want to see it.
>
> Neil
>
Hi Neil,
If you could forward it along I'll take a look. It seems like something
along these lines will be needed.
Thanks,
John
--
John Fastabend Intel Corporation
^ permalink raw reply
* Re: [PATCH v2 net-next 15/15] tipc: remove old ASCII netlink API
From: David Miller @ 2014-10-08 17:19 UTC (permalink / raw)
To: richard.alpe; +Cc: jon.maloy, netdev, tipc-discussion
In-Reply-To: <543527D6.2060607@ericsson.com>
From: Richard Alpe <richard.alpe@ericsson.com>
Date: Wed, 8 Oct 2014 14:02:30 +0200
> Alright. Can we log a deprecated warning when using the old API and
> eventually phase it out?
"Eventually phase it out" just means "break it later" to me, so no.
^ permalink raw reply
* Re: [PATCH net-next] i40e: skb->xmit_more support
From: Greg Rose @ 2014-10-08 17:02 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev, Daniel Borkmann, Jeff Kirsher
In-Reply-To: <1412713823.11091.166.camel@edumazet-glaptop2.roam.corp.google.com>
On Tue, 7 Oct 2014 13:30:23 -0700
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> 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>
Looks good to me.
- Greg
> ---
> 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:
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH V1 net-next 1/2] pgtable: Add API to query if write combining is available
From: David Miller @ 2014-10-08 16:24 UTC (permalink / raw)
To: moshel; +Cc: ogerlitz, jackm, talal, yevgenyp, netdev, amirv
In-Reply-To: <5434F989.2040101@dev.mellanox.co.il>
From: Moshe Lazer <moshel@dev.mellanox.co.il>
Date: Wed, 08 Oct 2014 11:44:57 +0300
>> #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
> The idea was to provide an indication as for whether the arch supports
> write-combining in general.
> If we want to benefit from blue flame operations, we need to map the
> blue flame registers as write combining - otherwise there is no
> benefit. So we would like to know if write combining is supported by
> the system or not.
>
You completely miss my point. On a given architectuire it might be
_illegal_ to map certain address ranges as write-combining without
checks like the ones above that ia64 needs.
Therefore your proposed interface is by definition insufficient.
^ permalink raw reply
* Re: [PATCH] net: description of dma_cookie cause make xmldocs warning
From: Eric Dumazet @ 2014-10-08 16:15 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: Masanari Iida, linux-kernel, davem, netdev, dan.j.williams
In-Reply-To: <54355F66.6060204@cogentembedded.com>
On Wed, 2014-10-08 at 19:59 +0400, Sergei Shtylyov wrote:
> Hello.
>
> On 10/08/2014 06:53 PM, Masanari Iida wrote:
>
> > In commit 7bced397510ab569d31de4c70b39e13355046387,
>
> Please also specify that commit's summary line in parens.
Note that this information is useful for backports and bug fixes.
In this particular case (documentation), there is no chance we'll
backport this patch to any prior stable kernel
^ permalink raw reply
* Re: [PATCH] net: description of dma_cookie cause make xmldocs warning
From: Sergei Shtylyov @ 2014-10-08 15:59 UTC (permalink / raw)
To: Masanari Iida, linux-kernel, davem, netdev; +Cc: dan.j.williams
In-Reply-To: <1412780019-32475-1-git-send-email-standby24x7@gmail.com>
Hello.
On 10/08/2014 06:53 PM, Masanari Iida wrote:
> In commit 7bced397510ab569d31de4c70b39e13355046387,
Please also specify that commit's summary line in parens.
> dma_cookie was removed from struct skbuff.
> But the description of dma_cookie still exist.
> So the "make xmldocs" output following warning.
> Warning(.//include/linux/skbuff.h:609): Excess struct/union
> /enum/typedef member 'dma_cookie' description in 'sk_buff'
> Remove description of dma_cookie fix the symptom.
> Signed-off-by: Masanari Iida <standby24x7@gmail.com>
WBR, Sergei
^ permalink raw reply
* [PATCH net-next] net: add netdev_txq_bql_{enqueue,complete}_prefetchw() helpers
From: Eric Dumazet @ 2014-10-08 15:19 UTC (permalink / raw)
To: Jim Davis, David Miller; +Cc: Stephen Rothwell, linux-next, amirv, netdev
In-Reply-To: <1412779746.11091.176.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <edumazet@google.com>
Add two helpers so that drivers do not have to care of BQL being
available or not.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: Jim Davis <jim.epost@gmail.com>
Fixes: 29d40c903247 ("net/mlx4_en: Use prefetch in tx path")
---
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_tx.c b/drivers/net/ethernet/mellanox/mlx4/en_tx.c
index 8726a4aee5a7..34c137878545 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_tx.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_tx.c
@@ -392,7 +392,8 @@ static bool mlx4_en_process_tx_cq(struct net_device *dev,
if (!priv->port_up)
return true;
- prefetchw(&ring->tx_queue->dql.limit);
+ netdev_txq_bql_complete_prefetchw(ring->tx_queue);
+
index = cons_index & size_mask;
cqe = mlx4_en_get_cqe(buf, index, priv->cqe_size) + factor;
last_nr_txbb = ACCESS_ONCE(ring->last_nr_txbb);
@@ -737,7 +738,7 @@ netdev_tx_t mlx4_en_xmit(struct sk_buff *skb, struct net_device *dev)
vlan_tag = vlan_tx_tag_get(skb);
- prefetchw(&ring->tx_queue->dql);
+ netdev_txq_bql_enqueue_prefetchw(ring->tx_queue);
/* Track current inflight packets for performance analysis */
AVG_PERF_COUNTER(priv->pstats.inflight_avg,
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 3a4315b39d20..afc0a9194de6 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -30,6 +30,7 @@
#include <linux/bug.h>
#include <linux/delay.h>
#include <linux/atomic.h>
+#include <linux/prefetch.h>
#include <asm/cache.h>
#include <asm/byteorder.h>
@@ -2480,6 +2481,34 @@ netif_xmit_frozen_or_drv_stopped(const struct netdev_queue *dev_queue)
return dev_queue->state & QUEUE_STATE_DRV_XOFF_OR_FROZEN;
}
+/**
+ * netdev_txq_bql_enqueue_prefetchw - prefetch bql data for write
+ * @dev_queue: pointer to transmit queue
+ *
+ * BQL enabled drivers might use this helper in their ndo_start_xmit(),
+ * to give appropriate hint to the cpu.
+ */
+static inline void netdev_txq_bql_enqueue_prefetchw(struct netdev_queue *dev_queue)
+{
+#ifdef CONFIG_BQL
+ prefetchw(&dev_queue->dql.num_queued);
+#endif
+}
+
+/**
+ * netdev_txq_bql_complete_prefetchw - prefetch bql data for write
+ * @dev_queue: pointer to transmit queue
+ *
+ * BQL enabled drivers might use this helper in their TX completion path,
+ * to give appropriate hint to the cpu.
+ */
+static inline void netdev_txq_bql_complete_prefetchw(struct netdev_queue *dev_queue)
+{
+#ifdef CONFIG_BQL
+ prefetchw(&dev_queue->dql.limit);
+#endif
+}
+
static inline void netdev_tx_sent_queue(struct netdev_queue *dev_queue,
unsigned int bytes)
{
^ permalink raw reply related
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