* Re: [PATCH] fcntl.h: Fix a typo
From: David Miller @ 2015-02-01 20:15 UTC (permalink / raw)
To: bart.vanassche; +Cc: sfr, netdev
In-Reply-To: <54CE16F9.7030706@sandisk.com>
From: Bart Van Assche <bart.vanassche@sandisk.com>
Date: Sun, 01 Feb 2015 13:07:21 +0100
> In the source file fs/fcntl.c and also in the fcntl() man page one
> can see that the FD_CLOEXEC flag can be manipulated via F_GETFD
> and F_SETFD. Update the comment in <fcntl.h> accordingly.
>
> Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com>
> Cc: Stephen Rothwell <sfr@canb.auug.org.au>
Netdev is not an appropriate mailing list for this patch, is it?
^ permalink raw reply
* Re: [PATCH] tun: orphan an skb on tx
From: David Miller @ 2015-02-01 20:19 UTC (permalink / raw)
To: dwmw2
Cc: mst, herbert, eric.dumazet, jan.kiszka, paul.moore, netdev,
linux-kernel, qemu-devel
In-Reply-To: <1422797630.11044.32.camel@infradead.org>
From: David Woodhouse <dwmw2@infradead.org>
Date: Sun, 01 Feb 2015 13:33:50 +0000
> Of course, now I'm looking closely at the path these packets take to
> leave the box, it starts to offend me that they're being passed up to
> userspace just to encrypt them (as DTLS or ESP) and then send them back
> down to the kernel on a UDP socket. The kernel already knows how to
> {en,de}crypt ESP, and do the sequence number checking on incoming
> packets.
It's funny, I thought we had an IPSEC stack....
^ permalink raw reply
* Re: [PATCH v2 3/3] netlabel: Less function calls in netlbl_mgmt_add_common() after error detection
From: David Miller @ 2015-02-01 20:30 UTC (permalink / raw)
To: elfring; +Cc: paul, netdev, linux-kernel, kernel-janitors, julia.lawall
In-Reply-To: <54CDFCDA.9010802@users.sourceforge.net>
When you post a new version of a patch within a series, you must repost
the entire series, not just the patch which is changing.
Thanks.
^ permalink raw reply
* Re: [PATCH v2 00/11] hso: fix some problems in the disconnect path
From: David Miller @ 2015-02-01 20:33 UTC (permalink / raw)
To: olivier-Ui3EtX6WB9GzQB+pC5nmwQ
Cc: j.dumon-x9gZzRpC1QbQT0dZR+AlfA, dcbw-H+wXaHxf7aLQT0dZR+AlfA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1422620523-15021-1-git-send-email-olivier-Ui3EtX6WB9GzQB+pC5nmwQ@public.gmane.org>
From: Olivier Sobrie <olivier-Ui3EtX6WB9GzQB+pC5nmwQ@public.gmane.org>
Date: Fri, 30 Jan 2015 13:21:52 +0100
> These patches attempt to fix some problems I observed when the hso
> device is disconnected.
> Several patches of this serie are fixing crashes or memleaks when a
> hso device is disconnected.
> This serie of patches is based on v3.18.
>
> changes in v2:
> - Last patch of the serie dropped since another patch fix the issue.
> See http://marc.info/?l=linux-usb&m=142186699418489 for more info.
>
> - Added an extra patch avoiding name conflicts for the rfkill interface.
Series applied to net-next, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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
* [patch] isdn: off by one in connect_res()
From: Dan Carpenter @ 2015-02-01 20:54 UTC (permalink / raw)
To: Armin Schindler; +Cc: Karsten Keil, netdev, kernel-janitors
The bug here is that we use "Reject" as the index into the cau_t[] array
in the else path. Since the cau_t[] has 9 elements if Reject == 9 then
we are reading beyond the end of the array.
My understanding of the code is that it's saying that if Reject is 1 or
too high then that's invalid and we should hang up.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
---
Please review this one a bit carefully. I think it's correct, but I'm
not terribly familiar with this code.
diff --git a/drivers/isdn/hardware/eicon/message.c b/drivers/isdn/hardware/eicon/message.c
index 0b38060..d7c2866 100644
--- a/drivers/isdn/hardware/eicon/message.c
+++ b/drivers/isdn/hardware/eicon/message.c
@@ -1474,7 +1474,7 @@ static byte connect_res(dword Id, word Number, DIVA_CAPI_ADAPTER *a,
add_ai(plci, &parms[5]);
sig_req(plci, REJECT, 0);
}
- else if (Reject == 1 || Reject > 9)
+ else if (Reject == 1 || Reject >= 9)
{
add_ai(plci, &parms[5]);
sig_req(plci, HANGUP, 0);
^ permalink raw reply related
* Re: [PATCH] tun: orphan an skb on tx
From: David Woodhouse @ 2015-02-01 21:29 UTC (permalink / raw)
To: David Miller
Cc: mst, herbert, eric.dumazet, jan.kiszka, netdev, linux-kernel,
qemu-devel
In-Reply-To: <20150201.121948.998046471405758397.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 2288 bytes --]
On Sun, 2015-02-01 at 12:19 -0800, David Miller wrote:
> From: David Woodhouse <dwmw2@infradead.org>
> Date: Sun, 01 Feb 2015 13:33:50 +0000
>
> > Of course, now I'm looking closely at the path these packets take to
> > leave the box, it starts to offend me that they're being passed up to
> > userspace just to encrypt them (as DTLS or ESP) and then send them back
> > down to the kernel on a UDP socket. The kernel already knows how to
> > {en,de}crypt ESP, and do the sequence number checking on incoming
> > packets.
>
> It's funny, I thought we had an IPSEC stack....
Right. But I'm trying to work out how we can sanely *use* that from a
VPN client.
The client normally sets up a tun device, configuring it with
appropriate IP addresses and routes by invoking vpnc-script or passing
the information back to NetworkManager. The client itself might not even
have root privs, in the NetworkManager case.
The initial authentication and connection are done over HTTPS, and
packets *can* be passed that way if they need to be. But obviously the
client *also* tries to set up a UDP data transport too — which is DTLS
in the case of Cisco AnyConnect, and ESP in UDP for Juniper.
If it *can* get communication over UDP, it'll use it. Otherwise it just
passes packets over the TCP connection. So it needs to dynamically set
up and tear down the ESP/DTLS tunnels as and when they are working.
Ideally we want it such that that packets routed to the tun device get
transparently encrypted and sent out on the UDP socket, and packets
received from UDP and successfully decrypted will appear to have arrived
on the tun device. The user may be manually tweaking the routing, or
setting up firewall/NAT/etc. on the tun device.
I can see how to set up an ESP in UDP tunnel such that it looks like the
packets are actually departing on the *physical* interface (which in
practice I suppose they are). But that's going to be fairly complex to
set up, and extremely non-intuitive and hard to manage for the user. To
the extent that I don't think it's actually deployable.
I really was looking for some way to push down something like an XFRM
state into the tun device and just say "shove them out here until I tell
you otherwise".
--
dwmw2
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5745 bytes --]
^ permalink raw reply
* [PATCH v3] net/fsl_pq_mdio: Document supported compatibles
From: Emil Medve @ 2015-02-01 21:58 UTC (permalink / raw)
To: scottwood, linuxppc-dev, devicetree, netdev; +Cc: Shruti Kanetkar, Emil Medve
From: Shruti Kanetkar <Kanetkar.Shruti@gmail.com>
The device tree binding(s) document has fallen out of sync with the
driver code. Update the list of supported devices to reflect current
driver capabilities
Change-Id: I440d8de2ee2d9c3b7b23e69b3da851cab18a4c9a
Signed-off-by: Shruti Kanetkar <Kanetkar.Shruti@gmail.com>
Signed-off-by: Emil Medve <Emilian.Medve@Freescale.com>
---
v3: Separated from the FMan MDIO dt/binding patchset http://patchwork.ozlabs.org/patch/370870
Documentation/devicetree/bindings/net/fsl-tsec-phy.txt | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt b/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt
index be6ea896..1e97532 100644
--- a/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt
+++ b/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt
@@ -8,7 +8,16 @@ of how to define a PHY.
Required properties:
- reg : Offset and length of the register set for the device
- compatible : Should define the compatible device type for the
- mdio. Currently, this is most likely to be "fsl,gianfar-mdio"
+ mdio. Currently supported strings/devices are:
+ - "fsl,gianfar-tbi"
+ - "fsl,gianfar-mdio"
+ - "fsl,etsec2-tbi"
+ - "fsl,etsec2-mdio"
+ - "fsl,ucc-mdio"
+ - "fsl,fman-mdio"
+ When device_type is "mdio", the following strings are also considered:
+ - "gianfar"
+ - "ucc_geth_phy"
Example:
--
2.2.2
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply related
* Re: Fwd: Throughput regression with `tcp: refine TSO autosizing`
From: Andrew McGregor @ 2015-02-01 23:34 UTC (permalink / raw)
To: dpreed
Cc: dstanley, Stig Thormodsrud, netdev, linux-wireless,
Jesper Dangaard Brouer, cerowrt-devel, Matt Mathis,
Derrick Pallas, Kathy Giori, Mahesh Paolini-Subramanya,
Jonathan Morton, Tim Shepard, Avery Pennarun
In-Reply-To: <1422801814.796219699@apps.rackspace.com>
[-- Attachment #1.1: Type: text/plain, Size: 9023 bytes --]
So far as I'm concerned, Minstrel is as widely adopted as we could want; it
could go further, but it doesn't need any help with that. It could be
better, however, and that's a fairly straightforward change. One of the
problems with rate selection is that the standard itself has a bit to say
on what rates to use for what packets, and what it says is braindead. So
if you want to be standards compliant you are also leaving quite a bit of
potential performance on the table.
I missed one item in my list of potential improvements: the most braindead
thing 802.11 has to say about rates is that broadcast and multicast packets
should be sent at 'the lowest basic rate in the current supported rate
set', which is really wasteful. There are a couple of ways of dealing with
this: one, ignore the standard and pick the rate that is most likely to get
the frame to as many neighbours as possible (by a scan of the Minstrel
tables). Or two, fan it out as unicast, which might well take less airtime
(due to aggregation) as well as being much more likely to be delivered,
since you get ACKs and retries by doing that.
As for the industry... sure, there are those forces, but then again there's
a non-trivial amount of influence in this audience.
On Mon, Feb 2, 2015 at 1:43 AM, <dpreed@reed.com> wrote:
> Just to clarify, managing queueing in a single access point WiFi network
> is only a small part of the problem of fixing the rapidly degrading
> performance of WiFi based systems. Similarly, mesh routing is only a small
> part of the problem with the scalability of cooperative meshes based on the
> WiFi MAC.
>
>
>
> So I don't disagree with work on queue management (which is not good in
> any commercial product).
>
>
>
> But Dave T has done some great talks on "fixing WiFi" that don't have to
> do with queueing very much at all.
>
>
>
> For example, rate selection for various packets is terrible. When you
> have nearly 1000:1 ratios of transmission rates and codes that are not
> backward compatible, there's a huge opportunity for improvement.
> Similarly, choice of frequency bandwidth and center frequency at each
> station offers huge opportunities for practical scalability of systems.
> Also, as we noted earlier, "handoff" from one next hop to another is a huge
> problem with performance in practical deployments (a factor of 10x at
> least, just in that).
>
>
>
> Propagation information is not used at all when 802.11 systems share a
> channel, even in single AP deployments, yet all stations can measure
> propagation quite accurately in their hardware.
>
>
>
> Finally, Listen-before-talk is highly wasteful for two reasons: 1) any
> random radio noise from other sources unnecessarily degrades communications
> (and in the 5.8 MHz band, the rule about "radar avoidance" requires
> treating very low level noise as a "signal to shut the net down by law",
> but there is a loophole if you can tell that it's not actually "radar" (the
> technique requires two or more stations to measure the same noise event,
> and if the power is significantly different - more than a few dB - then it
> can't possibly be due to a distant transmitter, and therefore can be
> ignored). 2) the transmitter cannot tell when the intended receiver will be
> perfectly able to decode the signal without interference with the station
> it hears (this second point is actually proven in theory in a paper by Jon
> Peha that argued against trivial "etiquettes" as a mechanism for sharing
> among uncooperative and non-interoperable stations).
>
>
>
> Dave T has discussed more, as have I in other venues.
>
>
>
> The reason no one is making progress on any of these particular issues is
> that there is no coordination at the "systems level" around creating rising
> tides that lift all boats in the WiFi-ish space. It's all about ripping
> the competition by creating stuff that can sell better than the other guys'
> stuff, and avoiding cooperation at all costs.
>
>
>
> I agree that, to the extent that managing queues in a single box or a
> single operating system doesn't require cooperation, it's much easier to
> get such things into the market. That's why CeroWRT has been as effective
> as it has been. But has Microsoft done anything at all about it? Do the
> better ECN signals that can arise from good queue management get used by
> the TCP endpoints, or for that matter UDP-based protocol endpoints?
>
>
>
> But the big wins in making WiFi better are going begging. As WiFi becomes
> more closed, as it will as the major Internet Access Providers and Gadget
> builders (Google, Apple) start excluding innovators in wireless from the
> market by closed, proprietary solutions, the problem WILL get worse. You
> won't be able to fix those problems at all. If you have a solution you
> will have to convince the oligopoly to even bother trying it.
>
>
>
> So, let me reiterate. The problem is not just "getting Minstrel adopted",
> though I have nothing against that as a subgoal. The problem is to find
> good systems-level answers, and to find a strategy to deliver those answers
> to a WiFi ecology that spans the planet, and where the marketing
> value-story focuses on things one can measure between two stations in a
> Faraday cage, and never on any systems-level issues.
>
>
>
>
>
> I personally think that things like promoting semi-closed, essentially
> proprietary ESSID-based bridged distribution systems as "good ideas" are
> counterproductive to this goal. But that's perhaps too radical for this
> crowd. It reminds me of Cisco's attempt to create a proprietary Internet
> technology with IOS, which fortunately was not the success Cisco hoped for,
> or Juniper would not have existed. Maybe IOS would have been a fine
> standard, but it would have killed the evolution of the Internet as we know
> it.
>
>
> On Sunday, February 1, 2015 5:47am, "Jonathan Morton" <
> chromatix99@gmail.com> said:
>
> Since this is going to be a big job, it's worth prioritising parts of it
> appropriately.
>
> Minstrel is probably already the single best feature of the Linux Wi-Fi
> stack. AFAIK it still outperforms any other rate selector we know about. So
> I don't consider improving it further to be a high priority, although that
> trick of using it as a sneaky random packet loss inducer is intriguing.
>
> Much more important and urgent is getting some form of functioning SQM
> closer to the hardware, where the information is. I don't think we need to
> get super fancy here to do some real good, in the same way that PIE is a
> major improvement over drop-tail. I'd settle for a variant of fq_codel that
> gets and uses information about whether the current packet request might be
> aggregated with the previous packet provided, and adjusts its choice of
> packet accordingly.
>
> At the same time, models would undoubtedly be useful to help test and
> repeatably demonstrate the advantages of both simple and more sophisticated
> solutions. Ns3 allows laying out a reasonably complex radio environment,
> which is great for this. To counter the prevalence of one-station Faraday
> cage tests in the industry, the simulated environments should represent
> realistic, challenging use cases:
>
> 1) the family home, with half a dozen client devices competing with
> several interference sources (Bluetooth, RC toys, microwave oven, etc).
> This is a relatively easy environment, representing the expected
> environment for consumer equipment.
>
> 2) the apartment block, with fewer clients per AP but lots of APs
> distributed throughout a large building. Walls and floors may provide
> valuable attenuation here - unless you're in Japan, where they can be
> notoriously thin.
>
> 3) the railway carriage, consisting of eighty passengers in a 20x3 m
> space, and roughly the same number of client devices. The uplink is 3G
> based and has some inherent latency. Add some Bluetooth for flavour, stir
> gently. This one is rather challenging, but there is scope to optimise AP
> antenna placement, and to scale the test down slightly by reducing seat
> occupancy.
>
> 4) the jumbo jet, consisting of several hundred passengers crammed in like
> sardines. The uplink has satellite latencies built in. Good luck.
>
> 5) the business hotel. Multiple APs will be needed to provide adequate
> coverage for this environment, which should encompass the rooms as well as
> lounge, conference and dining areas. Some visitors may bring their own APs,
> and the system must be able to cope with this without seriously degrading
> performance.
>
> 6) the trade conference. A large arena filled with thousands of people.
> Multiple APs required. Good luck.
>
> I also feel that ultimately we're going to have to get industry on board.
> Not just passively letting us play around as with ath9k, but actively
> taking note of our findings and implementing at least a few of our ideas
> themselves. Of course, tools, models and real-world results are likely to
> make that easier.
>
> - Jonathan Morton
>
[-- Attachment #1.2: Type: text/html, Size: 12890 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: [PATCH] brcmfmac: avoid duplicated suspend/resume operation
From: Fu, Zhonghui @ 2015-02-02 1:58 UTC (permalink / raw)
To: Arend van Spriel, Kalle Valo
Cc: Sergei Shtylyov, brudley, Franky Lin, meuleman, linville,
pieterpg, hdegoede, wens, linux-wireless, brcm80211-dev-list,
netdev, linux-kernel@vger.kernel.org
In-Reply-To: <54C723A3.8000508@linux.intel.com>
On 2015/1/27 13:35, Fu, Zhonghui wrote:
> On 2015/1/24 2:09, Arend van Spriel wrote:
>> On 01/23/15 16:29, Kalle Valo wrote:
>>> Arend van Spriel<arend@broadcom.com> writes:
>>>
>>>> On 01/22/15 14:54, Sergei Shtylyov wrote:
>>>>> Hello.
>>>>>
>>>>> On 1/22/2015 4:49 PM, Kalle Valo wrote:
>>>>>
>>>>>>>> From 04d3fa673897ca4ccbea6c76836d0092dba2484a Mon Sep 17 00:00:00 2001
>>>>>>> From: Zhonghui Fu<zhonghui.fu@linux.intel.com>
>>>>>>> Date: Tue, 20 Jan 2015 11:14:13 +0800
>>>>>>> Subject: [PATCH] brcmfmac: avoid duplicated suspend/resume operation
>>>>>>> WiFi chip has 2 SDIO functions, and PM core will trigger
>>>>>>> twice suspend/resume operations for one WiFi chip to do
>>>>>>> the same things. This patch avoid this case.
>>>>>>> Acked-by: Arend van Spriel<arend@broadcom.com>
>>>>>>> Acked-by: Sergei Shtylyov<sergei.shtylyov@cogentembedded.com>
>>>>>>> Acked-by: Kalle Valo<kvalo@codeaurora.org>
>>>>>>> Signed-off-by: Zhonghui Fu<zhonghui.fu@linux.intel.com>
>>>>>> I don't remember giving Acked-by to this (or for matter to anything for
>>>>>> a long time). What about Sergei or Arend?
>>>>> I haven't ACK'ed this patch either.
>>>> I did ACK the initial patch and felt it still valid for this 'V2' patch.
>>> Ok, thanks. So the patch is good, Zhonghui just needs to remove the two
>>> acked-by lines.
>> Indeed.
> I have removed the two acked-by lines and sent the new patch in another mail.
>
> Thanks,
> Zhonghui
What comments about the new patch? Can this new patch be accepted?
Thanks,
Zhonghui
>> Regards,
>> Arend
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-wireless" 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] Fixed TPACKET V3 to signal poll when block is closed rather than every packet
From: Guy Harris @ 2015-02-02 2:11 UTC (permalink / raw)
To: David Miller; +Cc: dan, netdev, linux-kernel
In-Reply-To: <20141222.154144.2133538994062884017.davem@davemloft.net>
On Dec 22, 2014, at 12:41 PM, David Miller <davem@davemloft.net> wrote:
> From: Dan Collins <dan@dcollins.co.nz>
> Date: Fri, 19 Dec 2014 16:49:25 +1300
>
>> Make TPACKET_V3 signal poll when block is closed rather than for every
>> packet. Side effect is that poll will be signaled when block retire
>> timer expires which didn't previously happen. Issue was visible when
>> sending packets at a very low frequency such that all blocks are retired
>> before packets are received by TPACKET_V3. This caused avoidable packet
>> loss. The fix ensures that the signal is sent when blocks are closed
>> which covers the normal path where the block is filled as well as the
>> path where the timer expires. The case where a block is filled without
>> moving to the next block (ie. all blocks are full) will still cause poll
>> to be signaled.
>>
>> Signed-off-by: Dan Collins <dan@dcollins.co.nz>
>
> Applied, thanks.
Should this be applied to any of the stable kernel branches? The old behavior is the source of some libpcap/tcpdump/etc. complaints; see, for example, the thread that included
http://marc.info/?l=linux-netdev&m=140713966510035&w=2
^ permalink raw reply
* [PATCHv2 net] net: restore lro after device detached from bridge
From: Fan Du @ 2015-02-02 2:20 UTC (permalink / raw)
To: Alexander Duyck; +Cc: Fan Du, bhutchings, davem, netdev
In-Reply-To: <54CBEE24.8000603@redhat.com>
于 2015年01月31日 04:48, Alexander Duyck 写道:
> On 01/30/2015 04:33 AM, Fan Du wrote:
>> Either detaching a device from bridge or switching a device
>> out of FORWARDING state, the original lro feature should
>> possibly be enabled for good reason, e.g. hw feature like
>> receive side coalescing could come into play.
>>
>> BEFORE:
>> echo 1 > /proc/sys/net/ipv4/conf/ens806f0/forwarding && ethtool -k ens806f0 | grep large
>> large-receive-offload: off
>>
>> echo 0 > /proc/sys/net/ipv4/conf/ens806f0/forwarding && ethtool -k ens806f0 | grep large
>> large-receive-offload: off
>>
>> AFTER:
>> echo 1 > /proc/sys/net/ipv4/conf/ens806f0/forwarding && ethtool -k ens806f0 | grep large
>> large-receive-offload: off
>>
>> echo 0 > /proc/sys/net/ipv4/conf/ens806f0/forwarding && ethtool -k ens806f0 | grep large
>> large-receive-offload: on
>>
>> Signed-off-by: Fan Du <fan.du@intel.com>
>> Fixes: 0187bdfb0567 ("net: Disable LRO on devices that are forwarding")
>
> First off this isn't a "fix". This is going to likely break more than
> it fixes. The main reason why LRO is disabled is because it can cause
> more harm then it helps. Since GRO is available we should err on the
> side of caution since enabling LRO/RSC can have undesirable side effects
> in a number of cases.
I think you are talking about bad scenarios when net device is attached to a bridge.
Then what's the good reason user has to pay extra cpu power for using GRO, instead
of using hw capable LRO/RSC when this net device is detached from bridge acting as
a standalone NIC?
Note, SRC is defaulted to *ON* in practice for ALL ixgbe NICs, as same other RSC capable
NICs. Attaching net device to a bridge _once_ should not changed its default configuration,
moreover it's a subtle change without any message that user won't noticed at all.
From 1e76b2625b3e6aa239b5ef8399fe441a587c6646 Mon Sep 17 00:00:00 2001
From: Fan Du <fan.du@intel.com>
Date: Mon, 2 Feb 2015 05:02:11 -0500
Subject: [PATCH] net: restore lro after device detached from bridge
When detached net device from a bridge, the original lro
feature should possibly be enabled for good reason, e.g.
hw feature like receive side coalescing could come into play.
Signed-off-by: Fan Du <fan.du@intel.com>
Fixes: 0187bdfb0567 ("net: Disable LRO on devices that are forwarding")
---
ChangeLog:
v2:
- Restore lro only when device detached from bridge
---
include/linux/netdevice.h | 1 +
net/bridge/br_if.c | 1 +
net/core/dev.c | 23 +++++++++++++++++++++++
3 files changed, 25 insertions(+)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 642d426..904b1a4 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -2153,6 +2153,7 @@ int dev_alloc_name(struct net_device *dev, const char *name);
int dev_open(struct net_device *dev);
int dev_close(struct net_device *dev);
void dev_disable_lro(struct net_device *dev);
+void dev_enable_lro(struct net_device *dev);
int dev_loopback_xmit(struct sk_buff *newskb);
int dev_queue_xmit(struct sk_buff *skb);
int dev_queue_xmit_accel(struct sk_buff *skb, void *accel_priv);
diff --git a/net/bridge/br_if.c b/net/bridge/br_if.c
index 81e49fb..4236f3a 100644
--- a/net/bridge/br_if.c
+++ b/net/bridge/br_if.c
@@ -565,6 +565,7 @@ int br_del_if(struct net_bridge *br, struct net_device *dev)
call_netdevice_notifiers(NETDEV_CHANGEADDR, br->dev);
netdev_update_features(br->dev);
+ dev_enable_lro(dev);
return 0;
}
diff --git a/net/core/dev.c b/net/core/dev.c
index 1e325ad..76f2ed7 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1451,6 +1451,29 @@ void dev_disable_lro(struct net_device *dev)
}
EXPORT_SYMBOL(dev_disable_lro);
+/**
+ * dev_enable_lro - enable Large Receive Offload on a device
+ * @dev: device
+ *
+ * Enable Large Receive Offload (LRO) on a net device.
+ * This is needed if device is not attached to a bridge.
+ */
+void dev_enable_lro(struct net_device *dev)
+{
+ struct net_device *lower_dev;
+ struct list_head *iter;
+
+ dev->wanted_features |= NETIF_F_LRO;
+ netdev_update_features(dev);
+
+ if (unlikely(!(dev->features & NETIF_F_LRO)))
+ netdev_WARN(dev, "failed to enable LRO!\n");
+
+ netdev_for_each_lower_dev(dev, lower_dev, iter)
+ dev_enable_lro(lower_dev);
+}
+EXPORT_SYMBOL(dev_enable_lro);
+
static int call_netdevice_notifier(struct notifier_block *nb, unsigned long val,
struct net_device *dev)
{
--
1.8.3.1
> As far as the rest of the patch I have serious misgivings as this is
> going to be switching on LRO in multiple cases so if the user disables
> it they will find it was re-enabled when they likely weren't expecting
> it. LRO/RSC has a history of causing issues in a number of different
> cases. I'd say if it is off leave it off. If the user really wants to
> enable it they can do so via the ethtool interface that is already
> provided in the kernel after they have removed the interface from the
> bridge, or disabled IP routing.
>
> Leaving it disabled would be consistent with how it is handled in
> ixgbe_fix_features when Rx checksum offload is disabled. We just
> disable the feature and expect the user to re-enable it when they
> re-enable Rx checksum offload. The same logic should apply here. The
> user put the hardware in this state, it is the responsibility of the
> user to sort out the side effects of disabled features after they revert
> to their original state.
>> ---
>> include/linux/netdevice.h | 1 +
>> net/bridge/br_if.c | 1 +
>> net/core/dev.c | 24 ++++++++++++++++++++++++
>> net/ipv4/devinet.c | 4 ++++
>> net/ipv6/addrconf.c | 2 ++
>> 5 files changed, 32 insertions(+)
>>
>> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
>> index 642d426..904b1a4 100644
>> --- a/include/linux/netdevice.h
>> +++ b/include/linux/netdevice.h
>> @@ -2153,6 +2153,7 @@ int dev_alloc_name(struct net_device *dev, const char *name);
>> int dev_open(struct net_device *dev);
>> int dev_close(struct net_device *dev);
>> void dev_disable_lro(struct net_device *dev);
>> +void dev_enable_lro(struct net_device *dev);
>> int dev_loopback_xmit(struct sk_buff *newskb);
>> int dev_queue_xmit(struct sk_buff *skb);
>> int dev_queue_xmit_accel(struct sk_buff *skb, void *accel_priv);
>> diff --git a/net/bridge/br_if.c b/net/bridge/br_if.c
>> index 81e49fb..4236f3a 100644
>> --- a/net/bridge/br_if.c
>> +++ b/net/bridge/br_if.c
>> @@ -565,6 +565,7 @@ int br_del_if(struct net_bridge *br, struct net_device *dev)
>> call_netdevice_notifiers(NETDEV_CHANGEADDR, br->dev);
>> netdev_update_features(br->dev);
>> + dev_enable_lro(dev);
>> return 0;
>> }
>
> Removing an interface from a bridge should not be grounds for turning on LRO/RSC.
>
>> diff --git a/net/core/dev.c b/net/core/dev.c
>> index 1e325ad..938d7f6 100644
>> --- a/net/core/dev.c
>> +++ b/net/core/dev.c
>> @@ -1451,6 +1451,30 @@ void dev_disable_lro(struct net_device *dev)
>> }
>> EXPORT_SYMBOL(dev_disable_lro);
>> +/**
>> + * dev_enable_lro - enable Large Receive Offload on a device
>> + * @dev: device
>> + *
>> + * Enable Large Receive Offload (LRO) on a net device. Must be
>> + * called under RTNL. This is needed if device is not attached
>> + * to a bridge, or user change the forwarding state.
>> + */
>> +void dev_enable_lro(struct net_device *dev)
>> +{
>> + struct net_device *lower_dev;
>> + struct list_head *iter;
>> +
>> + dev->wanted_features |= NETIF_F_LRO;
>> + netdev_update_features(dev);
>> +
>> + if (unlikely(!(dev->features & NETIF_F_LRO)))
>> + netdev_WARN(dev, "failed to enable LRO!\n");
>> +
>> + netdev_for_each_lower_dev(dev, lower_dev, iter)
>> + dev_enable_lro(lower_dev);
>> +}
>> +EXPORT_SYMBOL(dev_enable_lro);
>> +
>> static int call_netdevice_notifier(struct notifier_block *nb, unsigned long val,
>> struct net_device *dev)
>> {
>> diff --git a/net/ipv4/devinet.c b/net/ipv4/devinet.c
>> index 214882e..3307196 100644
>> --- a/net/ipv4/devinet.c
>> +++ b/net/ipv4/devinet.c
>> @@ -1956,6 +1956,8 @@ static void inet_forward_change(struct net *net)
>> struct in_device *in_dev;
>> if (on)
>> dev_disable_lro(dev);
>> + else
>> + dev_enable_lro(dev);
>> rcu_read_lock();
>> in_dev = __in_dev_get_rcu(dev);
>> if (in_dev) {
>
> Disabling it due to a feature conflict makes sense. Enabling it after disabling forwarding not so much. If the user disabled it prior to enabling forwarding it should stay disabled, not be enabled.
>
>> @@ -2047,6 +2049,8 @@ static int devinet_sysctl_forward(struct ctl_table *ctl, int write,
>> container_of(cnf, struct in_device, cnf);
>> if (*valp)
>> dev_disable_lro(idev->dev);
>> + else
>> + dev_enable_lro(idev->dev);
>> inet_netconf_notify_devconf(net,
>> NETCONFA_FORWARDING,
>> idev->dev->ifindex,
>> diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
>> index f7c8bbe..4c3b54c 100644
>> --- a/net/ipv6/addrconf.c
>> +++ b/net/ipv6/addrconf.c
>> @@ -669,6 +669,8 @@ static void dev_forward_change(struct inet6_dev *idev)
>> dev = idev->dev;
>> if (idev->cnf.forwarding)
>> dev_disable_lro(dev);
>> + else
>> + dev_enable_lro(dev);
>> if (dev->flags & IFF_MULTICAST) {
>> if (idev->cnf.forwarding) {
>> ipv6_dev_mc_inc(dev, &in6addr_linklocal_allrouters);
>
> Same applies here.
>
> If anything this patch seems like more of a feature request then a fix. It would likely create a desirable effect for some, but have some undesirable side-effects for other users.
>
> - Alex
^ permalink raw reply related
* linux-next: manual merge of the net-next tree with the net tree
From: Stephen Rothwell @ 2015-02-02 2:33 UTC (permalink / raw)
To: David Miller, netdev
Cc: linux-next, linux-kernel, Nicolas Dichtel, Thomas Graf
[-- Attachment #1: Type: text/plain, Size: 1397 bytes --]
Hi all,
Today's linux-next merge of the net-next tree got a conflict in
drivers/net/vxlan.c between commit 33564bbb2cf1 ("vxlan: setup the
right link netns in newlink hdlr") from the net tree and commit
ac5132d1a03f ("vxlan: Only bind to sockets with compatible flags
enabled") from the net-next tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc drivers/net/vxlan.c
index a8c755dcab14,31bac2a21ce3..000000000000
--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@@ -2557,8 -2761,19 +2761,19 @@@ static int vxlan_newlink(struct net *sr
nla_get_u8(data[IFLA_VXLAN_UDP_ZERO_CSUM6_RX]))
vxlan->flags |= VXLAN_F_UDP_ZERO_CSUM6_RX;
+ if (data[IFLA_VXLAN_REMCSUM_TX] &&
+ nla_get_u8(data[IFLA_VXLAN_REMCSUM_TX]))
+ vxlan->flags |= VXLAN_F_REMCSUM_TX;
+
+ if (data[IFLA_VXLAN_REMCSUM_RX] &&
+ nla_get_u8(data[IFLA_VXLAN_REMCSUM_RX]))
+ vxlan->flags |= VXLAN_F_REMCSUM_RX;
+
+ if (data[IFLA_VXLAN_GBP])
+ vxlan->flags |= VXLAN_F_GBP;
+
- if (vxlan_find_vni(net, vni, use_ipv6 ? AF_INET6 : AF_INET,
+ if (vxlan_find_vni(src_net, vni, use_ipv6 ? AF_INET6 : AF_INET,
- vxlan->dst_port)) {
+ vxlan->dst_port, vxlan->flags)) {
pr_info("duplicate VNI %u\n", vni);
return -EEXIST;
}
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* RE: [PATCH net-next 1/7] r8152: adjust rx_bottom
From: Hayes Wang @ 2015-02-02 2:38 UTC (permalink / raw)
To: David Miller
Cc: netdev@vger.kernel.org, nic_swsd, linux-kernel@vger.kernel.org,
linux-usb@vger.kernel.org
In-Reply-To: <0835B3720019904CB8F7AA43166CEEB2EE77A2@RTITMBSV03.realtek.com.tw>
> David Miller [mailto:davem@davemloft.net]
> > Sent: Sunday, January 25, 2015 2:44 PM
> > What keeps rtl_start_rx() from running in parallel with
> > r8152_submit_rx(), or any other accessor of the RX agg->list?
>
> Forgive my poor English. I would try to describe them clearly.
> The steps about the rx agg->list would be
> 1. carrier on or autoresume occurs.
> 2. Call rtl_start_rx().
> 3. Rx agg->list flows between device and tp->rx_done.
> 4. carrier off or autosuspend occurs.
> 5. call rtl_stop_rx().
>
> The rtl_start_rx() would only be called when the linking
> status is changed from off to on or the auto resume occurs.
> And rtl_start_rx() would reinitialize the tp->rx_done and
> all of the rx agg->list. After step 2, the rx agg->list
> would flow between the usb host controller and the driver.
> If r8152_submit_rx() is success, the driver wouldn't own the
> rx agg->list until it is returned from the usb host controller.
> If r8152_submit_rx() is fail, the driver would still own the
> rx agg->list, and queue it to the tp->rx_done with spin lock
> for next try.
>
> If the status stays in step 3, only the rx_bottom() would submit
> the rx agg. The rtl_start_rx() wouldn't be called suddenly,
> unless the linking down or auto suspend occur first and linking
> on or auto resume occur again. If linking down or auto suspend
> occur, rtl_stop_rx() would be called (step 5). After this step,
> rx_bottom() wouldn't submit rx, and all rx agg->list would stop
> flowing. That is, the tp->rx_done and all rx agg->list wouldn't
> be changed until the next rtl_start_rx() is called.
>
> Therefore, the flow for each rx agg->list would be
> a. submittd by rtl_start_rx().
> b. goto step c if success, otherwise goto step d.
> c. completed by usb host controller.
> d. queued to tp->rx_done with spin lock.
> e. dequeue from tp->rx_done with spin lock by rx_botoom().
> f. goto step i if link down, otherwise goto step g.
> g. submitted by rx_botoom().
> h. goto step b.
> i. goto step a if link on.
>
> And the patch change the step g to g1.
> g1. submitted by rx_botoom() if (!ret), otherwise goto step d.
Excuse me. Any other question or suggestion for this patch?
Best Regards,
Hayes
^ permalink raw reply
* linux-next: manual merge of the net-next tree with the net tree
From: Stephen Rothwell @ 2015-02-02 2:40 UTC (permalink / raw)
To: David Miller, netdev, Toshiaki Makita, Jiri Pirko
Cc: linux-next, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 516 bytes --]
Hi all,
Today's linux-next merge of the net-next tree got a conflict in
include/linux/if_vlan.h between commit d4bcef3fbe88 ("net: Fix
vlan_get_protocol for stacked vlan") from the net tree and commit
df8a39defad4 ("net: rename vlan_tx_* helpers since "tx" is misleading
there") from the net-next tree.
I fixed it up (the former removed the code modified by the latter) and
can carry the fix as necessary (no action is required).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [Cerowrt-devel] Fwd: Throughput regression with `tcp: refine TSO autosizing`
From: Avery Pennarun @ 2015-02-02 4:04 UTC (permalink / raw)
To: Andrew McGregor
Cc: David Reed, Jonathan Morton, Dave Taht, Matt Mathis, Tim Shepard,
dstanley-lTB0Xd325TxqO0yjgLDq5wC/G2K4zDHf, Kathy Giori,
Stig Thormodsrud, Derrick Pallas,
cerowrt-devel-JXvr2/1DY2fm6VMwtOF2vx4hnT+Y9+D1@public.gmane.org,
Mahesh Paolini-Subramanya, Jim Gettys, Jesper Dangaard Brouer,
linux-wireless, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <CAA_e5Z5PfimZeC5cqSk_xFpKOBeZ74htLeEdwtKieAYWJaEX+A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Sun, Feb 1, 2015 at 6:34 PM, Andrew McGregor <andrewmcgr-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> I missed one item in my list of potential improvements: the most braindead
> thing 802.11 has to say about rates is that broadcast and multicast packets
> should be sent at 'the lowest basic rate in the current supported rate set',
> which is really wasteful. There are a couple of ways of dealing with this:
> one, ignore the standard and pick the rate that is most likely to get the
> frame to as many neighbours as possible (by a scan of the Minstrel tables).
> Or two, fan it out as unicast, which might well take less airtime (due to
> aggregation) as well as being much more likely to be delivered, since you
> get ACKs and retries by doing that.
As far as I can see, the only sensible thing to do with
multicast/broadcast is some variation of the unicast fanout, unless
you've got a truly huge number of nodes. I don't know of any
protocols (certainly not video streams) that actually work well with
the kind of packet loss you see at medium/long range with wifi if
retransmits aren't used. I've heard that openwrt already has a patch
included that does this kind of fanout at the bridge layer.
I've also heard of a new "reliable multicast" in some newer 802.11
variant, which essentially sends out a single multicast packet and
expects an ACK from each intended recipient. Other than adding
complexity, it seems like the best of both worlds.
--
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: [Cerowrt-devel] Fwd: Throughput regression with `tcp: refine TSO autosizing`
From: Avery Pennarun @ 2015-02-02 4:21 UTC (permalink / raw)
To: David Reed
Cc: Jonathan Morton, Dave Taht, Matt Mathis, Tim Shepard, dstanley,
Kathy Giori, Stig Thormodsrud, Derrick Pallas,
cerowrt-devel@lists.bufferbloat.net, Mahesh Paolini-Subramanya,
Jim Gettys, Andrew McGregor, Jesper Dangaard Brouer,
linux-wireless, netdev
In-Reply-To: <1422801814.796219699@apps.rackspace.com>
On Sun, Feb 1, 2015 at 9:43 AM, <dpreed@reed.com> wrote:
> Just to clarify, managing queueing in a single access point WiFi network is
> only a small part of the problem of fixing the rapidly degrading performance
> of WiFi based systems.
Can you explain what you mean by "rapidly degrading?" The performance
in odd situations is certainly not inspirational, but I haven't
noticed it getting worse over time.
> Similarly, mesh routing is only a small part of the
> problem with the scalability of cooperative meshes based on the WiFi MAC.
That's certainly true. Not to say the mesh routing algorithms are
much good either.
> Also, as we noted
> earlier, "handoff" from one next hop to another is a huge problem with
> performance in practical deployments (a factor of 10x at least, just in
> that).
While there is definitely some work to be done in handoff, it seems
like there are some find implementations of this already in existence.
Several brands of "enterprise access point" setups seem to do well at
this. It would be nice if they interoperated, I guess.
The fact that there's no open source version of this kind of handoff
feature bugs me, but we are working on it here and the work is all
planned to be open source, for example: (very early version)
https://gfiber.googlesource.com/vendor/google/platform/+/master/waveguide/
> Propagation information is not used at all when 802.11 systems share a
> channel, even in single AP deployments, yet all stations can measure
> propagation quite accurately in their hardware.
802.11k seems to provide for sharing this information. But I'm not
clear what I should use it for. :)
> Finally, Listen-before-talk is highly wasteful for two reasons: 1) any
> random radio noise from other sources unnecessarily degrades communications [...]
> 2) the transmitter cannot tell when the intended receiver will be perfectly
> able to decode the signal without interference with the station it hears
> (this second point is actually proven in theory in a paper by Jon Peha that
> argued against trivial "etiquettes" as a mechanism for sharing among
> uncooperative and non-interoperable stations).
I've thought quite a bit about your point #2 above, but I don't know
which direction to pursue. The idea is that sometimes "just shout
over the background noise" is a globally optimal solution, right? The
question seems to be to figure out when that is true and when it
isn't.
> I agree that, to the extent that managing queues in a single box or a single
> operating system doesn't require cooperation, it's much easier to get such
> things into the market. That's why CeroWRT has been as effective as it has
> been. But has Microsoft done anything at all about it? Do the better ECN
> signals that can arise from good queue management get used by the TCP
> endpoints, or for that matter UDP-based protocol endpoints?
If we don't know the answer to the questions, then that is itself the
problem. It's a lot easier to say, hey, ChromeOS and MacOS have good
network performance but Microsoft has bad network performance, if it's
true and we have good reproducible tests to demonstrate that.
> The reason no one is making progress on any of these particular issues is
> that there is no coordination at the "systems level" around creating rising
> tides that lift all boats in the WiFi-ish space. It's all about ripping the
> competition by creating stuff that can sell better than the other guys'
> stuff, and avoiding cooperation at all costs.
> [...]
> But the big wins in making WiFi better are going begging. As WiFi becomes
> more closed, as it will as the major Internet Access Providers and Gadget
> builders (Google, Apple) start excluding innovators in wireless from the
> market by closed, proprietary solutions, the problem WILL get worse. You
> won't be able to fix those problems at all. If you have a solution you will
> have to convince the oligopoly to even bother trying it.
As someone who works at Google Fiber (which is both a gadget maker and
an ISP) and who pushes all day long for our wifi stuff to be open
source, I'm slightly offended to be lumped in with other vendors in
your story :) I think the ChromeOS team (which insists on only open
source wifi drivers in all chromebooks) would feel similarly. We are
lucky to have defined our competitive advantage as something other
than short-lived slight improvements in wifi that will soon be
wastefully duplicated by everyone else.
That said, I see what you mean about the general state of the
industry. The way to fix it is the way Linux always fixes it: make
the open source version so much better that building a proprietary
one, just to gather a small incremental advantage, is a huge waste of
time and effort. Work on minstrel and fq_codel go really far here.
> I personally think that things like promoting semi-closed, essentially
> proprietary ESSID-based bridged distribution systems as "good ideas" are
> counterproductive to this goal. But that's perhaps too radical for this
> crowd.
Not sure what you mean here. ESSID-based distribution systems seem
pretty well defined to me. The only proprietary part is the
decision-making process for assisted roaming (ie. the "inter-AP
protocol") which is only an optional performance optimization. There
really should be an open source version of this, and I'm in fact
feebly attempting to build one, but I don't feel like the world is
falling apart through not having it. You can build a bridged
multi-BSS ESSID today with plain out-of-the-box hostapd.
Have fun,
Avery
^ permalink raw reply
* Re: [PATCH] tun: orphan an skb on tx
From: David Miller @ 2015-02-02 5:07 UTC (permalink / raw)
To: dwmw2
Cc: herbert, eric.dumazet, mst, jan.kiszka, linux-kernel, qemu-devel,
netdev
In-Reply-To: <1422826183.11044.72.camel@infradead.org>
From: David Woodhouse <dwmw2@infradead.org>
Date: Sun, 01 Feb 2015 21:29:43 +0000
> I really was looking for some way to push down something like an XFRM
> state into the tun device and just say "shove them out here until I tell
> you otherwise".
People decided to use TUN and push VPN stuff back into userspace,
and there are repercussions for that decision.
I'm not saying this to be mean or whatever, but I was very
disappointed when userland IPSEC solutions using TUN started showing
up.
We might as well have not have implemented the IPSEC stack at all,
because as a result of the userland VPN stuff our IPSEC stack is
largely unused except by a very narrow group of users.
^ permalink raw reply
* Re: [PATCH bluetooth-next] ieee802154: cc2520: Fix space before , coding style issue
From: Marcel Holtmann @ 2015-02-02 5:10 UTC (permalink / raw)
To: Mohammad Jamal; +Cc: varkabhadram, alex.aring, linux-wpan, netdev, linux-kernel
In-Reply-To: <1422021327-18815-1-git-send-email-md.jamalmohiuddin@gmail.com>
Hi Mohammad,
> This patch removes the warnings (space before , ) shown by
> checkpatch.pl
>
> Signed-off-by: Mohammad Jamal <md.jamalmohiuddin@gmail.com>
> ---
> drivers/net/ieee802154/cc2520.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
patch has been applied to bluetooth-next tree.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH bluetooth-next] ieee802154: cc2520: Replace shift operations by BIT macro
From: Marcel Holtmann @ 2015-02-02 5:10 UTC (permalink / raw)
To: Mohammad Jamal; +Cc: varkabhadram, alex.aring, linux-wpan, netdev, linux-kernel
In-Reply-To: <1422021509-18877-1-git-send-email-md.jamalmohiuddin@gmail.com>
Hi Mohammad,
> This patch replaces the shifting operations by BIT macro
>
> Signed-off-by: Mohammad Jamal <md.jamalmohiuddin@gmail.com>
> ---
> drivers/net/ieee802154/cc2520.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
patch has been applied to bluetooth-next tree.
Regards
Marcel
^ permalink raw reply
* [PATCH] net: rocker: Change netdev names to include slot number
From: David Ahern @ 2015-02-02 6:03 UTC (permalink / raw)
To: netdev; +Cc: sfeldma, David Ahern
Currently, rocker devices are given eth%d names. If you have multiple
rocker devices it is difficult to easily correlate eth%d names to a
rocker device and port. Change the device name to sw + PCI slot
number + p + id (sw%dp%d). This makes the device names easier to
correlate. ie., Rather than eth0, ..., eth N (N = number of ports in
device) the ports get netdev names like sw5p0, ..., sw5pN.
Signed-off-by: David Ahern <dsahern@gmail.com>
---
drivers/net/ethernet/rocker/rocker.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/rocker/rocker.c b/drivers/net/ethernet/rocker/rocker.c
index 11f4ffcc113d..1d1cf84e6f47 100644
--- a/drivers/net/ethernet/rocker/rocker.c
+++ b/drivers/net/ethernet/rocker/rocker.c
@@ -4010,8 +4010,11 @@ static int rocker_probe_port(struct rocker *rocker, unsigned int port_number)
struct rocker_port *rocker_port;
struct net_device *dev;
int err;
+ char str[IFNAMSIZ];
- dev = alloc_etherdev(sizeof(struct rocker_port));
+ snprintf(str, sizeof(str), "sw%dp%%d", pdev->slot->number);
+ dev = alloc_netdev_mqs(sizeof(struct rocker_port),
+ str, NET_NAME_UNKNOWN, ether_setup, 1, 1);
if (!dev)
return -ENOMEM;
rocker_port = netdev_priv(dev);
--
1.9.3 (Apple Git-50)
^ permalink raw reply related
* Re: [PATCH v2 0/3] Restore UFO support to virtio_net devices
From: David Miller @ 2015-02-02 6:19 UTC (permalink / raw)
To: vyasevich; +Cc: eric.dumazet, mst, netdev, virtualization, hannes, ben
In-Reply-To: <1422646047-13168-1-git-send-email-vyasevic@redhat.com>
From: Vladislav Yasevich <vyasevich@gmail.com>
Date: Fri, 30 Jan 2015 14:27:24 -0500
> commit 3d0ad09412ffe00c9afa201d01effdb6023d09b4
> Author: Ben Hutchings <ben@decadent.org.uk>
> Date: Thu Oct 30 18:27:12 2014 +0000
>
> drivers/net: Disable UFO through virtio
>
> Turned off UFO support to virtio-net based devices due to issues
> with IPv6 fragment id generation for UFO packets. The issue
> was that IPv6 UFO/GSO implementation expects the fragment id
> to be supplied in skb_shinfo(). However, for packets generated
> by the VMs, the fragment id is not supplied which causes all
> IPv6 fragments to have the id of 0.
>
> The problem is that turning off UFO support on tap/macvtap
> as well as virtio devices caused issues with migrations.
> Migrations would fail when moving a vm from a kernel supporting
> expecting UFO to work to the newer kernels that disabled UFO.
>
> This series provides a partial solution to address the migration
> issue. The series allows us to track whether skb_shinfo()->ip6_frag_id
> has been set by treating value of 0 as unset.
> This lets GSO code to generate fragment ids if they are necessary
> (ex: packet was generated by VM or packet socket).
>
> Since v1:
> - Removed the skb bit and use value of 0 as tracker.
> - Used Eric's suggestion to set fragment id as 0x80000000 if id
> generation procedure yeilded a 0 result.
> - Consolidated ipv6 id genration code.
Series applied and queued up for -stable.
There was some trailing whitespace in patch #1, which I fixed up.
^ permalink raw reply
* Re: [PATCH net v2] net: ipv6: allow explicitly choosing optimistic addresses
From: Erik Kline @ 2015-02-02 6:20 UTC (permalink / raw)
To: Lorenzo Colitti; +Cc: netdev@vger.kernel.org, Hannes Frederic Sowa
In-Reply-To: <CAKD1Yr2LJT+rYwbKQMvMQFtSDTwQAHk5k__m22J=kx8eKxj1JA@mail.gmail.com>
On Thu, Jan 29, 2015 at 2:25 PM, Lorenzo Colitti <lorenzo@google.com> wrote:
> On Wed, Jan 28, 2015 at 9:03 PM, Erik Kline <ek@google.com> wrote:
>> if (ipv6_addr_equal(&ifp->addr, addr) &&
>> - !(ifp->flags&IFA_F_TENTATIVE) &&
>> + (!(ifp->flags&banned_flags) ||
>> + ifp->flags&IFA_F_OPTIMISTIC&~banned_flags) &&
>
> Is this if statement correct?
>
> The intent here is "if ifp has IFA_F_OPTIMISTIC set, then
> IFA_F_TENTATIVE is allowed, even if the caller explicitly banned
> IFA_F_TENTATIVE", right? Not "if ifp has IFA_F_OPTIMISTIC set, then
> any flags are allowed, even ones explicitly baned by the caller". For
> example, suppose that:
>
> banned_flags = IFA_F_SECONDARY
> ifp->flags = IFA_F_SECONDARY | IFA_F_OPTIMISTIC
>
> In that case, won't the if statement match ifp, even though it
> contains a flag that is explicitly banned?
Yep, true. It works for all existing inputs, but is not generally
future-proof. :(
I have a rewrite that explicitly defines the circumstances under which
optimistic would be considered ok in this check. If there are changes
in that definition in the future that one clause will need to be
updated accordingly.
Patch coming in minutes.
^ permalink raw reply
* Re: [PATCH net v2] net: ipv6: allow explicitly choosing optimistic addresses
From: Erik Kline @ 2015-02-02 6:21 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Hannes Frederic Sowa
In-Reply-To: <20150130.173151.820376779924109928.davem@davemloft.net>
On Sat, Jan 31, 2015 at 10:31 AM, David Miller <davem@davemloft.net> wrote:
>
> Erik, you have to address and respond to the feedback you received
> from Lorenzo Colitti.
>
> If you do not respond and handle that soon, I'm simply taking
> your patch out of my queue and you'll have to resubmit even
> if no changes are necessary.
>
> Thanks.
Ack.
I didn't get to it on Friday, nor was I able to get to the office on
the weekend, but I have coming in minutes.
Apologies,
-Erik
^ permalink raw reply
* [target:for-next 16/21] drivers/vhost/scsi.c:1081:5: sparse: symbol 'vhost_skip_iovec_bytes' was not declared. Should it be static?
From: kbuild test robot @ 2015-02-02 6:25 UTC (permalink / raw)
To: Nicholas Bellinger
Cc: kvm, Michael S. Tsirkin, netdev, linux-kernel, virtualization,
kbuild-all
tree: git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending.git for-next
head: 2936f1d4f3e8247bd519feba7892371d5e4c6603
commit: 105acf608f25d5e0d9fef669299a5438b7b114ee [16/21] vhost/scsi: Add ANY_LAYOUT vhost_skip_iovec_bytes helper
reproduce:
# apt-get install sparse
git checkout 105acf608f25d5e0d9fef669299a5438b7b114ee
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__
sparse warnings: (new ones prefixed by >>)
>> drivers/vhost/scsi.c:1081:5: sparse: symbol 'vhost_skip_iovec_bytes' was not declared. Should it be static?
drivers/vhost/scsi.c:969:1: warning: 'vhost_scsi_mapal' defined but not used [-Wunused-function]
vhost_scsi_mapal(struct tcm_vhost_cmd *cmd, int max_niov,
^
Please review and possibly fold the followup patch.
---
0-DAY kernel test infrastructure Open Source Technology Center
http://lists.01.org/mailman/listinfo/kbuild Intel Corporation
^ permalink raw reply
* [PATCH target] vhost/scsi: vhost_skip_iovec_bytes() can be static
From: kbuild test robot @ 2015-02-02 6:25 UTC (permalink / raw)
To: Nicholas Bellinger
Cc: kbuild-all, Michael S. Tsirkin, kvm, virtualization, netdev,
linux-kernel
In-Reply-To: <201502021411.KBLYtCzS%fengguang.wu@intel.com>
drivers/vhost/scsi.c:1081:5: sparse: symbol 'vhost_skip_iovec_bytes' was not declared. Should it be static?
Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
---
scsi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/vhost/scsi.c b/drivers/vhost/scsi.c
index d888bd9..8ac003f 100644
--- a/drivers/vhost/scsi.c
+++ b/drivers/vhost/scsi.c
@@ -1078,7 +1078,7 @@ vhost_scsi_send_bad_target(struct vhost_scsi *vs,
pr_err("Faulted on virtio_scsi_cmd_resp\n");
}
-int vhost_skip_iovec_bytes(size_t bytes, int max_niov,
+static int vhost_skip_iovec_bytes(size_t bytes, int max_niov,
struct iovec *iov_in, size_t off_in,
struct iovec **iov_out, size_t *off_out)
{
^ 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