* Re: [Cerowrt-devel] Fwd: Throughput regression with `tcp: refine TSO autosizing`
From: Jim Gettys @ 2015-02-02 15:25 UTC (permalink / raw)
To: Avery Pennarun
Cc: Andrew McGregor, David Reed, Jonathan Morton, Dave Taht,
Matt Mathis, Tim Shepard, dstanley@arubanetworks.com, Kathy Giori,
Stig Thormodsrud, Derrick Pallas,
cerowrt-devel@lists.bufferbloat.net, Mahesh Paolini-Subramanya,
Jesper Dangaard Brouer, linux-wireless, netdev
In-Reply-To: <CAPp0ZBbKu-B3yPf0Et=XByJ1SrnxBgVbRXr9PBe0f6P08w87=Q@mail.gmail.com>
On Sun, Feb 1, 2015 at 11:04 PM, Avery Pennarun <apenwarr@google.com> wrote:
> On Sun, Feb 1, 2015 at 6:34 PM, Andrew McGregor <andrewmcgr@gmail.com> 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 gather some Windows drivers from some vendors do this unicast fanout
(claim made by one of their engineers in an early homenet meeting).
>
> 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.
So long as it times out in some very small, finite time. We don't
want a repeat of the infinite retry bugs Dave found in drivers a few
years back...
"Reliable multicast" ultimately is an oxymoron, particularly on a
medium with hundreds/one bandwidth variation. One remote low
bandwidth station cannot be allowed to drag the entire network to the
basement.
- Jim
^ permalink raw reply
* Re: [PATCH v3 3/3] stmmac: pci: add MSI support for Intel Quark X1000
From: Bryan O'Donoghue @ 2015-02-02 15:17 UTC (permalink / raw)
To: netdev, Kweh, Hock Leong, Andy Shevchenko, davem, Ahmad, Josef
Hi guys.
Has the issue with PVM masking been addressed ?
https://lkml.org/lkml/2014/10/1/221
If not then please drop MSIs from this patchset.
--
Bryan
^ permalink raw reply
* Re: [PATCH] tun: orphan an skb on tx
From: David Woodhouse @ 2015-02-02 15:30 UTC (permalink / raw)
To: Steffen Klassert
Cc: David Miller, mst, herbert, eric.dumazet, jan.kiszka, netdev,
linux-kernel, qemu-devel
In-Reply-To: <20150202082446.GR13046@secunet.com>
[-- Attachment #1: Type: text/plain, Size: 2005 bytes --]
On Mon, 2015-02-02 at 09:24 +0100, Steffen Klassert wrote:
>
> Maybe you want to use a virtual tunnel interface (vti) what we have
> already. Everything that is routed through such an interface is
> guaranteed to be either encrypted if a matching xfrm state is present
> or dropped. Same on the rceive side, everything that is received by
> this interface is guaranteed to be IPsec processed. So you can do
> a routing based decision about the IPsec processing.
>
> While I'm sure it could handle the ESP in UDP encapsulation, I'm not that
> sure about your TCP fallback because this requires a valid xfrm state
> to allow packets to pass. Using the same interface for both is probably
> not possible.
I'm trying to imagine how we could make it work in practice if we end up
exposing two *different* interfaces and having to change the kernel's
routing according to whether we have UDP connectivity at any given
moment in time.
Given how painful it already is to maintain vpnc-script and make it do
the right thing for split-include and split-exclude routing, I'm not
really sure I want to go there.
Even if we could get such a scheme to work, it would probably also
require retaining root privileges to make the changes — and one of the
security benefits over the proprietary VPN clients is that we don't
*need* to run as root. We can either drop privs after running
vpnc-script to do the initial routing setup, or in the NetworkManager
case we *never* run with elevated privileges; we just pass the
IP/routing information back over DBus to NetworkManager.
It occurs to me that for the approach I was thinking about, I wouldn't
even need to touch the internals of the tun driver. It could be a
separate driver which just uses tun_get_socket(). Userspace could hand
it the file descriptors of the tun device and the connected UDP socket,
along with the encryption parameters — and then just stop reading
packets from the tun device for itself.
--
dwmw2
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5745 bytes --]
^ permalink raw reply
* Re: [PATCH] net: ipv6: Make address flushing on ifdown optional - v2
From: David Ahern @ 2015-02-02 15:33 UTC (permalink / raw)
To: netdev; +Cc: Hannes Frederic Sowa
In-Reply-To: <1422504065-17445-1-git-send-email-dsahern@gmail.com>
Hi Hannes:
Any comments before I spin a v3 to address Dave's comments?
David
On 1/28/15 9:01 PM, David Ahern wrote:
> Currently, all ipv6 addresses are flushed when the interface is configured
> down, even static address:
>
> [root@f20 ~]# ip -6 addr add dev eth1 2000:11:1:1::1/64
> [root@f20 ~]# ip addr show dev eth1
> 3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
> link/ether 02:04:11:22:33:01 brd ff:ff:ff:ff:ff:ff
> inet6 2000:11:1:1::1/64 scope global tentative
> valid_lft forever preferred_lft forever
> [root@f20 ~]# ip link set dev eth1 up
> [root@f20 ~]# ip link set dev eth1 down
> [root@f20 ~]# ip addr show dev eth1
> 3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
> link/ether 02:04:11:22:33:01 brd ff:ff:ff:ff:ff:ff
>
> Add a new sysctl to make this behavior optional. The new setting defaults to
> flush all addresses to maintain backwards compatibility. When the setting is
> reset static addresses are not flushed:
>
> [root@f20 ~]# echo 0 > /proc/sys/net/ipv6/conf/eth1/flush_addr_on_down
> [root@f20 ~]# ip -6 addr add dev eth1 2000:11:1:1::1/64
> [root@f20 ~]# ip addr show dev eth1
> 3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
> link/ether 02:04:11:22:33:01 brd ff:ff:ff:ff:ff:ff
> inet6 2000:11:1:1::1/64 scope global tentative
> valid_lft forever preferred_lft forever
> [root@f20 ~]# ip link set dev eth1 up
> [root@f20 ~]# ip link set dev eth1 down
> [root@f20 ~]# ip addr show dev eth1
> 3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
> link/ether 02:04:11:22:33:01 brd ff:ff:ff:ff:ff:ff
> inet6 2000:11:1:1::1/64 scope global
> valid_lft forever preferred_lft forever
> inet6 fe80::4:11ff:fe22:3301/64 scope link
> valid_lft forever preferred_lft forever
>
> v2:
> - only keep static addresses as suggested by Hannes
> - added new managed flag to track configured addresses
> - on ifdown do not remove from configured address from inet6_addr_lst
> - on ifdown reset the TENTATIVE flag and set state to DAD so that DAD is
> redone when link is brought up again
>
> Suggested-by: Hannes Frederic Sowa <hannes@redhat.com>
> Signed-off-by: David Ahern <dsahern@gmail.com>
> Cc: Hannes Frederic Sowa <hannes@redhat.com>
>
> Signed-off-by: David Ahern <dsahern@gmail.com>
> ---
> include/linux/ipv6.h | 1 +
> include/net/if_inet6.h | 1 +
> include/uapi/linux/ipv6.h | 1 +
> net/ipv6/addrconf.c | 55 ++++++++++++++++++++++++++++++++++++++---------
> 4 files changed, 48 insertions(+), 10 deletions(-)
>
> diff --git a/include/linux/ipv6.h b/include/linux/ipv6.h
> index 2805062c013f..b91b7c8be023 100644
> --- a/include/linux/ipv6.h
> +++ b/include/linux/ipv6.h
> @@ -53,6 +53,7 @@ struct ipv6_devconf {
> __s32 ndisc_notify;
> __s32 suppress_frag_ndisc;
> __s32 accept_ra_mtu;
> + __s32 flush_addr_on_down;
> void *sysctl;
> };
>
> diff --git a/include/net/if_inet6.h b/include/net/if_inet6.h
> index 98e5f9578f86..3b6323111f77 100644
> --- a/include/net/if_inet6.h
> +++ b/include/net/if_inet6.h
> @@ -72,6 +72,7 @@ struct inet6_ifaddr {
> int regen_count;
>
> bool tokenized;
> + bool managed;
>
> struct rcu_head rcu;
> struct in6_addr peer_addr;
> diff --git a/include/uapi/linux/ipv6.h b/include/uapi/linux/ipv6.h
> index 437a6a4b125a..ed10d4ba8340 100644
> --- a/include/uapi/linux/ipv6.h
> +++ b/include/uapi/linux/ipv6.h
> @@ -170,6 +170,7 @@ enum {
> DEVCONF_ACCEPT_RA_FROM_LOCAL,
> DEVCONF_USE_OPTIMISTIC,
> DEVCONF_ACCEPT_RA_MTU,
> + DEVCONF_FLUSH_ON_DOWN,
> DEVCONF_MAX
> };
>
> diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
> index 7dcc065e2160..e0e82aad2116 100644
> --- a/net/ipv6/addrconf.c
> +++ b/net/ipv6/addrconf.c
> @@ -202,6 +202,7 @@ static struct ipv6_devconf ipv6_devconf __read_mostly = {
> .accept_dad = 1,
> .suppress_frag_ndisc = 1,
> .accept_ra_mtu = 1,
> + .flush_addr_on_down = 1,
> };
>
> static struct ipv6_devconf ipv6_devconf_dflt __read_mostly = {
> @@ -240,6 +241,7 @@ static struct ipv6_devconf ipv6_devconf_dflt __read_mostly = {
> .accept_dad = 1,
> .suppress_frag_ndisc = 1,
> .accept_ra_mtu = 1,
> + .flush_addr_on_down = 1,
> };
>
> /* Check if a valid qdisc is available */
> @@ -870,6 +872,7 @@ ipv6_add_addr(struct inet6_dev *idev, const struct in6_addr *addr,
> ifa->prefered_lft = prefered_lft;
> ifa->cstamp = ifa->tstamp = jiffies;
> ifa->tokenized = false;
> + ifa->managed = false;
>
> ifa->rt = rt;
>
> @@ -2510,6 +2513,8 @@ static int inet6_addr_add(struct net *net, int ifindex,
> valid_lft, prefered_lft);
>
> if (!IS_ERR(ifp)) {
> + ifp->managed = true;
> +
> if (!(ifa_flags & IFA_F_NOPREFIXROUTE)) {
> addrconf_prefix_route(&ifp->addr, ifp->prefix_len, dev,
> expires, flags);
> @@ -3032,8 +3037,9 @@ static int addrconf_ifdown(struct net_device *dev, int how)
> {
> struct net *net = dev_net(dev);
> struct inet6_dev *idev;
> - struct inet6_ifaddr *ifa;
> + struct inet6_ifaddr *ifa, *tmp;
> int state, i;
> + struct list_head del_list;
>
> ASSERT_RTNL();
>
> @@ -3067,9 +3073,12 @@ static int addrconf_ifdown(struct net_device *dev, int how)
> restart:
> hlist_for_each_entry_rcu(ifa, h, addr_lst) {
> if (ifa->idev == idev) {
> - hlist_del_init_rcu(&ifa->addr_lst);
> addrconf_del_dad_work(ifa);
> - goto restart;
> + if (how || idev->cnf.flush_addr_on_down ||
> + !ifa->managed) {
> + hlist_del_init_rcu(&ifa->addr_lst);
> + goto restart;
> + }
> }
> }
> spin_unlock_bh(&addrconf_hash_lock);
> @@ -3103,14 +3112,35 @@ restart:
> write_lock_bh(&idev->lock);
> }
>
> - while (!list_empty(&idev->addr_list)) {
> - ifa = list_first_entry(&idev->addr_list,
> + INIT_LIST_HEAD(&del_list);
> + list_for_each_entry_safe(ifa, tmp, &idev->addr_list, if_list) {
> + /*
> + * on NETDEV_DOWN events do not flush managed (user configured)
> + * addresses unless configured to do so. If the address is not
> + * deleted reset flags and state such that DAD is re-done on a
> + * subsequent link up.
> + */
> + if (!how && !idev->cnf.flush_addr_on_down && ifa->managed) {
> + if (!(ifa->flags & IFA_F_NODAD)) {
> + ifa->flags |= IFA_F_TENTATIVE;
> + ifa->state = INET6_IFADDR_STATE_DAD;
> + }
> + } else {
> + list_del(&ifa->if_list);
> + list_add(&ifa->if_list, &del_list);
> + }
> + }
> +
> + write_unlock_bh(&idev->lock);
> +
> + while (!list_empty(&del_list)) {
> + ifa = list_first_entry(&del_list,
> struct inet6_ifaddr, if_list);
> +
> addrconf_del_dad_work(ifa);
>
> list_del(&ifa->if_list);
>
> - write_unlock_bh(&idev->lock);
>
> spin_lock_bh(&ifa->state_lock);
> state = ifa->state;
> @@ -3122,12 +3152,8 @@ restart:
> inet6addr_notifier_call_chain(NETDEV_DOWN, ifa);
> }
> in6_ifa_put(ifa);
> -
> - write_lock_bh(&idev->lock);
> }
>
> - write_unlock_bh(&idev->lock);
> -
> /* Step 5: Discard anycast and multicast list */
> if (how) {
> ipv6_ac_destroy_dev(idev);
> @@ -4383,6 +4409,7 @@ static inline void ipv6_store_devconf(struct ipv6_devconf *cnf,
> array[DEVCONF_SUPPRESS_FRAG_NDISC] = cnf->suppress_frag_ndisc;
> array[DEVCONF_ACCEPT_RA_FROM_LOCAL] = cnf->accept_ra_from_local;
> array[DEVCONF_ACCEPT_RA_MTU] = cnf->accept_ra_mtu;
> + array[DEVCONF_FLUSH_ON_DOWN] = cnf->flush_addr_on_down;
> }
>
> static inline size_t inet6_ifla6_size(void)
> @@ -5269,6 +5296,14 @@ static struct addrconf_sysctl_table
> .proc_handler = proc_dointvec,
> },
> {
> + .procname = "flush_addr_on_down",
> + .data = &ipv6_devconf.flush_addr_on_down,
> + .maxlen = sizeof(int),
> + .mode = 0644,
> + .proc_handler = proc_dointvec,
> +
> + },
> + {
> /* sentinel */
> }
> },
>
^ permalink raw reply
* Re: [PATCH v3 3/3] stmmac: pci: add MSI support for Intel Quark X1000
From: Andy Shevchenko @ 2015-02-02 15:46 UTC (permalink / raw)
To: Bryan O'Donoghue; +Cc: netdev, Kweh, Hock Leong, davem, Ahmad, Josef
In-Reply-To: <54CF94FF.1050802@nexus-software.ie>
On Mon, 2015-02-02 at 15:17 +0000, Bryan O'Donoghue wrote:
> Hi guys.
>
> Has the issue with PVM masking been addressed ?
>
> https://lkml.org/lkml/2014/10/1/221
>
> If not then please drop MSIs from this patchset.
I do not see the reason why it should be done on per driver basis.
Care to fix this under arch/x86 then when adding new Quark platform?
--
Andy Shevchenko <andriy.shevchenko@intel.com>
Intel Finland Oy
^ permalink raw reply
* Re: [PATCH] tun: orphan an skb on tx
From: David Woodhouse @ 2015-02-02 15:47 UTC (permalink / raw)
To: Phil Sutter
Cc: David Miller, mst, herbert, eric.dumazet, jan.kiszka, netdev,
linux-kernel, qemu-devel
In-Reply-To: <20150202152343.GA15880@orbit.nwl.cc>
[-- Attachment #1: Type: text/plain, Size: 3552 bytes --]
On Mon, 2015-02-02 at 16:23 +0100, Phil Sutter wrote:
> Since you want to provide connectivity over HTTPS which is not possible
> in kernel space, you are stuck with keeping the tun device. So the
> packet flow in that case is identical to how e.g. OpenVPN does it:
>
> - tunX holds default route
> - OpenConnect then:
> - receives packets on /dev/tun
> - holds TCP socket to VPN concentrator
> - does encapsulation into TLS
>
> Speaking of optimisation, the interesting part is the alternative flow
> via IPsec in UDP.
Right. The packet flow you describe is what we already have. Except of
course we already *do* establish the UDP connection (which is DTLS when
we're talking to a Cisco AnyConnect server, and ESP in UDP when we're
talking to Juniper). If we get responses to keepalive packets, we'll
send outbound packets over the UDP connection. If the UDP connectivity
goes AWOL, we'll fall back to sending on TCP. Rekeying of the UDP
connection is handled over the TCP control connection too. Even in the
DTLS case, the master secret and session ID are exchanged over TCP and
the DTLS is actually done as a 'session resume', without the normal DTLS
handshake ever happening.
As you say, I'm stuck with keeping the tun device (or something very
much like it). This *isn't* like vpnc where I can set up an IPSec config
and just let it run.
> AFAICT, it should be possible to setup an ESP in UDP
> tunnel using XFRM (see ip-xfrm(8) for reference), although I didn't try
> that myself. The funny thing with XFRM is, it applies before the routing
> decision does: If my IPsec policy matches, the packet goes that way no
> matter what the routing table says about the original destination. This
> can be used to override the default route provided via tun0 in the above
> case.
Except it isn't even the default route. We get given a bunch of split
includes or split excludes from the VPN server. We pass them to
vpnc-script or NetworkManager to actually set the routes up, and those
tools may make their own tweaks to what the server requested — denying
the default route and setting up explicit routes, or adding firewall
rules or NAT to incoming/outgoing packets on the tun device.
If it is no longer *just* the single tun device, everything gets really
complicated. Even *before* we talk about changing it on the fly during
normal operation.
> Of course, OpenConnect has to manage all the XFRM/policy stuff on it's
> own, since switching from ESP in UDP back to TLS would mean to tear down
> the XFRM tunnel. OpenConnect would have to setup (a limited) XFRM and
> send test traffic to decide whether to set it up fully (if limited) or
> tear it down (if unlimited) again so traffic arrives at tunX again.
Right. And ideally without CAP_NET_ADMIN.
> In my opinion, this might work. The whole setup is probably about as
> intuitive as the fact that kernel IPsec tunnel mode does not naturally
> provide an own interface. Firewall setup on top of that might become a
> matter of try-and-error. Maybe having a VTI interface and merely moving
> the default route instead of fiddling with policies all the time might
> make things a little easier to comprehend, but surely adds some
> performance overhead.
I think even the latter is sufficiently complex to manage that it's not
worth pursuing. I may throw together my suggested hack using
tun_get_socket() and see how much it makes *me* barf before deciding
whether to show it here for more feedback :)
--
dwmw2
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5745 bytes --]
^ permalink raw reply
* Re: [PATCH v3 3/3] stmmac: pci: add MSI support for Intel Quark X1000
From: Bryan O'Donoghue @ 2015-02-02 15:50 UTC (permalink / raw)
To: Andy Shevchenko; +Cc: netdev, Kweh, Hock Leong, davem, Ahmad, Josef
In-Reply-To: <1422891987.31903.374.camel@linux.intel.com>
On 02/02/15 15:46, Andy Shevchenko wrote:
> On Mon, 2015-02-02 at 15:17 +0000, Bryan O'Donoghue wrote:
>> Hi guys.
>>
>> Has the issue with PVM masking been addressed ?
>>
>> https://lkml.org/lkml/2014/10/1/221
>>
>> If not then please drop MSIs from this patchset.
>
> I do not see the reason why it should be done on per driver basis.
Agree.
> Care to fix this under arch/x86 then when adding new Quark platform?
Looking into that now.
Hmm - OK -let's aim to get a fix in for the bridge and leave the MSI
enable in place.
^ permalink raw reply
* RE: [PATCH net-next 0/4] enic: improve rq buff allocation and reduce dma mapping
From: David Laight @ 2015-02-02 15:56 UTC (permalink / raw)
To: 'Govindarajulu Varadarajan', davem@davemloft.net,
netdev@vger.kernel.org
Cc: ssujith@cisco.com, benve@cisco.com, edumazet@google.com,
ben@decadent.org.uk
In-Reply-To: <1422707290-939-1-git-send-email-_govind@gmx.com>
From: Govindarajulu Varadarajan
> The following series tries to address these two problem in rq buff allocation.
>
> * Memory wastage because of large 9k allocation using kmalloc:
> For 9k mtu buffer, netdev_alloc_skb_ip_align internally calls kmalloc for
> size > 4096. In case of 9k buff, kmalloc returns pages for order 2, 16k.
> And we use only ~9k of 16k. 7k memory wasted. Using the frag the frag
> allocator in patch 1/2, we can allocate three 9k buffs in a 32k page size.
> Typical enic configuration has 8 rq, and desc ring of size 4096.
> Thats 8 * 4096 * (16*1024) = 512 MB. Using this frag allocator:
> 8 * 4096 * (32*1024/3) = 341 MB. Thats 171 MB of memory save.
>
> * frequent dma_map() calls:
> we call dma_map() for every buff we allocate. When iommu is on, This is very
> cpu time consuming. From my testing, most of the cpu cycles are wasted
> spinning on spin_lock_irqsave(&iovad->iova_rbtree_lock, flags) in
> intel_map_page() .. -> ..__alloc_and_insert_iova_range()
>
> With this patch, we call dma_map() once for 32k page. i.e once for every three
> 9k desc, and once every twenty 1500 bytes desc.
Two questions:
1) How are you handling the skb's true_size ?
2) Memory fragmentation could easily make the allocation of 32k fail.
David
^ permalink raw reply
* Re: [PATCH net 0/2] netns: audit netdevice creation with IFLA_NET_NS_[PID|FD]
From: Nicolas Dichtel @ 2015-02-02 15:58 UTC (permalink / raw)
To: Arvid Brodin, netdev; +Cc: davem, dmitry.tarnyagin, alex.aring, linux-wpan
In-Reply-To: <54CBE2EF.7050003@alten.se>
Le 30/01/2015 21:00, Arvid Brodin a écrit :
> On 2015-01-26 22:28, Nicolas Dichtel wrote:
> *snip*
>> - HSR subsystem uses src_net to parse IFLA_HSR_SLAVE[1|2], but the netdevice has
>> the flag NETIF_F_NETNS_LOCAL, so the question is: does this netdevice really
>> supports x-netns? If not, the newlink handler should use the dest_net instead
>> of src_net, I can provide the patch.
> *snip*
>
> As the author of the HSR driver, I'd like to answer this question, but unfortunately
> I don't know what x-netns is. Neither Google nor Documentation/ has been particularly
> helpful.
>
> Care to elaborate? (Maybe this is a moot point now that the patch has been accepted,
> but I'd still like to understand, if you have the time to explain.)
Basically, network namespaces (netns) allow you to run several independant
instances of the linux networking stack.
Network interfaces are bound to one netns. By default, only one netns exists
(named init_net) when you boot your kernel.
For logical interfaces, they are usually bound to a link layer. For example, if
I understand well, hsr network interfaces receive and send their packets from
two physical interfaces (IFLA_HSR_SLAVE[1|2]).
Now imagine that these slaves are in a netns foo and the logical hsr interfaces
in netns bar. You have a x-netns interface, the link layer part of the interface
is not in the same netns than the upper part. A user will see the hsr interface
in netns bar, but this interface will send a receive packet in netns foo.
Usually, to configure an interface like this, you create it in netns foo and you
move it later to netns bar (ip link set hsr1 netns bar). The flag
NETIF_F_NETNS_LOCAL forbids this operation, you cannot move it to another netns.
But you still can create a x-netns interface:
ip netns add foo
ip link add hsr1 netns foo type hsr slave1 eth0 slave2 eth1
ip netns exec foo ip link ls hsr1
=> eth0 and eth1 are took from the current netns (because in the code, src_net
is the current netns) but hsr1 is built in netns foo.
Now, the question is: does HSR really work across netns? Why is the flag
NETIF_F_NETNS_LOCAL set?
dev_forward_skb() may be used to forward an skbuff to another netns.
Note, that I got a panic when playing with hsr:
ip link add hsr1 type hsr slave1 eth1 slave2 eth0
ip link del hsr1
=> panic
I dig a bit:
1/ hsr_netdev_notify() supposes that the port will always be available when the
notification is for an hsr interface. It's wrong. For example,
netdev_wait_allrefs() may resend NETDEV_UNREGISTER.
2/ with a patch that ignores the notification when the port is NULL, I got a
refcnt problem:
[ 327.372099] unregister_netdevice: waiting for hsr1 to become free. Usage
count = -1
Regards,
Nicolas
^ permalink raw reply
* Re: [PATCH net-next 0/3] openvswitch: Add STT support.
From: Tom Herbert @ 2015-02-02 16:15 UTC (permalink / raw)
To: Jesse Gross; +Cc: Pravin B Shelar, David Miller, Linux Netdev List
In-Reply-To: <CAEP_g=-Yn849TmrN5xFLJVxuux0fBuYGFSM7K-psg=pdxgPR9w@mail.gmail.com>
Here is my data running STT and comparing against VXLAN, GUE, and
native (no encapsulation). This is using bnx2x.
TCP_STREAM IPv4 1 connection
STT
2.33% TX CPU utilization
3.63% RX CPU utilization
8790 Mbps
GRE/GUE (RCO, GSO, GRO)
5.55% TX CPU utilization
6.67% RX CPU utilization
9106 Mbps
VXLAN (RCO, GSO, GRO)
5.07% TX CPU utilization
5.95% RX CPU utilization
9061 Mbps
Native (no ecapsulation)
2.48% TX CPU utilization
3.96% RX CPU utilization
9411 Mbps
TCP_STREAM IPv4 200 connections
STT
8.36% TX CPU utilization
9.29% RX CPU utilization
9389 Mbps
GUE/GRE (RCO, GSO, GRO)
9.98% TX CPU utilization
13.69% RX CPU utilization
9132 Mbps
VXLAN (RCO, GSO, GRO)
11.79% TX CPU utilization
13.88% RX CPU utilization
9093 Mbps
Native (no ecapsulation)
6.05% TX CPU utilization
7.27% RX CPU utilization
9378 Mbps
TCP_RR IPv4 200 connections
STT
41.91% CPU utilization
345/406/594 90/95/99% latencies
562560 tps
GUE/GRE (RCO, GSO, GRO)
93.03% CPU utilization
160/255/467 90/95/99% latencies
1.1401e+06 tps
VXLAN (RCO, GSO, GRO)
93.73% CPU utilization
157/249/448 90/95/99% latencies
1.15655e+06 tps
Native (no ecapsulation)
87.46% CPU utilization
120/178/292 90/95/99% latencies
1.51747e+06 tps
^ permalink raw reply
* Re: [PATCH net-next 0/3] openvswitch: Add STT support.
From: Tom Herbert @ 2015-02-02 16:23 UTC (permalink / raw)
To: Jesse Gross; +Cc: Pravin Shelar, David Miller, Linux Netdev List
In-Reply-To: <CAEP_g=-3GXJfawPb4jevkZhqmzTttsO1Rv_2J6GwpG=PR_a-0g@mail.gmail.com>
> I would recommend you take a look at the draft if you haven't already:
> http://tools.ietf.org/html/draft-davie-stt-06
>
> It is currently in the final stages of the RFC publication process.
Sorry, but this statement is completely wrong and misleading.
According to datatracker this draft has been expired since October,
there's been no discussion on it in IETF, and this has not gone to
IESG. You cannot say this is an IETF standard nor that it is about to
be published as one. See
https://datatracker.ietf.org/doc/draft-davie-stt/ and please read the
Internet Standards process in RFC2026.
I suggest that you update the draft and post it on both nvo3 and tsvwg
so there can be some real discussion on the implications of
repurposing an IP protocol number and breaking TCP protocol standards.
Tom
^ permalink raw reply
* Re: [PATCH net-next 7/8] cxgb4: Added support in debugfs to display tp_err_stats
From: Or Gerlitz @ 2015-02-02 16:32 UTC (permalink / raw)
To: Hariprasad Shenai
Cc: Linux Netdev List, David Miller, leedom, anish, nirranjan,
praveenm
In-Reply-To: <1422888789-12016-8-git-send-email-hariprasad@chelsio.com>
On Mon, Feb 2, 2015 at 4:53 PM, Hariprasad Shenai
<hariprasad@chelsio.com> wrote:
> SNIP - empty change log... please try to avoid such commits
Anything wrong with retrieving these with ethtool statistics?
^ permalink raw reply
* Re: [PATCH net-next 2/8] cxgb4: Added support in debugfs to display tp_la stats
From: Or Gerlitz @ 2015-02-02 16:34 UTC (permalink / raw)
To: Hariprasad Shenai
Cc: Linux Netdev List, David Miller, leedom, anish, nirranjan,
praveenm
In-Reply-To: <1422888789-12016-3-git-send-email-hariprasad@chelsio.com>
On Mon, Feb 2, 2015 at 4:53 PM, Hariprasad Shenai
<hariprasad@chelsio.com> wrote:
same two comments as for patch #7
> Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com>
^ permalink raw reply
* Re: [PATCH 0/3] crypto: algif - change algif_skcipher to be asynchronous
From: Stephan Mueller @ 2015-02-02 16:40 UTC (permalink / raw)
To: Tadeusz Struk
Cc: herbert, linux-crypto, netdev, davem, qat-linux, linux-kernel
In-Reply-To: <54CF91A6.2020100@intel.com>
Am Montag, 2. Februar 2015, 07:03:02 schrieb Tadeusz Struk:
Hi Tadeusz,
>On 02/01/2015 10:31 AM, Stephan Mueller wrote:
>> Hi Tadeusz,
>>
>>> > The way the algif_skcipher works currently is that on
>>> > sendmsg/sendpage it builds an sgl for the input data and then on
>>> > read/recvmsg it sends the job for encryption putting the user to
>>> > sleep till the data is processed. This way it can only handle one
>>> > job at a given time.
>>> > To be able to fuly utilize the potential of existing crypto
>>> > hardware
>>> > accelerators it is required to submit multiple jobs in
>>> > asynchronously.
>>> > First patch enables asynchronous read and write on socket.
>>> > Second patch enables af_alg sgl to be linked.
>>> > Third patch implement asynch read for skcipher.
>>
>> Do you have a code fragment on how to test that patch? I would like
>> to see whether I can test that with my libkcapi.
>
>Hi Stephan,
>This is what I'm using.
Thanks for the listing.
Are you aware of the speed tester that I added to libkcapi? See [1]
subdir speed-test/
If you want to play with it, all you need to do is to add your
init/encryption/fini code into cryptoperf-skcipher.c.
The key is that cp_ablkcipher_enc_test/cp_ablkcipher_dec_test performs
only the encryption/decryption operation (setkey, etc is done in the
init call). The speed measuring is done only over that function.
[1] http://www.chronox.de/libkcapi.html
Ciao
Stephan
^ permalink raw reply
* Re: [PATCH net-next] drivers: net: cpsw: make cpsw_ale.c a module to allow re-use on Keystone
From: Tony Lindgren @ 2015-02-02 16:40 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Murali Karicheri, w-kwok2, davem, mugunthanvnm, prabhakar.csengg,
grygorii.strashko, lokeshvutla, mpa, lsorense, netdev,
linux-kernel
In-Reply-To: <1802322.NDR3d5ZRSA@wuerfel>
* Arnd Bergmann <arnd@arndb.de> [150129 15:51]:
> On Thursday 29 January 2015 18:15:51 Murali Karicheri wrote:
> > NetCP on Keystone has cpsw ale function similar to other TI SoCs
> > and this driver is re-used. To allow both ti cpsw and keystone netcp
> > to re-use the driver, convert the cpsw ale to a module and configure
> > it through Kconfig option CONFIG_TI_CPSW_ALE. Currently it is statically
> > linked to both TI CPSW and NetCP and this causes issues when the above
> > drivers are built as dynamic modules. This patch addresses this issue
> >
> > While at it, fix the Makefile and code to build both netcp_core and
> > netcp_ethss as dynamic modules. This is needed to support arm allmodconfig.
> > This also requires exporting of API calls provided by netcp_core so that
> > both the above can be dynamic modules.
> >
> > Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
> > ---
> > drivers/net/ethernet/ti/Kconfig | 19 +++++++++++++++++--
> > drivers/net/ethernet/ti/Makefile | 8 +++++---
> > drivers/net/ethernet/ti/cpsw_ale.c | 26 ++++++++++++++++++++++++--
> > drivers/net/ethernet/ti/netcp_core.c | 8 ++++++++
> > drivers/net/ethernet/ti/netcp_ethss.c | 5 +++++
> > 5 files changed, 59 insertions(+), 7 deletions(-)
>
> I was hoping there would be a way without exporting all those symbols, but
> I also couldn't come up with a better solution. I'm putting this into the
> randconfig build test for now, but I'm guessing it's fine.
Probably the best way in the long run is to add a single exported
function to cpsw-common.c I just added for the MAC address function.
Then all the cpsw like drivers can register with that instead of
having tons of custom exported functions.
But before doing that, we should have a clear idea what all can
be shared. Murali, maybe you can take a look at that?
Regards,
Tony
^ permalink raw reply
* [PATCHv1 net] xen-netback: stop the guest rx thread after a fatal error
From: David Vrabel @ 2015-02-02 16:57 UTC (permalink / raw)
To: netdev; +Cc: David Vrabel, xen-devel, Ian Campbell, Wei Liu
After commit e9d8b2c2968499c1f96563e6522c56958d5a1d0d (xen-netback:
disable rogue vif in kthread context), a fatal (protocol) error would
leave the guest Rx thread spinning, wasting CPU time. Commit
ecf08d2dbb96d5a4b4bcc53a39e8d29cc8fef02e (xen-netback: reintroduce
guest Rx stall detection) made this even worse by removing a
cond_resched() from this path.
Since a fatal error is non-recoverable, just allow the guest Rx thread
to exit. This requires taking additional refs to the task so the
thread exiting early is handled safely.
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Reported-by: Julien Grall <julien.grall@linaro.org>
Tested-by: Julien Grall <julien.grall@linaro.org>
---
drivers/net/xen-netback/interface.c | 2 ++
drivers/net/xen-netback/netback.c | 3 +--
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
index 9259a73..037f74f 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -578,6 +578,7 @@ int xenvif_connect(struct xenvif_queue *queue, unsigned long tx_ring_ref,
goto err_rx_unbind;
}
queue->task = task;
+ get_task_struct(task);
task = kthread_create(xenvif_dealloc_kthread,
(void *)queue, "%s-dealloc", queue->name);
@@ -634,6 +635,7 @@ void xenvif_disconnect(struct xenvif *vif)
if (queue->task) {
kthread_stop(queue->task);
+ put_task_struct(queue->task);
queue->task = NULL;
}
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 908e65e..c8ce701 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -2109,8 +2109,7 @@ int xenvif_kthread_guest_rx(void *data)
*/
if (unlikely(vif->disabled && queue->id == 0)) {
xenvif_carrier_off(vif);
- xenvif_rx_queue_purge(queue);
- continue;
+ break;
}
if (!skb_queue_empty(&queue->rx_queue))
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCHv1 net] xen-netback: stop the guest rx thread after a fatal error
From: Wei Liu @ 2015-02-02 17:00 UTC (permalink / raw)
To: David Vrabel; +Cc: netdev, xen-devel, Ian Campbell, Wei Liu
In-Reply-To: <1422896271-26551-1-git-send-email-david.vrabel@citrix.com>
On Mon, Feb 02, 2015 at 04:57:51PM +0000, David Vrabel wrote:
> After commit e9d8b2c2968499c1f96563e6522c56958d5a1d0d (xen-netback:
> disable rogue vif in kthread context), a fatal (protocol) error would
> leave the guest Rx thread spinning, wasting CPU time. Commit
> ecf08d2dbb96d5a4b4bcc53a39e8d29cc8fef02e (xen-netback: reintroduce
> guest Rx stall detection) made this even worse by removing a
> cond_resched() from this path.
>
> Since a fatal error is non-recoverable, just allow the guest Rx thread
> to exit. This requires taking additional refs to the task so the
> thread exiting early is handled safely.
>
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> Reported-by: Julien Grall <julien.grall@linaro.org>
> Tested-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Wei Liu <wei.liu2@citrix.com>
> ---
> drivers/net/xen-netback/interface.c | 2 ++
> drivers/net/xen-netback/netback.c | 3 +--
> 2 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
> index 9259a73..037f74f 100644
> --- a/drivers/net/xen-netback/interface.c
> +++ b/drivers/net/xen-netback/interface.c
> @@ -578,6 +578,7 @@ int xenvif_connect(struct xenvif_queue *queue, unsigned long tx_ring_ref,
> goto err_rx_unbind;
> }
> queue->task = task;
> + get_task_struct(task);
>
> task = kthread_create(xenvif_dealloc_kthread,
> (void *)queue, "%s-dealloc", queue->name);
> @@ -634,6 +635,7 @@ void xenvif_disconnect(struct xenvif *vif)
>
> if (queue->task) {
> kthread_stop(queue->task);
> + put_task_struct(queue->task);
> queue->task = NULL;
> }
>
> diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
> index 908e65e..c8ce701 100644
> --- a/drivers/net/xen-netback/netback.c
> +++ b/drivers/net/xen-netback/netback.c
> @@ -2109,8 +2109,7 @@ int xenvif_kthread_guest_rx(void *data)
> */
> if (unlikely(vif->disabled && queue->id == 0)) {
> xenvif_carrier_off(vif);
> - xenvif_rx_queue_purge(queue);
> - continue;
> + break;
> }
>
> if (!skb_queue_empty(&queue->rx_queue))
> --
> 1.7.10.4
^ permalink raw reply
* [PATCH] net: fs_enet: Implement NETIF_F_SG feature
From: Christophe Leroy @ 2015-02-02 17:06 UTC (permalink / raw)
To: Pantelis Antoniou, Vitaly Bordug, davem
Cc: linux-kernel, linuxppc-dev, netdev
Freescale ethernet controllers have the capability to re-assemble fragmented
data into a single ethernet frame. This patch uses this capability and
implements NETIP_F_SG feature into the fs_enet ethernet driver.
On a MPC885, I get 53% performance improvement on a ftp transfer of a 15Mb file:
* Without the patch : 2,8 Mbps
* With the patch : 4,3 Mbps
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
---
.../net/ethernet/freescale/fs_enet/fs_enet-main.c | 95 +++++++++++++++-------
drivers/net/ethernet/freescale/fs_enet/fs_enet.h | 1 +
2 files changed, 66 insertions(+), 30 deletions(-)
diff --git a/drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c b/drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c
index 9e2bcb8..a176287 100644
--- a/drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c
+++ b/drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c
@@ -278,14 +278,20 @@ static int fs_enet_tx_napi(struct napi_struct *napi, int budget)
fep->stats.collisions++;
/* unmap */
- dma_unmap_single(fep->dev, CBDR_BUFADDR(bdp),
- skb->len, DMA_TO_DEVICE);
+ if (fep->mapped_as_page[dirtyidx])
+ dma_unmap_page(fep->dev, CBDR_BUFADDR(bdp),
+ CBDR_DATLEN(bdp), DMA_TO_DEVICE);
+ else
+ dma_unmap_single(fep->dev, CBDR_BUFADDR(bdp),
+ CBDR_DATLEN(bdp), DMA_TO_DEVICE);
/*
* Free the sk buffer associated with this last transmit.
*/
- dev_kfree_skb(skb);
- fep->tx_skbuff[dirtyidx] = NULL;
+ if (skb) {
+ dev_kfree_skb(skb);
+ fep->tx_skbuff[dirtyidx] = NULL;
+ }
/*
* Update pointer to next buffer descriptor to be transmitted.
@@ -299,7 +305,7 @@ static int fs_enet_tx_napi(struct napi_struct *napi, int budget)
* Since we have freed up a buffer, the ring is no longer
* full.
*/
- if (!fep->tx_free++)
+ if (++fep->tx_free >= MAX_SKB_FRAGS)
do_wake = 1;
has_tx_work = 1;
}
@@ -509,6 +515,9 @@ static int fs_enet_start_xmit(struct sk_buff *skb, struct net_device *dev)
cbd_t __iomem *bdp;
int curidx;
u16 sc;
+ int nr_frags = skb_shinfo(skb)->nr_frags;
+ skb_frag_t *frag;
+ int len;
#ifdef CONFIG_FS_ENET_MPC5121_FEC
if (((unsigned long)skb->data) & 0x3) {
@@ -530,7 +539,7 @@ static int fs_enet_start_xmit(struct sk_buff *skb, struct net_device *dev)
*/
bdp = fep->cur_tx;
- if (!fep->tx_free || (CBDR_SC(bdp) & BD_ENET_TX_READY)) {
+ if (fep->tx_free <= nr_frags || (CBDR_SC(bdp) & BD_ENET_TX_READY)) {
netif_stop_queue(dev);
spin_unlock(&fep->tx_lock);
@@ -543,35 +552,42 @@ static int fs_enet_start_xmit(struct sk_buff *skb, struct net_device *dev)
}
curidx = bdp - fep->tx_bd_base;
- /*
- * Clear all of the status flags.
- */
- CBDC_SC(bdp, BD_ENET_TX_STATS);
-
- /*
- * Save skb pointer.
- */
- fep->tx_skbuff[curidx] = skb;
-
- fep->stats.tx_bytes += skb->len;
+ len = skb->len;
+ fep->stats.tx_bytes += len;
+ if (nr_frags)
+ len -= skb->data_len;
+ fep->tx_free -= nr_frags + 1;
/*
* Push the data cache so the CPM does not get stale memory data.
*/
CBDW_BUFADDR(bdp, dma_map_single(fep->dev,
- skb->data, skb->len, DMA_TO_DEVICE));
- CBDW_DATLEN(bdp, skb->len);
+ skb->data, len, DMA_TO_DEVICE));
+ CBDW_DATLEN(bdp, len);
+
+ fep->mapped_as_page[curidx] = 0;
+ frag = skb_shinfo(skb)->frags;
+ while (nr_frags) {
+ CBDC_SC(bdp,
+ BD_ENET_TX_STATS | BD_ENET_TX_LAST | BD_ENET_TX_TC);
+ CBDS_SC(bdp, BD_ENET_TX_READY);
+
+ if ((CBDR_SC(bdp) & BD_ENET_TX_WRAP) == 0)
+ bdp++, curidx++;
+ else
+ bdp = fep->tx_bd_base, curidx = 0;
- /*
- * If this was the last BD in the ring, start at the beginning again.
- */
- if ((CBDR_SC(bdp) & BD_ENET_TX_WRAP) == 0)
- fep->cur_tx++;
- else
- fep->cur_tx = fep->tx_bd_base;
+ len = skb_frag_size(frag);
+ CBDW_BUFADDR(bdp, skb_frag_dma_map(fep->dev, frag, 0, len,
+ DMA_TO_DEVICE));
+ CBDW_DATLEN(bdp, len);
- if (!--fep->tx_free)
- netif_stop_queue(dev);
+ fep->tx_skbuff[curidx] = NULL;
+ fep->mapped_as_page[curidx] = 1;
+
+ frag++;
+ nr_frags--;
+ }
/* Trigger transmission start */
sc = BD_ENET_TX_READY | BD_ENET_TX_INTR |
@@ -582,8 +598,22 @@ static int fs_enet_start_xmit(struct sk_buff *skb, struct net_device *dev)
* yay for hw reuse :) */
if (skb->len <= 60)
sc |= BD_ENET_TX_PAD;
+ CBDC_SC(bdp, BD_ENET_TX_STATS);
CBDS_SC(bdp, sc);
+ /* Save skb pointer. */
+ fep->tx_skbuff[curidx] = skb;
+
+ /* If this was the last BD in the ring, start at the beginning again. */
+ if ((CBDR_SC(bdp) & BD_ENET_TX_WRAP) == 0)
+ bdp++;
+ else
+ bdp = fep->tx_bd_base;
+ fep->cur_tx = bdp;
+
+ if (fep->tx_free < MAX_SKB_FRAGS)
+ netif_stop_queue(dev);
+
skb_tx_timestamp(skb);
(*fep->ops->tx_kickstart)(dev);
@@ -917,7 +947,7 @@ static int fs_enet_probe(struct platform_device *ofdev)
}
fpi->rx_ring = 32;
- fpi->tx_ring = 32;
+ fpi->tx_ring = 64;
fpi->rx_copybreak = 240;
fpi->napi_weight = 17;
fpi->phy_node = of_parse_phandle(ofdev->dev.of_node, "phy-handle", 0);
@@ -955,7 +985,8 @@ static int fs_enet_probe(struct platform_device *ofdev)
privsize = sizeof(*fep) +
sizeof(struct sk_buff **) *
- (fpi->rx_ring + fpi->tx_ring);
+ (fpi->rx_ring + fpi->tx_ring) +
+ sizeof(char) * fpi->tx_ring;
ndev = alloc_etherdev(privsize);
if (!ndev) {
@@ -978,6 +1009,8 @@ static int fs_enet_probe(struct platform_device *ofdev)
fep->rx_skbuff = (struct sk_buff **)&fep[1];
fep->tx_skbuff = fep->rx_skbuff + fpi->rx_ring;
+ fep->mapped_as_page = (char *)(fep->rx_skbuff + fpi->rx_ring +
+ fpi->tx_ring);
spin_lock_init(&fep->lock);
spin_lock_init(&fep->tx_lock);
@@ -1007,6 +1040,8 @@ static int fs_enet_probe(struct platform_device *ofdev)
netif_carrier_off(ndev);
+ ndev->features |= NETIF_F_SG;
+
ret = register_netdev(ndev);
if (ret)
goto out_free_bd;
diff --git a/drivers/net/ethernet/freescale/fs_enet/fs_enet.h b/drivers/net/ethernet/freescale/fs_enet/fs_enet.h
index 3a4b49e..f184d8f 100644
--- a/drivers/net/ethernet/freescale/fs_enet/fs_enet.h
+++ b/drivers/net/ethernet/freescale/fs_enet/fs_enet.h
@@ -134,6 +134,7 @@ struct fs_enet_private {
void __iomem *ring_base;
struct sk_buff **rx_skbuff;
struct sk_buff **tx_skbuff;
+ char *mapped_as_page;
cbd_t __iomem *rx_bd_base; /* Address of Rx and Tx buffers. */
cbd_t __iomem *tx_bd_base;
cbd_t __iomem *dirty_tx; /* ring entries to be free()ed. */
--
2.1.0
^ permalink raw reply related
* [PATCH net-next] bridge: Let bridge not age 'externally' learnt FDB entries, they are removed when 'external' entity notifies the aging
From: Siva Mannem @ 2015-02-02 17:21 UTC (permalink / raw)
To: netdev; +Cc: Siva Mannem
When 'learned_sync' flag is turned on, the offloaded switch
port syncs learned MAC addresses to bridge's FDB via switchdev notifier
(NETDEV_SWITCH_FDB_ADD). Currently, FDB entries learnt via this mechanism are
wrongly being deleted by bridge aging logic. This patch ensures that FDB
entries synced from offloaded switch ports are not deleted by bridging logic.
Such entries can only be deleted via switchdev notifier
(NETDEV_SWITCH_FDB_DEL).
Signed-off-by: Siva Mannem <siva.mannem.lnx@gmail.com>
---
net/bridge/br_fdb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/bridge/br_fdb.c b/net/bridge/br_fdb.c
index 08bf04b..6eb94b5 100644
--- a/net/bridge/br_fdb.c
+++ b/net/bridge/br_fdb.c
@@ -280,7 +280,7 @@ void br_fdb_cleanup(unsigned long _data)
hlist_for_each_entry_safe(f, n, &br->hash[i], hlist) {
unsigned long this_timer;
- if (f->is_static)
+ if (f->is_static || f->added_by_external_learn)
continue;
this_timer = f->updated + delay;
if (time_before_eq(this_timer, jiffies))
--
2.1.0
^ permalink raw reply related
* Re: [PATCH] net: ipv6: Make address flushing on ifdown optional - v2
From: Brian Haley @ 2015-02-02 17:38 UTC (permalink / raw)
To: David Ahern, netdev; +Cc: Hannes Frederic Sowa
In-Reply-To: <1422504065-17445-1-git-send-email-dsahern@gmail.com>
On 01/28/2015 11:01 PM, David Ahern wrote:
> Currently, all ipv6 addresses are flushed when the interface is configured
> down, even static address:
>
...
> diff --git a/include/linux/ipv6.h b/include/linux/ipv6.h
> index 2805062c013f..b91b7c8be023 100644
> --- a/include/linux/ipv6.h
> +++ b/include/linux/ipv6.h
> @@ -53,6 +53,7 @@ struct ipv6_devconf {
> __s32 ndisc_notify;
> __s32 suppress_frag_ndisc;
> __s32 accept_ra_mtu;
> + __s32 flush_addr_on_down;
> void *sysctl;
> };
...
> diff --git a/include/uapi/linux/ipv6.h b/include/uapi/linux/ipv6.h
> index 437a6a4b125a..ed10d4ba8340 100644
> --- a/include/uapi/linux/ipv6.h
> +++ b/include/uapi/linux/ipv6.h
> @@ -170,6 +170,7 @@ enum {
> DEVCONF_ACCEPT_RA_FROM_LOCAL,
> DEVCONF_USE_OPTIMISTIC,
> DEVCONF_ACCEPT_RA_MTU,
> + DEVCONF_FLUSH_ON_DOWN,
nit: DEVCONF_FLUSH_ADDR_ON_DOWN to match the name added to ipv6_devconf.
-Brian
^ permalink raw reply
* RE: [PATCH net-next 0/4] enic: improve rq buff allocation and reduce dma mapping
From: Govindarajulu Varadarajan @ 2015-02-02 17:49 UTC (permalink / raw)
To: David Laight
Cc: 'Govindarajulu Varadarajan', davem@davemloft.net,
netdev@vger.kernel.org, ssujith@cisco.com, benve@cisco.com,
edumazet@google.com, ben@decadent.org.uk
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D1CAD8FD1@AcuExch.aculab.com>
On Mon, 2 Feb 2015, David Laight wrote:
> Two questions:
> 1) How are you handling the skb's true_size ?
skb->true_size is set to ksize(data) for data allocated using alloc_page and
kmalloc. For frags we set it to size of frag. Check the function build_skb()
> 2) Memory fragmentation could easily make the allocation of 32k fail.
>
With huge memory these days order-3 allocation failure is quite rare. In my
testing on system with 8G memory I have never encountered order-3 failure.
This is probably why __netdev_alloc_frag tries order-3 page allocation first.
If order-3 page allocation fails, we drop to minimum order required for the
given size.
^ permalink raw reply
* Re: AF_NETDEV - device specific sockets
From: John Fastabend @ 2015-02-02 18:04 UTC (permalink / raw)
To: Zayats, Michael; +Cc: netdev@vger.kernel.org, dborkman
In-Reply-To: <FC8E8D0ECC753F45808079B18C3203FE1CCAF4@G4W3293.americas.hpqcorp.net>
On 01/31/2015 09:04 PM, Zayats, Michael wrote:
> More specific example would be when NIC performs certain fast path processing,
> while punting to the CPU for a slow path.
> Slow path would be interested to know the punt reason.
>
> Another example would be if specific NIC strips S-tag in QinQ case and would like to communicate the stripped
> Tag to the client.
>
Right, maybe we need some sort of TLV scheme to pass up the relevant
info. I'm not sure we want to necessarily bury it in the driver though.
Perhaps passing auxdata in a TLV format is worth considering.
Just curious do you have NICs that are stripping or inserting more then
a single tag?
For tagging my current scheme is to strip outer tags using this
experimental Flow API
http://www.spinics.net/lists/netdev/msg313071.html
and then only report the inner tag to the stack. At the moment I haven't
found any use cases this is not sufficient.
> There might be many types of custom functionality, agreed between the NIC and the clients,
> which is not generic or not practical enough for inclusion in the kernel.
>
> That's why I am looking for a generic, socket like mechanism of device<->client, packet + metadata communication,
> which wouldn't require core kernel modification.
hmm the question is how do the NIC and client "agree" on the
format of the data and its meaning? If you follow the thread
above and also our af_packet direct DMA work we are struggling
with similar questions,
http://www.spinics.net/lists/netdev/msg311862.html
I think we need some way to "describe" the meta-data or we
need to build some kernel/uapi standard that defines them.
.John
>
> Thanks,
>
> Michael
>
>
>
>
>
> -----Original Message-----
> From: John Fastabend [mailto:john.fastabend@gmail.com]
> Sent: Saturday, January 31, 2015 8:41 PM
> To: Zayats, Michael
> Cc: netdev@vger.kernel.org
> Subject: Re: AF_NETDEV - device specific sockets
>
> On 01/31/2015 08:20 PM, Zayats, Michael wrote:
>> Hi,
>>
>> I am looking for a generic mechanism that would allow network device
>> drivers to provide socket interface to user and kernel space clients.
>>
>> Such an interface might be used to provide access to important
>> sub-streams of packets, alongside with device specific packet
>> metadata, provided through msg_control fields of recv/sendmsg.
>>
>> RX Metadata might include device specific information, such as queuing
>> priorities applied, potential destination interface in case of
>> switching hardware etc.
>>
>> On the transmission, metadata might be used to indicate hardware
>> specific required optimizations, as well as any other transformation
>> or accounting required on the packet.
>>
>> AF_PACKET based mechanism doesn't allow metadata to be exchanged
>> between the client and the device driver. Extending it would require
>> extending of sk_buff and potentially additional per packet operations.
>> Generic Netlink is not intended to pass packets.
>>
>> As I am trying to validate generic applicability of such a mechanism,
>> I see that TUN driver is providing custom socket interface, in order
>> to deal with user information through msg_control. Only usable inside
>> the kernel, through custom interface.
>
>> Proposed interface
>> ------------------
>> Kernel side:
>> (struct proto *) should be added to struct net_device.
>> Device driver that is interested to support socket interface would populate the pointer.
>>
>
>> User space: After creating AF_NETDEV socket, the only successful
>> operation would be setting SO_BINDTODEVICE option. Once set, all
>> socket operations would be implemented by calling functions, that are
>> registered at struct proto on the appropriate net_device.
>>
>> What do you think?
>> Would you see a better approach?
>> Some other mechanism that already exists for such a purpose?
>
> It might help to come up with specific examples but an alternate proposal would be to use skb->priority field and then mqprio to steer the traffic to a specific queue and then bind attributes to the queue.
>
> For example the NIC offloaded QOS can be mapped on to queues and then sockets mapped to the queues.
>
> Another example would be to forward all traffic from one queue to a virtual fuction in SR-IOV use case. We don't have an interface to do this but I have been working on an API that could be used for this.
>
> In this case you don't need to modify AF_PACKET interface but configure the device correctly. If you need per-packet control you could use 'tc' or 'nftables' to do the steering.
>
> .John
>
--
John Fastabend Intel Corporation
^ permalink raw reply
* Re: [PATCH net-next v2 0/6] net: Add STT support.
From: Pravin Shelar @ 2015-02-02 18:44 UTC (permalink / raw)
To: Andy Gospodarek; +Cc: Tom Herbert, Alexander Duyck, David Miller, netdev
In-Reply-To: <20150130184446.GF13164@gospo.home.greyhouse.net>
On Fri, Jan 30, 2015 at 10:44 AM, Andy Gospodarek
<gospo@cumulusnetworks.com> wrote:
> On Thu, Jan 29, 2015 at 09:03:14PM -0800, Pravin Shelar wrote:
>> On Thu, Jan 29, 2015 at 8:17 PM, Tom Herbert <therbert@google.com> wrote:
>> > On Thu, Jan 29, 2015 at 8:04 PM, Pravin Shelar <pshelar@nicira.com> wrote:
>> >> On Thu, Jan 29, 2015 at 7:46 PM, Alexander Duyck
>> >> <alexander.duyck@gmail.com> wrote:
>> >>> On 01/29/2015 03:29 PM, Pravin B Shelar wrote:
>> >>>> Following patch series adds support for Stateless Transport
>> >>>> Tunneling protocol.
>> >>>> STT uses TCP segmentation offload available in most of NIC. On
>> >>>> packet xmit STT driver appends STT header along with TCP header
>> >>>> to the packet. For GSO packet GSO parameters are set according
>> >>>> to tunnel configuration and packet is handed over to networking
>> >>>> stack. This allows use of segmentation offload available in NICs
>> >>>>
>> >>>> The protocol is documented at
>> >>>> http://www.ietf.org/archive/id/draft-davie-stt-06.txt
>> >>>>
>> >>>> I will send out OVS userspace patch on ovs-dev mailing list.
>> >>>>
>> >>>> Following are test results. All tests are done on net-next with
>> >>>> STT and VXLAN kernel device without OVS.
>> >>>>
>> >>>> Single Netperf session:
>> >>>> =======================
>> >>>> VXLAN:
>> >>>> CPU utilization
>> >>>> - Send local: 1.26
>> >>>> - Recv remote: 8.62
>> >>>> Throughput: 4.9 Gbit/sec
>> >>>> STT:
>> >>>> CPU utilization
>> >>>> - Send local: 1.01
>> >>>> - Recv remote: 1.8
>> >>>> Throughput: 9.45 Gbit/sec
>> >>>>
>> >>>> Five Netperf sessions:
>> >>>> ======================
>> >>>> VXLAN:
>> >>>> CPU utilization
>> >>>> - Send local: 9.7
>> >>>> - Recv remote: 70 (varies from 60 to 80)
>> >>>> Throughput: 9.05 Gbit/sec
>> >>>> STT:
>> >>>> CPU utilization
>> >>>> - Send local: 5.85
>> >>>> - Recv remote: 14
>> >>>> Throughput: 9.47 Gbit/sec
>> >>>>
>> >>>
>> >>> What does the small packet or non-TCP performance look like for STT vs
>> >>> VXLAN? My concern is that STT looks like it is a one trick pony since
>> >>> all your numbers show is TCP TSO performance, and based on some of the
>> >>> comments in your patches it seems like other protocols such as UDP are
>> >>> going to suffer pretty badly due to things like the linearization overhead.
>> >>>
>> >>
>> >> Current implementation is targeted for TCP workloads thats why I
>> >> posted numbers with TCP, once UDP is optimized we can discuss UDP
>> >> numbers. I am pretty sure the STT code can be optimized further
>> >> specially for protocols other than TCP.
>> >> --
>> > There are many TCP workloads that use small packets, it is critical to
>> > test for these also. E.g. "super_netperf 200 -H <addr> -l 120 -t
>> > TCP_RR -- -r 1,1"
>> >
>> I have not tried it on STT device, I will collect those numbers.
>>
>> > Please provide the *exact* commands that you are using to configure
>> > stt for optimal performance.
>> >
>> To create STT tunnel device.
>> `ip link add stt1 type stt key 1 remote 1.1.2.128`
>>
>> No other configuration is needed.
>
> Thanks for posting some performance numbers with your patch. I also
> don't want to 'pile on' with additional complaints, but I do have one
> request.
>
> Can you share any specs (including number of cores and NIC hardware
> used) for the systems that gave you the above results? If you do not
> want to endorse a particular NIC that is fine -- I'm mostly curious how
> many cores were used and if UDP and TCP RSS were both being used in this
> configuration.
>
I used 16 core (Sandy bridge) machine with intel 10G NIC. I enabled
both UDP and TCP RSS for all tests.
^ permalink raw reply
* Re: [PATCH net-next v2 0/6] net: Add STT support.
From: Pravin Shelar @ 2015-02-02 18:44 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20150131.174037.1176748996497876060.davem@davemloft.net>
On Sat, Jan 31, 2015 at 5:40 PM, David Miller <davem@davemloft.net> wrote:
> From: Pravin B Shelar <pshelar@nicira.com>
> Date: Thu, 29 Jan 2015 15:29:16 -0800
>
>> Following patch series adds support for Stateless Transport
>> Tunneling protocol.
>> STT uses TCP segmentation offload available in most of NIC. On
>> packet xmit STT driver appends STT header along with TCP header
>> to the packet. For GSO packet GSO parameters are set according
>> to tunnel configuration and packet is handed over to networking
>> stack. This allows use of segmentation offload available in NICs
>
> I don't like this at all.
>
> Routers _absolutely_ depend upon the ability to make TCP flows back
> off by dropping packets in various ways (tail drop, RED random drops,
> etc.). STT violates this completely.
>
> It's _NOT_ TCP, you can't put lipstick on a pig and pretend it's not a
> pig. You need to use something that indicates it's flow properties,
> a datagram protocol. Either via an existing one or by creating a new
> one.
>
> I know you want to do this mass TCP behavioral violation because of
> TSO. But that's too bad. The ends do not justify the means.
>
> I also don't buy the argument that "people can put arbitrary changes
> into their kernel to do stuff like that".
>
> They can't do it to the stack I'm willing to maintain, and that's what
> matters for %99 of systems out there.
ok, I will drop patch series.
^ permalink raw reply
* Re: Throughput regression with `tcp: refine TSO autosizing`
From: Eric Dumazet @ 2015-02-02 18:52 UTC (permalink / raw)
To: Michal Kazior; +Cc: linux-wireless, Network Development, eyalpe
In-Reply-To: <CA+BoTQkV+mOZfe_Niz5101sMQeaV6muKCsShptjGQ1AgOHqqoQ@mail.gmail.com>
On Mon, 2015-02-02 at 11:27 +0100, Michal Kazior wrote:
> While testing I've had my internal GRO patch for ath10k and no stretch
> ack patches.
Thanks for the data, I took a look at it.
I am afraid this GRO patch might be the problem.
It seems to break ACK clocking badly (linux stack has a somewhat buggy
tcp_tso_should_defer(), which relies on ACK being received smoothly, as
no timer is setup to split the TSO packet.)
I am seeing huge delays on ACK packets and bursts like that :
05:01:53.413038 IP 192.168.1.2.5001 > 192.168.1.3.49669: Flags [.], ack 76745, win 4435, options [nop,nop,TS val 4294758508 ecr 4294757300], length 0
05:01:53.413407 IP 192.168.1.2.5001 > 192.168.1.3.49669: Flags [.], ack 79641, win 4435, options [nop,nop,TS val 4294758508 ecr 4294757301], length 0
05:01:53.413969 IP 192.168.1.2.5001 > 192.168.1.3.49669: Flags [.], ack 92673, win 4435, options [nop,nop,TS val 4294758510 ecr 4294757302], length 0
05:01:53.413990 IP 192.168.1.2.5001 > 192.168.1.3.49669: Flags [.], ack 97017, win 4435, options [nop,nop,TS val 4294758510 ecr 4294757302], length 0
05:01:53.414011 IP 192.168.1.2.5001 > 192.168.1.3.49669: Flags [.], ack 110049, win 4435, options [nop,nop,TS val 4294758510 ecr 4294757302], length 0
...
05:01:53.422663 IP 192.168.1.2.5001 > 192.168.1.3.49669: Flags [.], ack 189689, win 4435, options [nop,nop,TS val 4294758519 ecr 4294757310], length 0
05:01:53.424354 IP 192.168.1.2.5001 > 192.168.1.3.49669: Flags [.], ack 198377, win 4435, options [nop,nop,TS val 4294758520 ecr 4294757311], length 0
05:01:53.424400 IP 192.168.1.2.5001 > 192.168.1.3.49669: Flags [.], ack 202721, win 4435, options [nop,nop,TS val 4294758520 ecr 4294757313], length 0
05:01:53.424409 IP 192.168.1.2.5001 > 192.168.1.3.49669: Flags [.], ack 205617, win 4435, options [nop,nop,TS val 4294758520 ecr 4294757313], length 0
...
05:01:53.450248 IP 192.168.1.2.5001 > 192.168.1.3.49669: Flags [.], ack 419921, win 4435, options [nop,nop,TS val 4294758547 ecr 4294757337], length 0
05:01:53.450266 IP 192.168.1.2.5001 > 192.168.1.3.49669: Flags [.], ack 427161, win 4435, options [nop,nop,TS val 4294758547 ecr 4294757340], length 0
05:01:53.450289 IP 192.168.1.2.5001 > 192.168.1.3.49669: Flags [.], ack 431505, win 4435, options [nop,nop,TS val 4294758547 ecr 4294757340], length 0
Could you make again your experiments using upstream kernel (David
Miller net tree) ?
You also could post the GRO patch so that we can comment on it.
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