* 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
* Re: [RFC][PATCHSET] more iov_iter conversion in net/*
From: David Miller @ 2015-02-02 6:26 UTC (permalink / raw)
To: viro; +Cc: netdev
In-Reply-To: <20150131035513.GK29656@ZenIV.linux.org.uk>
From: Al Viro <viro@ZenIV.linux.org.uk>
Date: Sat, 31 Jan 2015 03:55:13 +0000
> ->sendmsg() side of that business, now. By the end of it, we
> get all ->sendmsg() instances leaving iovec unchanged and ->msg_iter -
> drained.
...
> The pile after that one will be dealing with the kernel_sendmsg and
> kernel_recvmg callers - at that point we can start reaping benefits of
> consistent way ->msg_iter is handled. Note that after these changes if
> iov_iter_kvec() is used to initialize ->msg_iter, we don't need the games
> with get_fs()/set_fs() anymore; just sock_sendmsg()/sock_recvmsg() will do,
> so quite a few of those kernel_{send,recv}msg() callers will turn into
> sock_{send,recv}msg() ones.
The content of this series looks fine, but I really would like you
to put proper "subsystem: " prefixes into the commit log header
lines of these commits.
Patch 2 and 3 should use "ipv6: ", patch #4 should use whatever the
name of that device driver "vmw_vmci: " or similar, etc.
Thanks.
^ permalink raw reply
* Re: Is sch_teql still useful?
From: David Miller @ 2015-02-02 6:27 UTC (permalink / raw)
To: cwang; +Cc: jhs, netdev, stephen
In-Reply-To: <CAHA+R7NDfn705P0OrgpMfx7nbsNcHh-cXrPVQezG9WtH1Ya3Yg@mail.gmail.com>
From: Cong Wang <cwang@twopensource.com>
Date: Fri, 30 Jan 2015 20:23:32 -0800
> Since we have bonding alb, is it still needed to have sch_teql since
> they do the same thing, load balancing over multiple interfaces? Also
> sch_teql mixes netdevice with qdisc, which somewhat breaks the
> abstraction?
>
> I don't dig the history so I could easily miss something here.
I can't comment as to it's usefulness, but I will note that we don't
have the option of removing it if you are thinking about doing so.
^ permalink raw reply
* Re: [PATCH v2 0/3] Restore UFO support to virtio_net devices
From: David Miller @ 2015-02-02 6:28 UTC (permalink / raw)
To: vyasevich
Cc: netdev, virtualization, mst, ben, eric.dumazet, hannes, vyasevic
In-Reply-To: <20150201.221935.283572621026340671.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Sun, 01 Feb 2015 22:19:35 -0800 (PST)
> Series applied and queued up for -stable.
I have to revert, this breaks the build.
net/built-in.o: In function `udp6_ufo_fragment':
udp_offload.c:(.text+0x103380): undefined reference to `ipv6_select_ident'
^ permalink raw reply
* Re: [PATCH target] vhost/scsi: vhost_skip_iovec_bytes() can be static
From: Fam Zheng @ 2015-02-02 6:35 UTC (permalink / raw)
To: kbuild test robot
Cc: kvm, Michael S. Tsirkin, netdev, linux-kernel, virtualization,
kbuild-all
In-Reply-To: <20150202062521.GA18113@snb>
On Mon, 02/02 14:25, kbuild test robot wrote:
> 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)
Probably keep the parameter list lines aligned?
Fam
^ permalink raw reply
* Re: [PATCHv2 net-next] cxgb4: Remove preprocessor check for CONFIG_CXGB4_DCB
From: David Miller @ 2015-02-02 6:37 UTC (permalink / raw)
To: hariprasad; +Cc: netdev, leedom, anish, nirranjan, praveenm
In-Reply-To: <1422587967-18405-1-git-send-email-hariprasad@chelsio.com>
From: Hariprasad Shenai <hariprasad@chelsio.com>
Date: Fri, 30 Jan 2015 08:49:27 +0530
> In commit dc9daab226aa ("cxgb4: Added support in debugfs to dump
> sge_qinfo") a preprocessor check for CONFIG_CXGB4_DCB got added, which should
> have been CONFIG_CHELSIO_T4_DCB. After adding the right preprocessor, build
> fails due to missing function ethqset2pinfo. Fixing that as well.
>
> Reported-by: Paul Bolle <pebolle@tiscal.nl>
> Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com>
>
> V2: Updated description since the patch also fixes build failure
Applied, thanks.
^ permalink raw reply
* [PATCH net v3] net: ipv6: allow explicitly choosing optimistic addresses
From: Erik Kline @ 2015-02-02 6:39 UTC (permalink / raw)
To: netdev; +Cc: lorenzo, hannes, Erik Kline
RFC 4429 ("Optimistic DAD") states that optimistic addresses
should be treated as deprecated addresses. From section 2.1:
Unless noted otherwise, components of the IPv6 protocol stack
should treat addresses in the Optimistic state equivalently to
those in the Deprecated state, indicating that the address is
available for use but should not be used if another suitable
address is available.
Optimistic addresses are indeed avoided when other addresses are
available (i.e. at source address selection time), but they have
not heretofore been available for things like explicit bind() and
sendmsg() with struct in6_pktinfo, etc.
This change makes optimistic addresses treated more like
deprecated addresses than tentative ones.
Signed-off-by: Erik Kline <ek@google.com>
---
include/net/addrconf.h | 3 +++
net/ipv6/addrconf.c | 17 +++++++++++++++--
net/ipv6/ndisc.c | 4 +++-
3 files changed, 21 insertions(+), 3 deletions(-)
diff --git a/include/net/addrconf.h b/include/net/addrconf.h
index d13573b..80456f7 100644
--- a/include/net/addrconf.h
+++ b/include/net/addrconf.h
@@ -62,6 +62,9 @@ int addrconf_set_dstaddr(struct net *net, void __user *arg);
int ipv6_chk_addr(struct net *net, const struct in6_addr *addr,
const struct net_device *dev, int strict);
+int ipv6_chk_addr_and_flags(struct net *net, const struct in6_addr *addr,
+ const struct net_device *dev, int strict,
+ u32 banned_flags);
#if defined(CONFIG_IPV6_MIP6) || defined(CONFIG_IPV6_MIP6_MODULE)
int ipv6_chk_home_addr(struct net *net, const struct in6_addr *addr);
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index f7c8bbe..e9b795f 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -1519,6 +1519,14 @@ static int ipv6_count_addresses(struct inet6_dev *idev)
int ipv6_chk_addr(struct net *net, const struct in6_addr *addr,
const struct net_device *dev, int strict)
{
+ return ipv6_chk_addr_and_flags(net, addr, dev, strict, IFA_F_TENTATIVE);
+}
+EXPORT_SYMBOL(ipv6_chk_addr);
+
+int ipv6_chk_addr_and_flags(struct net *net, const struct in6_addr *addr,
+ const struct net_device *dev, int strict,
+ u32 banned_flags)
+{
struct inet6_ifaddr *ifp;
unsigned int hash = inet6_addr_hash(addr);
@@ -1526,8 +1534,13 @@ int ipv6_chk_addr(struct net *net, const struct in6_addr *addr,
hlist_for_each_entry_rcu(ifp, &inet6_addr_lst[hash], addr_lst) {
if (!net_eq(dev_net(ifp->idev->dev), net))
continue;
+ /* Permit optimistic addresses, but only under explicitly
+ * defined circumstances.
+ */
+ bool optimistic_ok = (ifp->flags & IFA_F_OPTIMISTIC) &&
+ (banned_flags == IFA_F_TENTATIVE);
if (ipv6_addr_equal(&ifp->addr, addr) &&
- !(ifp->flags&IFA_F_TENTATIVE) &&
+ (!(ifp->flags&banned_flags) || optimistic_ok) &&
(dev == NULL || ifp->idev->dev == dev ||
!(ifp->scope&(IFA_LINK|IFA_HOST) || strict))) {
rcu_read_unlock_bh();
@@ -1538,7 +1551,7 @@ int ipv6_chk_addr(struct net *net, const struct in6_addr *addr,
rcu_read_unlock_bh();
return 0;
}
-EXPORT_SYMBOL(ipv6_chk_addr);
+EXPORT_SYMBOL(ipv6_chk_addr_and_flags);
static bool ipv6_chk_same_addr(struct net *net, const struct in6_addr *addr,
struct net_device *dev)
diff --git a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c
index 6828667..113fc6c 100644
--- a/net/ipv6/ndisc.c
+++ b/net/ipv6/ndisc.c
@@ -655,7 +655,9 @@ static void ndisc_solicit(struct neighbour *neigh, struct sk_buff *skb)
struct in6_addr *target = (struct in6_addr *)&neigh->primary_key;
int probes = atomic_read(&neigh->probes);
- if (skb && ipv6_chk_addr(dev_net(dev), &ipv6_hdr(skb)->saddr, dev, 1))
+ if (skb && ipv6_chk_addr_and_flags(dev_net(dev), &ipv6_hdr(skb)->saddr,
+ dev, 1,
+ IFA_F_TENTATIVE|IFA_F_OPTIMISTIC))
saddr = &ipv6_hdr(skb)->saddr;
probes -= NEIGH_VAR(neigh->parms, UCAST_PROBES);
if (probes < 0) {
--
2.2.0.rc0.207.ga3a616c
^ permalink raw reply related
* RE: [PATCH net] hyperv: Fix the error processing in netvsc_send()
From: Jason Wang @ 2015-02-02 6:49 UTC (permalink / raw)
To: Haiyang Zhang
Cc: olaf@aepfle.de, netdev@vger.kernel.org,
driverdev-devel@linuxdriverproject.org,
linux-kernel@vger.kernel.org, davem@davemloft.net
In-Reply-To: <BN1PR0301MB0770FCDA58F3BC9E25382D95CA310@BN1PR0301MB0770.namprd03.prod.out look.com>
On Fri, Jan 30, 2015 at 11:05 PM, Haiyang Zhang
<haiyangz@microsoft.com> wrote:
>
>
>> -----Original Message-----
>> From: Jason Wang [mailto:jasowang@redhat.com]
>> Sent: Friday, January 30, 2015 5:25 AM
>> > + if (ret != 0) {
>> > + if (section_index != NETVSC_INVALID_INDEX)
>> > + netvsc_free_send_slot(net_device, section_index);
>>
>> What if ret is -EINVAL or -ENOSPC? Looks like we need free the skb
>> in
>> this case also.
>
> In these cases, skb is freed in netvsc_start_xmit().
>
>
>> >
>> > + } else if (skb) {
>> > + dev_kfree_skb_any(skb);
>>
>> The caller - netvsc_start_xmit() do this also, may be handle this in
>> caller is better since netvsc_start_xmit() is the only user that
>> tries
>> to send a skb?
>
> When the packet is sent out normally, we frees it in netvsc_send() if
> it's
> copied to send-buffer. The free is done in netvsc_send(), because the
> copy
> is also in this function. If it's not copied, it will be freed in
> another
> function -- netvsc_xmit_completion().
>
> netvsc_start_xmit() only does free skb in error case.
Ok.
>
>
>> btw, I find during netvsc_start_xmit(), ret was change to -ENOSPC
>> when
>> queue_sends[q_idx] < 1. But non of the caller check -ENOSPC in fact?
>
> In this case, we don't request re-send, so set ret to a value other
> than
> -EAGAIN.
Why not? We have available slots for it to be sent now. Dropping the
packet in this case may cause out of order sending.
> It's handled in the same way as errors != -EAGAIN, so we don't
> need to check this value specifically.
Thanks
^ permalink raw reply
* Re: [RFC][PATCHSET] more iov_iter conversion in net/*
From: Al Viro @ 2015-02-02 6:53 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20150201.222646.1280320067605385223.davem@davemloft.net>
On Sun, Feb 01, 2015 at 10:26:46PM -0800, David Miller wrote:
> From: Al Viro <viro@ZenIV.linux.org.uk>
> Date: Sat, 31 Jan 2015 03:55:13 +0000
>
> > ->sendmsg() side of that business, now. By the end of it, we
> > get all ->sendmsg() instances leaving iovec unchanged and ->msg_iter -
> > drained.
> ...
> > The pile after that one will be dealing with the kernel_sendmsg and
> > kernel_recvmg callers - at that point we can start reaping benefits of
> > consistent way ->msg_iter is handled. Note that after these changes if
> > iov_iter_kvec() is used to initialize ->msg_iter, we don't need the games
> > with get_fs()/set_fs() anymore; just sock_sendmsg()/sock_recvmsg() will do,
> > so quite a few of those kernel_{send,recv}msg() callers will turn into
> > sock_{send,recv}msg() ones.
>
> The content of this series looks fine, but I really would like you
> to put proper "subsystem: " prefixes into the commit log header
> lines of these commits.
>
> Patch 2 and 3 should use "ipv6: ", patch #4 should use whatever the
> name of that device driver "vmw_vmci: " or similar, etc.
Point... Are you OK with tcp_send_syn_data() change in 8/18? Basically,
tcp_sendmsg() treats short copy from userland as "send as much as we can,
stop at the first point where copy_from_user() fails", same as write(),
etc.; that much is unchanged, but the current mainline has a strange behaviour
in case when short copy happens within what would be packed into SYN packet -
if that happens, it still sends as much as possible, but it falls back to
separate SYN. With this patch it simply sends shorter SYN+data packet instead.
The reason I went that way is that I wanted to avoid copying the same data
from userland twice and it was easy to do; I can preserve the current mainline
behaviour, but it'll cost making a backup copy of ->msg_iter in
tcp_send_syn_data(), only to never use it in normal case *and* do piles
of extra work (extra packet to send, repeated copying from userland) in case
of short copy. Is there any reason not to combine SYN+data in case of short
copy? Again, we do send exact same data, return the same value, etc. - you
need tcpdump to see the difference.
Al, off to figure out the proper Cc: for all those commits, so that
git-send-email would DTRT - if I need to edit commit messages, might
as well do that at the same time...
^ permalink raw reply
* Re: [RFC][PATCHSET] more iov_iter conversion in net/*
From: David Miller @ 2015-02-02 7:05 UTC (permalink / raw)
To: viro; +Cc: netdev
In-Reply-To: <20150202065339.GU29656@ZenIV.linux.org.uk>
From: Al Viro <viro@ZenIV.linux.org.uk>
Date: Mon, 2 Feb 2015 06:53:39 +0000
> Point... Are you OK with tcp_send_syn_data() change in 8/18? Basically,
> tcp_sendmsg() treats short copy from userland as "send as much as we can,
> stop at the first point where copy_from_user() fails", same as write(),
> etc.; that much is unchanged, but the current mainline has a strange behaviour
> in case when short copy happens within what would be packed into SYN packet -
> if that happens, it still sends as much as possible, but it falls back to
> separate SYN. With this patch it simply sends shorter SYN+data packet instead.
> The reason I went that way is that I wanted to avoid copying the same data
> from userland twice and it was easy to do; I can preserve the current mainline
> behaviour, but it'll cost making a backup copy of ->msg_iter in
> tcp_send_syn_data(), only to never use it in normal case *and* do piles
> of extra work (extra packet to send, repeated copying from userland) in case
> of short copy. Is there any reason not to combine SYN+data in case of short
> copy? Again, we do send exact same data, return the same value, etc. - you
> need tcpdump to see the difference.
I think dropping down to plain SYN in the short copy case was just based
upon a blanket decision to not do SYN+DATA if anything out of the
ordinary happens, rathe than an explicit policy decision. So that change
should be OK.
^ permalink raw reply
* Re: [PATCH] ipv4: tcp: get rid of ugly unicast_sock
From: David Miller @ 2015-02-02 7:06 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1422596105.21689.66.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 29 Jan 2015 21:35:05 -0800
> From: Eric Dumazet <edumazet@google.com>
>
> In commit be9f4a44e7d41 ("ipv4: tcp: remove per net tcp_sock")
> I tried to address contention on a socket lock, but the solution
> I chose was horrible :
>
> commit 3a7c384ffd57e ("ipv4: tcp: unicast_sock should not land outside
> of TCP stack") addressed a selinux regression.
>
> commit 0980e56e506b ("ipv4: tcp: set unicast_sock uc_ttl to -1")
> took care of another regression.
>
> commit b5ec8eeac46 ("ipv4: fix ip_send_skb()") fixed another regression.
>
> commit 811230cd85 ("tcp: ipv4: initialize unicast_sock sk_pacing_rate")
> was another shot in the dark.
>
> Really, just use a proper socket per cpu, and remove the skb_orphan()
> call, to re-enable flow control.
>
> This solves a serious problem with FQ packet scheduler when used in
> hostile environments, as we do not want to allocate a flow structure
> for every RST packet sent in response to a spoofed packet.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied, thanks Eric.
^ permalink raw reply
* Re: Fwd: Throughput regression with `tcp: refine TSO autosizing`
From: David Lang @ 2015-02-02 7:07 UTC (permalink / raw)
To: Avery Pennarun
Cc: dstanley, Andrew McGregor, Stig Thormodsrud, netdev,
linux-wireless, Jesper Dangaard Brouer, Derrick Pallas,
Matt Mathis, cerowrt-devel@lists.bufferbloat.net, Jonathan Morton,
Mahesh Paolini-Subramanya, Kathy Giori, Tim Shepard
In-Reply-To: <CAPp0ZBa43kVBWN5iGgmW=-YQAkdm2DrmMN0URvVu=yXA-_TZCQ@mail.gmail.com>
On Sun, 1 Feb 2015, Avery Pennarun wrote:
> On Sun, Feb 1, 2015 at 9:43 AM, <dpreed@reed.com> wrote:
>> 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.
I will be running a fully opensource bridged ESSID system at SCaLE this month.
last year we had ~2500 people and devices with ~50 APs deployed, and it worked
well. The only problem was that I needed to deploy a few more APs to cover some
of the hallway areas more reliably.
There are tricks that the commercial systems pull that I can't currently
duplicate with opensource tools. But as Avery says, they are optimizations, not
something required for successful operation. It would be nice to get the
assisted roaming portion available. But it's not required.
David Lang
^ permalink raw reply
* Re: [PATCH v2] stmmac: DMA threshold mode or SF mode can be different among multiple device instance
From: David Miller @ 2015-02-02 7:14 UTC (permalink / raw)
To: sonic.adi; +Cc: peppe.cavallaro, netdev, adi-buildroot-devel, sonic.zhang
In-Reply-To: <1422596972-18559-1-git-send-email-sonic.adi@gmail.com>
From: Sonic Zhang <sonic.adi@gmail.com>
Date: Fri, 30 Jan 2015 13:49:32 +0800
> From: Sonic Zhang <sonic.zhang@analog.com>
>
> - In tx_hard_error_bump_tc interrupt, tc should be bumped only when current
> device instance is in DMA threshold mode. Check per device xstats.threshold
> other than global tc.
>
> - Set per device xstats.threshold to SF_DMA_MODE when current device
> instance is set to SF mode.
>
> v2-changes:
> - fix ident style
>
> Signed-off-by: Sonic Zhang <sonic.zhang@analog.com>
Applied to net-next, thanks.
^ permalink raw reply
* Re: [PATCH net-next v4 0/7] switchdev offload flags
From: David Miller @ 2015-02-02 7:16 UTC (permalink / raw)
To: roopa
Cc: jiri, sfeldma, jhs, bcrl, tgraf, john.fastabend, stephen,
vyasevic, ronen.arad, netdev, shm, gospo
In-Reply-To: <1422600017-42393-1-git-send-email-roopa@cumulusnetworks.com>
From: roopa@cumulusnetworks.com
Date: Thu, 29 Jan 2015 22:40:10 -0800
> This patch series introduces new offload flags for switchdev.
> Kernel network subsystems can use this flag to accelerate
> network functions by offloading to hw.
Series applied to net-next, thanks.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox