* [PATCH RFC 0/2] Multiple VLAN Registration Protocol (IEEE 802.1Q-2011)
From: David Ward @ 2012-09-24 21:07 UTC (permalink / raw)
To: netdev; +Cc: Patrick McHardy, Eric Dumazet, Philip Foulkes, David Ward
The Linux kernel currently implements the GARP VLAN Registration
Protocol (GVRP) from IEEE 802.1Q-1998 (applicant-only participant).
When the GVRP flag is set for a VLAN interface on a Linux host, the
host advertises its membership in the VLAN to the attached bridge/
switch, so that it is not necessary to manually configure the bridge/
switch port to participate in the VLAN.
GVRP has been superseded by the Multiple VLAN Registration Protocol
(MVRP) in IEEE 802.1Q-2011, which addresses scalability concerns about
the earlier protocol. The following patches add support for MVRP to
the Linux kernel and iproute2 utility. They are based largely off of
the existing implementation of GVRP, but have been modified for the
new PDU structure and state machine.
Please let me know if you have any comments. This implementation was
tested with two Juniper EX4200 switches and found to work as expected.
If you have access to other switches that implement MVRP, I would of
course welcome additional testing.
Signed-off-by: David Ward <david.ward@ll.mit.edu>
David Ward (2):
net/802: Implement Multiple Registration Protocol (MRP)
net/8021q: Implement Multiple VLAN Registration Protocol (MVRP)
include/linux/if_ether.h | 1 +
include/linux/if_vlan.h | 1 +
include/linux/netdevice.h | 2 +
include/net/mrp.h | 142 ++++++++
net/802/Kconfig | 3 +
net/802/Makefile | 1 +
net/802/mrp.c | 872 +++++++++++++++++++++++++++++++++++++++++++++
net/8021q/Kconfig | 11 +
net/8021q/Makefile | 1 +
net/8021q/vlan.c | 27 ++-
net/8021q/vlan.h | 16 +
net/8021q/vlan_dev.c | 12 +-
net/8021q/vlan_mvrp.c | 72 ++++
net/8021q/vlan_netlink.c | 2 +-
14 files changed, 1156 insertions(+), 7 deletions(-)
create mode 100644 include/net/mrp.h
create mode 100644 net/802/mrp.c
create mode 100644 net/8021q/vlan_mvrp.c
--
1.7.4.1
^ permalink raw reply
* Re: [PATCH v3] ucc_geth: Lockless xmit
From: Francois Romieu @ 2012-09-24 21:10 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: netdev
In-Reply-To: <OF39977762.2BDD4BB8-ONC1257A82.0032A26B-C1257A82.00350A53@transmode.se>
Joakim Tjernlund <joakim.tjernlund@transmode.se> :
[...]
> I don't get it. The skb test is there just for one special case, when
> the BD ring is empty the (bd_status & T_R) == 0 will be true as well so
> one need something more than the bd_status test.
Sure but the converse is not true : (bd_status & T_R) == 0 && skb does not
mean that the skb has been sent. It happens when said skb is about to be
given to the hardware by hard_start_xmit as well.
--
Ueimor
^ permalink raw reply
* Re: [PATCH net-next 3/3] vxlan: virtual extensible lan
From: Chris Wright @ 2012-09-24 21:22 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Chris Wright, David Miller, netdev
In-Reply-To: <20120924141133.3c97e9de@nehalam.linuxnetplumber.net>
* Stephen Hemminger (shemminger@vyatta.com) wrote:
> Chris Wright <chrisw@redhat.com> wrote:
> > > +/* Propogate ECN bits out */
> > > +static inline u8 vxlan_ecn_encap(u8 tos,
> > > + const struct iphdr *iph,
> > > + const struct sk_buff *skb)
> > > +{
> > > + u8 inner = vxlan_get_dsfield(iph, skb);
> > > +
> > > + return INET_ECN_encapsulate(tos, inner);
> > > +}
> >
> > Goal is to be RFC 6040 compliant, and it looks like some edge cases aren't
> > met, for example, should drop on decap when inner is not supporting ECN
> > and outer has set CE.
>
> The code was taken from existing GRE in Linux.
> Looks like both VXLAN and GRE need to handle that.
Right.
> > > +/* Callback from net/ipv4/udp.c to receive packets */
> > > + /* Mark socket as an encapsulation socket. */
> > > + udp_sk(sk)->encap_type = UDP_ENCAP_L2TPINUDP;
> >
> > I don't think we need this particular encap_type value, just != 0
>
> Is there any value in defining new value?
No, more the propagation of L2TP constant starts to look like cargo cult
programming. IOW, no special meaning in this context.
^ permalink raw reply
* Re: [PATCH net-next 3/3] vxlan: virtual extensible lan
From: Stephen Hemminger @ 2012-09-24 21:11 UTC (permalink / raw)
To: Chris Wright; +Cc: David Miller, netdev
In-Reply-To: <20120924205822.GI26494@x200.localdomain>
On Mon, 24 Sep 2012 13:58:22 -0700
Chris Wright <chrisw@redhat.com> wrote:
> * Stephen Hemminger (shemminger@vyatta.com) wrote:
> > This is an implementation of Virtual eXtensible Local Area Network
> > as described in draft RFC:
> > http://tools.ietf.org/html/draft-mahalingam-dutt-dcops-vxlan-02
> >
> > The driver integrates a Virtual Tunnel Endpoint (VTEP) functionality
> > that learns MAC to IP address mapping.
> >
> > This implementation has not been tested for Interoperation with
> > other equipment.
>
> I'm working on doing some interop
>
> > --- a/drivers/net/Kconfig 2012-09-24 10:56:57.080291529 -0700
> > +++ b/drivers/net/Kconfig 2012-09-24 11:08:02.865416523 -0700
> > @@ -149,6 +149,19 @@ config MACVTAP
> > To compile this driver as a module, choose M here: the module
> > will be called macvtap.
> >
> > +config VXLAN
> > + tristate "Virtual eXtensible Local Area Network (VXLAN)"
> > + depends on EXPERIMENTAL
> > + ---help---
> > + This allows one to create vxlan virtual interfaces that provide
> > + Layer 2 Networks over Layer 3 Networks. VXLAN is often used
> > + to tunnel virtual network infrastructure in virtualized environments.
> > + For more information see:
> > + http://tools.ietf.org/html/draft-mahalingam-dutt-dcops-vxlan-02
> > +
> > + To compile this driver as a module, choose M here: the module
> > + will be called macvlan.
> ^^^^^^^
> Cut 'n paste error, s/macvlan/vxlan/
>
> > +/* Add static entry (via netlink) */
> > +static int vxlan_fdb_add(struct ndmsg *ndm, struct nlattr *tb[],
> > + struct net_device *dev,
> > + const unsigned char *addr, u16 flags)
> > +{
> > + struct vxlan_dev *vxlan = netdev_priv(dev);
> > + __be32 ip;
> > + int err;
> > +
> > + if (tb[NDA_DST] == NULL)
> > + return -EINVAL;
> > +
> > + if (nla_len(tb[NDA_DST]) != sizeof(__be32))
> > + return -EAFNOSUPPORT;
> > +
> > + ip = nla_get_be32(tb[NDA_DST]);
> > +
> > + spin_lock_bh(&vxlan->hash_lock);
> > + err = vxlan_fdb_create(vxlan, addr, ip, VXLAN_FDB_PERM);
>
> Any reason to force permanent when created from userspace?
Should use neighbour flag (NUD_PERMANENT) instead.
>
> > +static bool vxlan_group_used(struct vxlan_net *vn,
> > + const struct vxlan_dev *this)
> > +{
> > + const struct vxlan_dev *vxlan;
> > + struct hlist_node *node;
> > + unsigned h;
> > +
> > + for (h = 0; h < VNI_HASH_SIZE; ++h)
> > + hlist_for_each_entry(vxlan, node, &vn->vni_list[h], hlist) {
>
> is walking this chain only protected with rtnl?
Yes. that should be enough, only used when creating new vxlan
to avoid joining same group twice.
>
> > +/* Propogate ECN from outer IP header to tunneled packet */
> > +static inline void vxlan_ecn_decap(const struct iphdr *iph, struct sk_buff *skb)
> > +{
> > + if (INET_ECN_is_ce(iph->tos)) {
> > + if (skb->protocol == htons(ETH_P_IP))
> > + IP_ECN_set_ce(ip_hdr(skb));
> > + else if (skb->protocol == htons(ETH_P_IPV6))
> > + IP6_ECN_set_ce(ipv6_hdr(skb));
> > + }
> > +}
> <snip>
> > +/* Propogate ECN bits out */
> > +static inline u8 vxlan_ecn_encap(u8 tos,
> > + const struct iphdr *iph,
> > + const struct sk_buff *skb)
> > +{
> > + u8 inner = vxlan_get_dsfield(iph, skb);
> > +
> > + return INET_ECN_encapsulate(tos, inner);
> > +}
>
> Goal is to be RFC 6040 compliant, and it looks like some edge cases aren't
> met, for example, should drop on decap when inner is not supporting ECN
> and outer has set CE.
The code was taken from existing GRE in Linux.
Looks like both VXLAN and GRE need to handle that.
>
> <snip>
> > +/* Callback from net/ipv4/udp.c to receive packets */
> > + /* Mark socket as an encapsulation socket. */
> > + udp_sk(sk)->encap_type = UDP_ENCAP_L2TPINUDP;
>
> I don't think we need this particular encap_type value, just != 0
Is there any value in defining new value?
>
> > + udp_sk(sk)->encap_rcv = vxlan_udp_encap_recv;
> > + udp_encap_enable();
^ permalink raw reply
* Re: [PATCH net-next] filter: add XOR instruction for use with X/K
From: Daniel Borkmann @ 2012-09-24 21:02 UTC (permalink / raw)
To: David Miller; +Cc: eric.dumazet, netdev
In-Reply-To: <20120924.165005.1246466996061307302.davem@davemloft.net>
David Miller <davem@davemloft.net> [2012-09-24 16:50:05 -0400] wrote:
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Mon, 24 Sep 2012 15:43:48 +0200
> > On Mon, 2012-09-24 at 14:23 +0200, Daniel Borkmann wrote:
> >> BPF_S_ANC_ALU_XOR_X has been added a while ago, but as an 'ancillary'
> >> operation that is invoked through a negative offset in K within BPF
> >> load operations. Since BPF_MOD has recently been added, BPF_XOR should
> >> also be part of the common ALU operations. Removing BPF_S_ANC_ALU_XOR_X
> >> might not be an option since this is exposed to user space.
> >
> > Please note we dont expose BPF_S_ANC_ALU_XOR_X to user space.
> >
> > We expose SKF_AD_ALU_XOR_X instead.
> >
> > But it seems easier to leave it to keep this patch small (not touching
> > various JIT implementations, even if followup are welcomed)
> >
> > Acked-by: Eric Dumazet <edumazet@google.com>
>
> I applied this, fixing the commit message to refer to SKF_AD_ALU_XOR_X
> instead of BPF_S_ANC_ALU_XOR_X.
Thanks David!
^ permalink raw reply
* Re: kernel BUG at kernel/timer.c:748!
From: Eric Dumazet @ 2012-09-24 21:01 UTC (permalink / raw)
To: David Miller; +Cc: davej, ycheng, ja, netdev
In-Reply-To: <20120924.165307.848844032342514886.davem@davemloft.net>
On Mon, 2012-09-24 at 16:53 -0400, David Miller wrote:
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Mon, 24 Sep 2012 19:00:11 +0200
>
> > Signed-off-by: Eric Dumazet <edumazet@google.com>
>
> I know you meant "From: Eric Dumazet <edumazet@google.com>"
> here :-)
Oh well, I should use some automatic tool ;)
Thanks
^ permalink raw reply
* Re: [PATCH net-next 3/3] vxlan: virtual extensible lan
From: Chris Wright @ 2012-09-24 20:58 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Miller, Chris Wright, netdev
In-Reply-To: <20120924185050.162920909@vyatta.com>
* Stephen Hemminger (shemminger@vyatta.com) wrote:
> This is an implementation of Virtual eXtensible Local Area Network
> as described in draft RFC:
> http://tools.ietf.org/html/draft-mahalingam-dutt-dcops-vxlan-02
>
> The driver integrates a Virtual Tunnel Endpoint (VTEP) functionality
> that learns MAC to IP address mapping.
>
> This implementation has not been tested for Interoperation with
> other equipment.
I'm working on doing some interop
> --- a/drivers/net/Kconfig 2012-09-24 10:56:57.080291529 -0700
> +++ b/drivers/net/Kconfig 2012-09-24 11:08:02.865416523 -0700
> @@ -149,6 +149,19 @@ config MACVTAP
> To compile this driver as a module, choose M here: the module
> will be called macvtap.
>
> +config VXLAN
> + tristate "Virtual eXtensible Local Area Network (VXLAN)"
> + depends on EXPERIMENTAL
> + ---help---
> + This allows one to create vxlan virtual interfaces that provide
> + Layer 2 Networks over Layer 3 Networks. VXLAN is often used
> + to tunnel virtual network infrastructure in virtualized environments.
> + For more information see:
> + http://tools.ietf.org/html/draft-mahalingam-dutt-dcops-vxlan-02
> +
> + To compile this driver as a module, choose M here: the module
> + will be called macvlan.
^^^^^^^
Cut 'n paste error, s/macvlan/vxlan/
> +/* Add static entry (via netlink) */
> +static int vxlan_fdb_add(struct ndmsg *ndm, struct nlattr *tb[],
> + struct net_device *dev,
> + const unsigned char *addr, u16 flags)
> +{
> + struct vxlan_dev *vxlan = netdev_priv(dev);
> + __be32 ip;
> + int err;
> +
> + if (tb[NDA_DST] == NULL)
> + return -EINVAL;
> +
> + if (nla_len(tb[NDA_DST]) != sizeof(__be32))
> + return -EAFNOSUPPORT;
> +
> + ip = nla_get_be32(tb[NDA_DST]);
> +
> + spin_lock_bh(&vxlan->hash_lock);
> + err = vxlan_fdb_create(vxlan, addr, ip, VXLAN_FDB_PERM);
Any reason to force permanent when created from userspace?
> +static bool vxlan_group_used(struct vxlan_net *vn,
> + const struct vxlan_dev *this)
> +{
> + const struct vxlan_dev *vxlan;
> + struct hlist_node *node;
> + unsigned h;
> +
> + for (h = 0; h < VNI_HASH_SIZE; ++h)
> + hlist_for_each_entry(vxlan, node, &vn->vni_list[h], hlist) {
is walking this chain only protected with rtnl?
> +/* Propogate ECN from outer IP header to tunneled packet */
> +static inline void vxlan_ecn_decap(const struct iphdr *iph, struct sk_buff *skb)
> +{
> + if (INET_ECN_is_ce(iph->tos)) {
> + if (skb->protocol == htons(ETH_P_IP))
> + IP_ECN_set_ce(ip_hdr(skb));
> + else if (skb->protocol == htons(ETH_P_IPV6))
> + IP6_ECN_set_ce(ipv6_hdr(skb));
> + }
> +}
<snip>
> +/* Propogate ECN bits out */
> +static inline u8 vxlan_ecn_encap(u8 tos,
> + const struct iphdr *iph,
> + const struct sk_buff *skb)
> +{
> + u8 inner = vxlan_get_dsfield(iph, skb);
> +
> + return INET_ECN_encapsulate(tos, inner);
> +}
Goal is to be RFC 6040 compliant, and it looks like some edge cases aren't
met, for example, should drop on decap when inner is not supporting ECN
and outer has set CE.
<snip>
> +/* Callback from net/ipv4/udp.c to receive packets */
> + /* Mark socket as an encapsulation socket. */
> + udp_sk(sk)->encap_type = UDP_ENCAP_L2TPINUDP;
I don't think we need this particular encap_type value, just != 0
> + udp_sk(sk)->encap_rcv = vxlan_udp_encap_recv;
> + udp_encap_enable();
^ permalink raw reply
* Re: [PATCH net-next] x86: bpf_jit_comp: add XOR instruction for BPF JIT
From: David Miller @ 2012-09-24 20:55 UTC (permalink / raw)
To: eric.dumazet; +Cc: dxchgb, netdev
In-Reply-To: <1348508647.26828.1300.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 24 Sep 2012 19:44:07 +0200
> On Mon, 2012-09-24 at 19:34 +0200, Daniel Borkmann wrote:
>> This patch is a follow-up for patch "filter: add XOR instruction for use
>> with X/K" that implements BPF x86 JIT parts for the BPF XOR operation.
>>
>> Signed-off-by: Daniel Borkmann <daniel.borkmann@tik.ee.ethz.ch>
>> ---
>> arch/x86/net/bpf_jit_comp.c | 9 +++++++++
>> 1 files changed, 9 insertions(+), 0 deletions(-)
>
> Acked-by: Eric Dumazet <edumazet@google.com>
Applied, thanks everyone.
^ permalink raw reply
* Re: kernel BUG at kernel/timer.c:748!
From: David Miller @ 2012-09-24 20:53 UTC (permalink / raw)
To: davej; +Cc: eric.dumazet, ycheng, ja, netdev
In-Reply-To: <20120924181152.GA31183@redhat.com>
From: Dave Jones <davej@redhat.com>
Date: Mon, 24 Sep 2012 14:11:52 -0400
> tangent: Is there any kind of networking correctness suite
> other than fuzz testers like isic etc ?
If people want to work on this I'm willing to maintain the
tree.
^ permalink raw reply
* Re: kernel BUG at kernel/timer.c:748!
From: David Miller @ 2012-09-24 20:53 UTC (permalink / raw)
To: eric.dumazet; +Cc: davej, ycheng, ja, netdev
In-Reply-To: <1348506011.26828.1195.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 24 Sep 2012 19:00:11 +0200
> Signed-off-by: Eric Dumazet <edumazet@google.com>
I know you meant "From: Eric Dumazet <edumazet@google.com>"
here :-)
> [PATCH] net: guard tcp_set_keepalive() to tcp sockets
>
> Its possible to use RAW sockets to get a crash in
> tcp_set_keepalive() / sk_reset_timer()
>
> Fix is to make sure socket is a SOCK_STREAM one.
>
> Reported-by: Dave Jones <davej@redhat.com>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied and queued up for -stable, thanks Eric.
^ permalink raw reply
* Re: [PATCH net-next] filter: add XOR instruction for use with X/K
From: David Miller @ 2012-09-24 20:50 UTC (permalink / raw)
To: eric.dumazet; +Cc: dxchgb, netdev
In-Reply-To: <1348494228.26828.784.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 24 Sep 2012 15:43:48 +0200
> On Mon, 2012-09-24 at 14:23 +0200, Daniel Borkmann wrote:
>> BPF_S_ANC_ALU_XOR_X has been added a while ago, but as an 'ancillary'
>> operation that is invoked through a negative offset in K within BPF
>> load operations. Since BPF_MOD has recently been added, BPF_XOR should
>> also be part of the common ALU operations. Removing BPF_S_ANC_ALU_XOR_X
>> might not be an option since this is exposed to user space.
>
> Please note we dont expose BPF_S_ANC_ALU_XOR_X to user space.
>
> We expose SKF_AD_ALU_XOR_X instead.
>
> But it seems easier to leave it to keep this patch small (not touching
> various JIT implementations, even if followup are welcomed)
>
> Acked-by: Eric Dumazet <edumazet@google.com>
I applied this, fixing the commit message to refer to SKF_AD_ALU_XOR_X
instead of BPF_S_ANC_ALU_XOR_X.
^ permalink raw reply
* Re: [PATCH] net: mipsnet: Remove the MIPSsim Ethernet driver.
From: David Miller @ 2012-09-24 20:41 UTC (permalink / raw)
To: sjhill; +Cc: linux-mips, netdev, ralf
In-Reply-To: <1348498036-30257-1-git-send-email-sjhill@mips.com>
From: "Steven J. Hill" <sjhill@mips.com>
Date: Mon, 24 Sep 2012 09:47:16 -0500
> From: "Steven J. Hill" <sjhill@mips.com>
>
> The MIPSsim platform is no longer supported or used. This patch
> deletes the Ethernet driver.
>
> Signed-off-by: Steven J. Hill <sjhill@mips.com>
I'll apply this to net-next, thanks.
^ permalink raw reply
* Re: [PATCHv2 net-next 3/3] vxlan: virtual extensible lan
From: Eric Dumazet @ 2012-09-24 20:41 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Miller, Chris Wright, netdev
In-Reply-To: <20120924132637.17d89210@nehalam.linuxnetplumber.net>
On Mon, 2012-09-24 at 13:26 -0700, Stephen Hemminger wrote:
> On Mon, 24 Sep 2012 22:09:50 +0200
> Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
> >
> > I am not sure why you remove IFF_XMIT_DST_RELEASE here
>
> Copied from GRE. What is impact either way?
GRE needs skb_dst(skb) to be non NULL if tiph->daddr == NULL
but I am not sure your code needs this.
This is a performance issue, for packets waiting in a Qdisc : we'll need
to force a reference (and a cache line false sharing)
^ permalink raw reply
* Re: [PATCH net-next v3] net: use a per task frag allocator
From: David Miller @ 2012-09-24 20:39 UTC (permalink / raw)
To: eric.dumazet; +Cc: subramanian.vijay, netdev, bhutchings, alexander.h.duyck
In-Reply-To: <1348477482.26828.235.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 24 Sep 2012 11:04:42 +0200
> From: Eric Dumazet <edumazet@google.com>
>
> We currently use a per socket order-0 page cache for tcp_sendmsg()
> operations.
>
> This page is used to build fragments for skbs.
>
> Its done to increase probability of coalescing small write() into
> single segments in skbs still in write queue (not yet sent)
>
> But it wastes a lot of memory for applications handling many mostly
> idle sockets, since each socket holds one page in sk->sk_sndmsg_page
>
> Its also quite inefficient to build TSO 64KB packets, because we need
> about 16 pages per skb on arches where PAGE_SIZE = 4096, so we hit
> page allocator more than wanted.
>
> This patch adds a per task frag allocator and uses bigger pages,
> if available. An automatic fallback is done in case of memory pressure.
>
> (up to 32768 bytes per frag, thats order-3 pages on x86)
>
> This increases TCP stream performance by 20% on loopback device,
> but also benefits on other network devices, since 8x less frags are
> mapped on transmit and unmapped on tx completion. Alexander Duyck
> mentioned a probable performance win on systems with IOMMU enabled.
>
> Its possible some SG enabled hardware cant cope with bigger fragments,
> but their ndo_start_xmit() should already handle this, splitting a
> fragment in sub fragments, since some arches have PAGE_SIZE=65536
>
> Successfully tested on various ethernet devices.
> (ixgbe, igb, bnx2x, tg3, mellanox mlx4)
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
I'm going to apply this, nice work Eric.
I'll also take care of the trailing whitespace pointed out by others.
Thanks again.
^ permalink raw reply
* Re: [PATCH net-net] net: loopback: set default mtu to 64K
From: David Miller @ 2012-09-24 20:38 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1348518796.26828.1651.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 24 Sep 2012 22:33:16 +0200
> On Mon, 2012-09-24 at 16:24 -0400, David Miller wrote:
>> From: Eric Dumazet <eric.dumazet@gmail.com>
>> Date: Mon, 24 Sep 2012 10:28:59 +0200
>>
>> > From: Eric Dumazet <edumazet@google.com>
>> >
>> > loopback current mtu of 16436 bytes allows no more than 3 MSS TCP
>> > segments per frame, or 48 Kbytes. Changing mtu to 64K allows TCP
>> > stack to build large frames and significantly reduces stack overhead.
>> >
>> > Performance boost on bulk TCP transferts can be up to 30 %, partly
>> > because we now have one ACK message for two 64KB segments, and a lower
>> > probability of hitting /proc/sys/net/ipv4/tcp_reordering default limit.
>> >
>> > Signed-off-by: Eric Dumazet <edumazet@google.com>
>>
>> This gives a nice %13 improvement on my SPARC-T4 box as well.
>>
>> Applied, thanks Eric.
>
> the biggest increase is with
>
> netperf -- -m 63K
>
> I reach 50000 Mbytes/second
I tested with lmbench bw_tcp, which gives me about 1308 MB/sec.
And indeed that netperf command line gives superior numbers,
about 11747 MB/sec
^ permalink raw reply
* Re: [PATCH net-net] net: loopback: set default mtu to 64K
From: Eric Dumazet @ 2012-09-24 20:33 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20120924.162442.1381532664983403691.davem@redhat.com>
On Mon, 2012-09-24 at 16:24 -0400, David Miller wrote:
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Mon, 24 Sep 2012 10:28:59 +0200
>
> > From: Eric Dumazet <edumazet@google.com>
> >
> > loopback current mtu of 16436 bytes allows no more than 3 MSS TCP
> > segments per frame, or 48 Kbytes. Changing mtu to 64K allows TCP
> > stack to build large frames and significantly reduces stack overhead.
> >
> > Performance boost on bulk TCP transferts can be up to 30 %, partly
> > because we now have one ACK message for two 64KB segments, and a lower
> > probability of hitting /proc/sys/net/ipv4/tcp_reordering default limit.
> >
> > Signed-off-by: Eric Dumazet <edumazet@google.com>
>
> This gives a nice %13 improvement on my SPARC-T4 box as well.
>
> Applied, thanks Eric.
the biggest increase is with
netperf -- -m 63K
I reach 50000 Mbytes/second
^ permalink raw reply
* Re: [RFC PATCHv2 bridge 7/7] bridge: Add the ability to show dump the vlan map from a bridge port
From: Vlad Yasevich @ 2012-09-24 20:29 UTC (permalink / raw)
To: Ben Hutchings; +Cc: Stephen Hemminger, David Miller, netdev
In-Reply-To: <1348511955.10741.4.camel@deadeye.wl.decadent.org.uk>
On 09/24/2012 02:39 PM, Ben Hutchings wrote:
> On Mon, 2012-09-24 at 09:49 -0400, Vlad Yasevich wrote:
>> On 09/22/2012 04:05 PM, Stephen Hemminger wrote:
>>> On Sat, 22 Sep 2012 13:27:47 -0400 (EDT)
>>> David Miller <davem@davemloft.net> wrote:
>>>
>>>> From: Ben Hutchings <bhutchings@solarflare.com>
>>>> Date: Sat, 22 Sep 2012 18:15:32 +0100
>>>>
>>>>> On Wed, 2012-09-19 at 08:42 -0400, Vlad Yasevich wrote:
>>>>>> Using the RTM_GETLINK dump the vlan map of a given bridge port.
>>>>> [...]
>>>>>
>>>>> This enlarges the RTM_GETLINK response quite a bit. I think perhaps
>>>>> this should be optional, like IFLA_VFINFO_LIST is now.
>>>>
>>>> Completely agreed.
>>>
>>> Since most users won't use it, it should be not necessary to include
>>> it if the map is blank.
>>>
>>
>> Response is included only for AF_BRIDGE calls (proably used by STP
>> implementation) and only when vlan filtering is configured.
>>
>> I do see the point though and can add a filter for this.
>
> I thought the per-AF stuff was included by default (or at least what
> most clients ask for). If not then this is probably fine.
> IFLA_VFINFO_LIST was causing glibc's queries to fail and that must be
> avoided.
>
> Ben.
>
Not just that. This is a PF_BRIDGE family request. Note the
err = __rtnl_register(PF_BRIDGE, RTM_GETLINK, NULL,
br_dump_ifinfo, NULL);
in br_netlink_init.
-vlad
^ permalink raw reply
* Re: [PATCHv3 net-next 3/3] vxlan: virtual extensible lan
From: Stephen Hemminger @ 2012-09-24 20:27 UTC (permalink / raw)
To: John Fastabend; +Cc: Eric Dumazet, David Miller, Chris Wright, netdev
In-Reply-To: <5060C189.8090803@intel.com>
On Mon, 24 Sep 2012 13:24:41 -0700
John Fastabend <john.r.fastabend@intel.com> wrote:
> [...]
>
> On 9/24/2012 1:02 PM, Stephen Hemminger wrote:
> > +
> > +/* Transmit local packets over Vxlan
> > + *
> > + * Outer IP header inherits ECN and DF from inner header.
> > + * Outer UDP destination is the VXLAN assigned port.
> > + * source port is based on hash of flow if available
> > + * otherwise use a random value
> > + */
> > +static netdev_tx_t vxlan_xmit(struct sk_buff *skb, struct net_device *dev)
> > +{
> > + struct vxlan_dev *vxlan = netdev_priv(dev);
> > + struct rtable *rt;
> > + const struct ethhdr *eth;
> > + const struct iphdr *old_iph;
> > + struct iphdr *iph;
> > + struct vxlanhdr *vxh;
> > + struct udphdr *uh;
> > + struct flowi4 fl4;
> > + struct vxlan_fdb *f;
> > + unsigned int pkt_len = skb->len;
> > + unsigned int mtu;
> > + u32 hash;
> > + __be32 dst;
> > + __be16 df = 0;
> > + __u8 tos, ttl;
> > + int err;
> > +
>
> [...]
>
> > + err = ip_local_out(skb);
> > + if (likely(net_xmit_eval(err) == 0)) {
> > + struct vxlan_stats *stats = this_cpu_ptr(vxlan->stats);
> > +
> > + u64_stats_update_begin(&stats->syncp);
> > + stats->tx_packets++;
> > + stats->tx_bytes += pkt_len;
>
> Should pkt_len include the outer headers?
It doesn't for GRE and related tunnels.
^ permalink raw reply
* Re: [PATCHv2 net-next 3/3] vxlan: virtual extensible lan
From: Stephen Hemminger @ 2012-09-24 20:26 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, Chris Wright, netdev
In-Reply-To: <1348517390.26828.1601.camel@edumazet-glaptop>
On Mon, 24 Sep 2012 22:09:50 +0200
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Mon, 2012-09-24 at 12:46 -0700, Stephen Hemminger wrote:
>
> > +/* Initialize the device structure. */
> > +static void vxlan_setup(struct net_device *dev)
> > +{
> > + struct vxlan_dev *vxlan = netdev_priv(dev);
> > + unsigned h;
> > +
> > + eth_hw_addr_random(dev);
> > + ether_setup(dev);
> > +
> > + dev->netdev_ops = &vxlan_netdev_ops;
> > + dev->destructor = vxlan_free;
> > + SET_NETDEV_DEVTYPE(dev, &vxlan_type);
> > +
> > + dev->tx_queue_len = 0;
> > + dev->features |= NETIF_F_LLTX;
> > + dev->features |= NETIF_F_NETNS_LOCAL;
> > + dev->priv_flags &= ~IFF_XMIT_DST_RELEASE;
>
> I am not sure why you remove IFF_XMIT_DST_RELEASE here
Copied from GRE. What is impact either way?
^ permalink raw reply
* Re: [PATCH net-next v1] gianfar: Change default HW Tx queue scheduling mode
From: David Miller @ 2012-09-24 20:25 UTC (permalink / raw)
To: claudiu.manoil; +Cc: netdev, paul.gortmaker
In-Reply-To: <1348475948-22721-1-git-send-email-claudiu.manoil@freescale.com>
From: Claudiu Manoil <claudiu.manoil@freescale.com>
Date: Mon, 24 Sep 2012 11:39:08 +0300
> This is primarily to address transmission timeout occurrences, when
> multiple H/W Tx queues are being used concurrently. Because in
> the priority scheduling mode the controller does not service the
> Tx queues equally (but in ascending index order), Tx timeouts are
> being triggered rightaway for a basic test with multiple simultaneous
> connections like:
> iperf -c <server_ip> -n 100M -P 8
>
> resulting in kernel trace:
> NETDEV WATCHDOG: eth1 (fsl-gianfar): transmit queue <X> timed out
> ------------[ cut here ]------------
> WARNING: at net/sched/sch_generic.c:255
> ...
> and controller reset during intense traffic, and possibly further
> complications.
>
> This patch changes the default H/W Tx scheduling setting (TXSCHED)
> for multi-queue devices, from priority scheduling mode to a weighted
> round robin mode with equal weights for all H/W Tx queues, and
> addresses the issue above.
>
> Signed-off-by: Claudiu Manoil <claudiu.manoil@freescale.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCHv3 net-next 3/3] vxlan: virtual extensible lan
From: John Fastabend @ 2012-09-24 20:24 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Eric Dumazet, David Miller, Chris Wright, netdev
In-Reply-To: <20120924130239.18767146@nehalam.linuxnetplumber.net>
[...]
On 9/24/2012 1:02 PM, Stephen Hemminger wrote:
> +
> +/* Transmit local packets over Vxlan
> + *
> + * Outer IP header inherits ECN and DF from inner header.
> + * Outer UDP destination is the VXLAN assigned port.
> + * source port is based on hash of flow if available
> + * otherwise use a random value
> + */
> +static netdev_tx_t vxlan_xmit(struct sk_buff *skb, struct net_device *dev)
> +{
> + struct vxlan_dev *vxlan = netdev_priv(dev);
> + struct rtable *rt;
> + const struct ethhdr *eth;
> + const struct iphdr *old_iph;
> + struct iphdr *iph;
> + struct vxlanhdr *vxh;
> + struct udphdr *uh;
> + struct flowi4 fl4;
> + struct vxlan_fdb *f;
> + unsigned int pkt_len = skb->len;
> + unsigned int mtu;
> + u32 hash;
> + __be32 dst;
> + __be16 df = 0;
> + __u8 tos, ttl;
> + int err;
> +
[...]
> + err = ip_local_out(skb);
> + if (likely(net_xmit_eval(err) == 0)) {
> + struct vxlan_stats *stats = this_cpu_ptr(vxlan->stats);
> +
> + u64_stats_update_begin(&stats->syncp);
> + stats->tx_packets++;
> + stats->tx_bytes += pkt_len;
Should pkt_len include the outer headers?
> + u64_stats_update_end(&stats->syncp);
> + } else {
> + dev->stats.tx_errors++;
> + dev->stats.tx_aborted_errors++;
> + }
> + return NETDEV_TX_OK;
> +
> +drop:
> + dev->stats.tx_dropped++;
> + goto tx_free;
> +
> +tx_error:
> + dev->stats.tx_errors++;
> +tx_free:
> + dev_kfree_skb(skb);
> + return NETDEV_TX_OK;
> +}
^ permalink raw reply
* Re: [PATCH net-net] net: loopback: set default mtu to 64K
From: David Miller @ 2012-09-24 20:24 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1348475339.26828.188.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 24 Sep 2012 10:28:59 +0200
> From: Eric Dumazet <edumazet@google.com>
>
> loopback current mtu of 16436 bytes allows no more than 3 MSS TCP
> segments per frame, or 48 Kbytes. Changing mtu to 64K allows TCP
> stack to build large frames and significantly reduces stack overhead.
>
> Performance boost on bulk TCP transferts can be up to 30 %, partly
> because we now have one ACK message for two 64KB segments, and a lower
> probability of hitting /proc/sys/net/ipv4/tcp_reordering default limit.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
This gives a nice %13 improvement on my SPARC-T4 box as well.
Applied, thanks Eric.
^ permalink raw reply
* RE: [PATCH 1/26 v3] rdma/cm: define native IB address
From: Hefty, Sean @ 2012-09-24 20:20 UTC (permalink / raw)
To: David Miller
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <20120924.161641.1251385747585210916.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
> I really hope you're not going to only post this one patch of the
> series to netdev, and leave netdev out completely for the rest.
I will happily resend the series with netdev copied. All other changes are limited to the rdma stack.
- Sean
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/26 v3] rdma/cm: define native IB address
From: David Miller @ 2012-09-24 20:16 UTC (permalink / raw)
To: sean.hefty-ral2JQCrhuEAvxtiuMwx3w
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1828884A29C6694DAF28B7E6B8A8237346A8EE07-P5GAC/sN6hmkrb+BlOpmy7fspsVTdybXVpNB7YpNyf8@public.gmane.org>
I really hope you're not going to only post this one patch of the
series to netdev, and leave netdev out completely for the rest.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" 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: [PATCHv2 net-next 3/3] vxlan: virtual extensible lan
From: Eric Dumazet @ 2012-09-24 20:09 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Miller, Chris Wright, netdev
In-Reply-To: <20120924124657.4541c186@nehalam.linuxnetplumber.net>
On Mon, 2012-09-24 at 12:46 -0700, Stephen Hemminger wrote:
> +/* Initialize the device structure. */
> +static void vxlan_setup(struct net_device *dev)
> +{
> + struct vxlan_dev *vxlan = netdev_priv(dev);
> + unsigned h;
> +
> + eth_hw_addr_random(dev);
> + ether_setup(dev);
> +
> + dev->netdev_ops = &vxlan_netdev_ops;
> + dev->destructor = vxlan_free;
> + SET_NETDEV_DEVTYPE(dev, &vxlan_type);
> +
> + dev->tx_queue_len = 0;
> + dev->features |= NETIF_F_LLTX;
> + dev->features |= NETIF_F_NETNS_LOCAL;
> + dev->priv_flags &= ~IFF_XMIT_DST_RELEASE;
I am not sure why you remove IFF_XMIT_DST_RELEASE here
^ 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