* Re: [RFC PATCH 00/24] TRILL implementation
From: Cong Wang @ 2014-09-24 17:24 UTC (permalink / raw)
To: William Dauchy
Cc: Stephen Hemminger, Ahmed Amamou, netdev, f.cachereul,
Fengguang Wu
In-Reply-To: <20140924165447.GG27183@gandi.net>
On Wed, Sep 24, 2014 at 9:54 AM, William Dauchy <william@gandi.net> wrote:
> On Sep24 09:44, Stephen Hemminger wrote:
>> Is this patch series bisectable? does it build at each step?
>
> it should be the case but we will double check that.
>
You can ask Fengguang to add your repo to his kbuild bot,
I am sure it can catch much more than we do. :)
^ permalink raw reply
* Re: [PATCH v1 4/5] drivers: net: xgene: Add 10GbE support
From: Iyappan Subramanian @ 2014-09-24 17:24 UTC (permalink / raw)
To: Arnd Bergmann
Cc: David Miller, netdev, devicetree@vger.kernel.org, Keyur Chudgar,
patches
In-Reply-To: <7752137.3u6F6qDtIo@wuerfel>
Hi Arnd,
On Wed, Sep 24, 2014 at 6:10 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Tuesday 23 September 2014 20:51:27 Iyappan Subramanian wrote:
>> -static void xgene_enet_wr_mcx_mac(struct xgene_enet_pdata *pdata,
>> - u32 wr_addr, u32 wr_data)
>> +void xgene_enet_wr_mac(struct xgene_enet_pdata *pdata, u32 wr_addr, u32 wr_data)
>> {
>> void __iomem *addr, *wr, *cmd, *cmd_done;
>>
>> - addr = pdata->mcx_mac_addr + MAC_ADDR_REG_OFFSET;
>> - wr = pdata->mcx_mac_addr + MAC_WRITE_REG_OFFSET;
>> - cmd = pdata->mcx_mac_addr + MAC_COMMAND_REG_OFFSET;
>> - cmd_done = pdata->mcx_mac_addr + MAC_COMMAND_DONE_REG_OFFSET;
>> + addr = pdata->mac_addr + MAC_ADDR_REG_OFFSET;
>> + wr = pdata->mac_addr + MAC_WRITE_REG_OFFSET;
>> + cmd = pdata->mac_addr + MAC_COMMAND_REG_OFFSET;
>> + cmd_done = pdata->mac_addr + MAC_COMMAND_DONE_REG_OFFSET;
>>
>> if (!xgene_enet_wr_indirect(addr, wr, cmd, cmd_done, wr_addr, wr_data))
>> netdev_err(pdata->ndev, "MCX mac write failed, addr: %04x\n",
>> wr_addr);
>> }
>>
>> -static void xgene_enet_rd_csr(struct xgene_enet_pdata *pdata,
>> - u32 offset, u32 *val)
>> +void xgene_enet_rd_csr(struct xgene_enet_pdata *pdata, u32 offset, u32 *val)
>> {
>> void __iomem *addr = pdata->eth_csr_addr + offset;
>>
>>
>
> A lot of the changes in this patch seem to just rename existing interfaces.
> Please split those out into a preparatory patch, to make it easier to
> review the actual functional changes.
Sure. I will do as you suggest. Thanks for the review.
>
> Arnd
> CONFIDENTIALITY NOTICE: This e-mail message, including any attachments,
> is for the sole use of the intended recipient(s) and contains information
> that is confidential and proprietary to Applied Micro Circuits Corporation or its subsidiaries.
> It is to be used solely for the purpose of furthering the parties' business relationship.
> All unauthorized review, use, disclosure or distribution is prohibited.
> If you are not the intended recipient, please contact the sender by reply e-mail
> and destroy all copies of the original message.
>
^ permalink raw reply
* Re: [RFC PATCH 01/24] net: rbridge: add trill frame description
From: Cong Wang @ 2014-09-24 17:26 UTC (permalink / raw)
To: William Dauchy
Cc: Stephen Hemminger, Ahmed Amamou, netdev, f.cachereul,
Emmanuel Hocdet, Kamel Haddadou
In-Reply-To: <20140924164828.GF27183@gandi.net>
On Wed, Sep 24, 2014 at 9:48 AM, William Dauchy <william@gandi.net> wrote:
>> Did you even run this through checkpatch?
>
> no but we will.
>
At least the comment style is not what DaveM prefers.
Please take a look at netdev-FAQ.txt.
^ permalink raw reply
* Re: [RFC PATCH 00/24] TRILL implementation
From: William Dauchy @ 2014-09-24 17:33 UTC (permalink / raw)
To: Cong Wang
Cc: William Dauchy, Stephen Hemminger, Ahmed Amamou, netdev,
f.cachereul, Fengguang Wu
In-Reply-To: <CAHA+R7MmcxKK2F3y7tkHxD7ZvK+WkJDevLz=vOEr6QScngBkbw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 257 bytes --]
On Sep24 10:24, Cong Wang wrote:
> You can ask Fengguang to add your repo to his kbuild bot,
> I am sure it can catch much more than we do. :)
ok; give us some time so we can send a branch somewhere with these patch
version.
Thanks,
--
William
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [RFC PATCH 01/24] net: rbridge: add trill frame description
From: William Dauchy @ 2014-09-24 17:34 UTC (permalink / raw)
To: Cong Wang
Cc: William Dauchy, Stephen Hemminger, Ahmed Amamou, netdev,
f.cachereul, Emmanuel Hocdet, Kamel Haddadou
In-Reply-To: <CAHA+R7OjNEVj+PSzoyzvCOBDYXNWAUMSbsZUFZk0qGFz4fSB-w@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 192 bytes --]
On Sep24 10:26, Cong Wang wrote:
> At least the comment style is not what DaveM prefers.
> Please take a look at netdev-FAQ.txt.
agreed, will correct and double check that
--
William
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [PATCH] vlan: Fix receive statistics under-reporting
From: Vlad Yasevich @ 2014-09-24 16:45 UTC (permalink / raw)
To: Eric Dumazet, Vladislav Yasevich; +Cc: netdev, stephen
In-Reply-To: <1411571333.15395.33.camel@edumazet-glaptop2.roam.corp.google.com>
On 09/24/2014 11:08 AM, Eric Dumazet wrote:
> On Wed, 2014-09-24 at 10:45 -0400, Vladislav Yasevich wrote:
>> Vlan devices uder-report 14 bytes per packet in the recieve statistics.
>> This is because the ETH_HLEN bytes of data has been pulled off the skb
>> by the time it gets to the vlan receive code. When accounting for
>> receive butes, add ETH_HLEN back.
>>
>> See also https://bugzilla.kernel.org/show_bug.cgi?id=84951
>>
>> Signed-off-by: Vladislav Yasevich <vyasevic@redhat.com>
>> ---
>> net/8021q/vlan_core.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/net/8021q/vlan_core.c b/net/8021q/vlan_core.c
>> index 90cc2bd..8bc5d46 100644
>> --- a/net/8021q/vlan_core.c
>> +++ b/net/8021q/vlan_core.c
>> @@ -54,7 +54,7 @@ bool vlan_do_receive(struct sk_buff **skbp)
>>
>> u64_stats_update_begin(&rx_stats->syncp);
>> rx_stats->rx_packets++;
>> - rx_stats->rx_bytes += skb->len;
>> + rx_stats->rx_bytes += skb->len + ETH_HLEN;
>> if (skb->pkt_type == PACKET_MULTICAST)
>> rx_stats->rx_multicast++;
>> u64_stats_update_end(&rx_stats->syncp);
>
>
> I do not think this patch is general enough, it doesn't handle GRO for
> example.
I just looked at more software devices (including encapsulators) and
find that macvlan appears to be the only anomaly.
Everyone appears to be using skb->len directly and dropping ETH_HLEN.
Macvlan tries to be "extra smart" and adds the ETH_HLEN back in.
Definitely this patch isn't enough all by itself. I might be better
to make it consistent the other way around.
>
> And should not the vlan tag also be accounted ?
>
>
I don't think so. We don't do it on TX.
-vlad
^ permalink raw reply
* Re: [RFC PATCH 06/24] net: rbridge: Enable/disable TRILL capability
From: Vlad Yasevich @ 2014-09-24 17:46 UTC (permalink / raw)
To: Ahmed Amamou, netdev; +Cc: william, f.cachereul, Kamel Haddadou
In-Reply-To: <1411573940-14079-7-git-send-email-ahmed@gandi.net>
On 09/24/2014 11:52 AM, Ahmed Amamou wrote:
> enable switching TRILL capability state via sysfs command
>
> Signed-off-by: Ahmed Amamou <ahmed@gandi.net>
> Signed-off-by: Kamel Haddadou <kamel@gandi.net>
> ---
> net/bridge/Makefile | 2 ++
> net/bridge/br_private.h | 5 ++++
> net/bridge/br_sysfs_br.c | 38 +++++++++++++++++++++++
> net/bridge/rbridge/rbr.c | 78 ++++++++++++++++++++++++++++++++++++++++++++++++
> 4 files changed, 123 insertions(+)
> create mode 100644 net/bridge/rbridge/rbr.c
>
> diff --git a/net/bridge/Makefile b/net/bridge/Makefile
> index 8590b94..314783c 100644
> --- a/net/bridge/Makefile
> +++ b/net/bridge/Makefile
> @@ -17,3 +17,5 @@ bridge-$(CONFIG_BRIDGE_IGMP_SNOOPING) += br_multicast.o br_mdb.o
> bridge-$(CONFIG_BRIDGE_VLAN_FILTERING) += br_vlan.o
>
> obj-$(CONFIG_NETFILTER) += netfilter/
> +
> +bridge-$(CONFIG_TRILL) += rbridge/rbr.o
> diff --git a/net/bridge/br_private.h b/net/bridge/br_private.h
> index 430c556..844c87b 100644
> --- a/net/bridge/br_private.h
> +++ b/net/bridge/br_private.h
> @@ -811,6 +811,11 @@ int br_stp_set_port_priority(struct net_bridge_port *p, unsigned long newprio);
> int br_stp_set_path_cost(struct net_bridge_port *p, unsigned long path_cost);
> ssize_t br_show_bridge_id(char *buf, const struct bridge_id *id);
>
> +/* rbridge/rbr.c */
> +#ifdef CONFIG_TRILL
> +void br_trill_set_enabled(struct net_bridge *br, unsigned long val);
> +#endif
> +
> /* br_stp_bpdu.c */
> struct stp_proto;
> void br_stp_rcv(const struct stp_proto *proto, struct sk_buff *skb,
> diff --git a/net/bridge/br_sysfs_br.c b/net/bridge/br_sysfs_br.c
> index c9e2572..787ab84 100644
> --- a/net/bridge/br_sysfs_br.c
> +++ b/net/bridge/br_sysfs_br.c
> @@ -146,6 +146,41 @@ static ssize_t stp_state_store(struct device *d,
> }
> static DEVICE_ATTR_RW(stp_state);
>
> +#ifdef CONFIG_TRILL
> +static ssize_t trill_state_show(struct device *d,
> + struct device_attribute *attr, char *buf)
> +{
> + struct net_bridge *br = to_bridge(d);
> + return sprintf(buf, "%d\n", br->trill_enabled);
> +}
> +
> +static ssize_t trill_state_store(struct device *d,
> + struct device_attribute *attr, const char *buf,
> + size_t len)
> +{
> + struct net_bridge *br = to_bridge(d);
> + char *endp;
> + unsigned long val;
> +
> + if (!ns_capable(dev_net(br->dev)->user_ns, CAP_NET_ADMIN))
> + return -EPERM;
> +
> + val = simple_strtoul(buf, &endp, 0);
> + if (endp == buf)
> + return -EINVAL;
> +
> + if (!rtnl_trylock())
> + return restart_syscall();
> + br_trill_set_enabled(br, val);
> + rtnl_unlock();
> +
> + return len;
> +}
> +
> +static DEVICE_ATTR_RW(trill_state);
> +#endif
> +
> +
> static ssize_t group_fwd_mask_show(struct device *d,
> struct device_attribute *attr,
> char *buf)
> @@ -733,6 +768,9 @@ static struct attribute *bridge_attrs[] = {
> &dev_attr_max_age.attr,
> &dev_attr_ageing_time.attr,
> &dev_attr_stp_state.attr,
> +#ifdef CONFIG_TRILL
> + &dev_attr_trill_state.attr,
> +#endif
> &dev_attr_group_fwd_mask.attr,
> &dev_attr_priority.attr,
> &dev_attr_bridge_id.attr,
> diff --git a/net/bridge/rbridge/rbr.c b/net/bridge/rbridge/rbr.c
> new file mode 100644
> index 0000000..41d47db
> --- /dev/null
> +++ b/net/bridge/rbridge/rbr.c
> @@ -0,0 +1,78 @@
> +/*
> + * Generic parts
> + * Linux ethernet Rbridge
> + *
> + * Authors:
> + * Ahmed AMAMOU <ahmed@gandi.net>
> + * Kamel Haddadou <kamel@gandi.net>
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * as published by the Free Software Foundation; either version
> + * 2 of the License, or (at your option) any later version.
> + */
> +#include "br_private.h"
> +#include "rbr_private.h"
> +
> +static struct rbr *add_rbr(struct net_bridge *br)
> +{
> + struct rbr *rbr;
> +
> + if (!br->rbr) {
> + rbr = kzalloc(sizeof(*rbr), GFP_KERNEL);
> + if (!rbr)
> + return NULL;
> +
> + rbr->br = br;
> + rbr->nick = RBRIDGE_NICKNAME_NONE;
> + rbr->treeroot = RBRIDGE_NICKNAME_NONE;
> + return rbr;
> + }
> +
> + return br->rbr;
> +}
> +
> +static void br_trill_start(struct net_bridge *br)
> +{
> + /* Disable STP if it is already enabled */
> +
> + if (br->stp_enabled != BR_NO_STP)
> + br_stp_set_enabled(br, false);
> + br->rbr = add_rbr(br);
> + if (br->rbr) {
> + spin_lock_bh(&br->lock);
> + br->trill_enabled = BR_TRILL;
> + spin_unlock_bh(&br->lock);
> + } else {
> + printk(KERN_WARNING
> + "RBridge allocation for bridge '%s' failed\n",
> + br->dev->name);
> + }
> +}
> +
> +static void br_trill_stop(struct net_bridge *br)
> +{
> + struct rbr *old;
> +
> + spin_lock_bh(&br->lock);
> + br->trill_enabled = BR_NO_TRILL;
> + spin_unlock_bh(&br->lock);
Are the locks around trill_enabled really needed? Seems to be already
protected by rtnl. Are you protecting against something else?
> + old = br->rbr;
> + br->rbr = NULL;
> + if (likely(old)) {
> + spin_lock_bh(&br->lock);
> + kfree(old);
> + spin_unlock_bh(&br->lock);
These locks appear to be completely unnecessary.
Also what's protecting future refrences to br->rbr? Should it be rcu
protected?
-vlad
> + }
> +}
> +
> +void br_trill_set_enabled(struct net_bridge *br, unsigned long val)
> +{
> + if (val) {
> + if (br->trill_enabled == BR_NO_TRILL)
> + br_trill_start(br);
> + } else {
> + if (br->trill_enabled != BR_NO_TRILL)
> + br_trill_stop(br);
> + }
> +}
>
^ permalink raw reply
* Re: [RFC PATCH 08/24] net: rbridge: Add Rbridge netlink message skeleton
From: Vlad Yasevich @ 2014-09-24 17:52 UTC (permalink / raw)
To: Ahmed Amamou, netdev; +Cc: william, f.cachereul, Kamel Haddadou
In-Reply-To: <1411573940-14079-9-git-send-email-ahmed@gandi.net>
On 09/24/2014 11:52 AM, Ahmed Amamou wrote:
> add data plane and control plane basic message skeleton
> add netlink socket registration and unregistration respectively within module init and deinit function
>
> Signed-off-by: Ahmed Amamou <ahmed@gandi.net>
> Signed-off-by: Kamel Haddadou <kamel@gandi.net>
> ---
> net/bridge/Makefile | 2 +-
> net/bridge/br.c | 6 ++
> net/bridge/br_private.h | 1 +
> net/bridge/rbridge/rbr_netlink.c | 152 +++++++++++++++++++++++++++++++++++++++
> net/bridge/rbridge/rbr_netlink.h | 62 ++++++++++++++++
> 5 files changed, 222 insertions(+), 1 deletion(-)
> create mode 100644 net/bridge/rbridge/rbr_netlink.c
> create mode 100644 net/bridge/rbridge/rbr_netlink.h
>
> diff --git a/net/bridge/Makefile b/net/bridge/Makefile
> index 314783c..b11a22b 100644
> --- a/net/bridge/Makefile
> +++ b/net/bridge/Makefile
> @@ -18,4 +18,4 @@ bridge-$(CONFIG_BRIDGE_VLAN_FILTERING) += br_vlan.o
>
> obj-$(CONFIG_NETFILTER) += netfilter/
>
> -bridge-$(CONFIG_TRILL) += rbridge/rbr.o
> +bridge-$(CONFIG_TRILL) += rbridge/rbr.o rbridge/rbr_netlink.o
> diff --git a/net/bridge/br.c b/net/bridge/br.c
> index 1a755a1..51af134 100644
> --- a/net/bridge/br.c
> +++ b/net/bridge/br.c
> @@ -178,6 +178,9 @@ static int __init br_init(void)
> #if IS_ENABLED(CONFIG_ATM_LANE)
> br_fdb_test_addr_hook = br_fdb_test_addr;
> #endif
> +#ifdef CONFIG_TRILL
> + rbridge_register_genl();
> +#endif
>
> return 0;
> err_out4:
> @@ -210,6 +213,9 @@ static void __exit br_deinit(void)
> br_fdb_test_addr_hook = NULL;
> #endif
>
> +#ifdef CONFIG_TRILL
> + rbridge_unregister_genl();
> +#endif
> br_fdb_fini();
> }
The above #defines should be removed and inline noop stubs should
be added.
>
> diff --git a/net/bridge/br_private.h b/net/bridge/br_private.h
> index 844c87b..6952db8 100644
> --- a/net/bridge/br_private.h
> +++ b/net/bridge/br_private.h
> @@ -21,6 +21,7 @@
> #include <linux/if_vlan.h>
> #ifdef CONFIG_TRILL
> #include "rbridge/rbr_private.h"
> +#include "rbridge/rbr_netlink.h"
> #endif
>
> #define BR_HASH_BITS 8
> diff --git a/net/bridge/rbridge/rbr_netlink.c b/net/bridge/rbridge/rbr_netlink.c
> new file mode 100644
> index 0000000..eb7c902
> --- /dev/null
> +++ b/net/bridge/rbridge/rbr_netlink.c
> @@ -0,0 +1,152 @@
> +/*
> + * Generic parts
> + * Linux ethernet Rbridge
> + *
> + * Authors:
> + * Ahmed AMAMOU <ahmed@gandi.net>
> + * Kamel Haddadou <kamel@gandi.net>
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * as published by the Free Software Foundation; either version
> + * 2 of the License, or (at your option) any later version.
> + */
> +
> +#include <net/genetlink.h>
> +#include <net/netlink.h>
> +#include <linux/if_trill.h>
> +#include <linux/socket.h>
> +#include <linux/socket.h>
> +#include "br_private.h"
> +#include "rbr_private.h"
> +#include "rbr_netlink.h"
> +
> +static struct nla_policy attrs_policy[TRILL_ATTR_MAX + 1] = {
> + [TRILL_ATTR_U16] = {.type = NLA_U16},
> + [TRILL_ATTR_BIN] = {.type = NLA_UNSPEC},
> +};
> +
> +static struct genl_family trill_genl_family = {
> + .id = GENL_ID_GENERATE,
> + .hdrsize = sizeof(struct trill_nl_header),
> + .name = TRILL_NL_FAMILY,
> + .version = TRILL_NL_VERSION,
> + .maxattr = TRILL_ATTR_MAX
> +};
> +
> +static struct genl_multicast_group trill_mcgrps[] = {
> + [TRILL_MCGRP_OFFSET] = {.name = TRILL_MCAST_NAME,},
> +};
> +
> +static int trill_cmd_set_nicks_info(struct sk_buff *skb, struct genl_info *info)
> +{
> + return 0;
> +}
> +
> +static int trill_cmd_get_nicks_info(struct sk_buff *skb, struct genl_info *info)
> +{
> + return 0;
> +}
> +
> +static int trill_cmd_add_nicks_info(struct sk_buff *skb, struct genl_info *info)
> +{
> + return 0;
> +}
> +
> +static int trill_cmd_set_treeroot_id(struct sk_buff *skb,
> + struct genl_info *info)
> +{
> + return 0;
> +}
> +
> +static int trill_cmd_get_rbridge(struct sk_buff *skb, struct genl_info *info)
> +{
> + return 0;
> +}
> +
> +static int trill_cmd_set_rbridge(struct sk_buff *skb, struct genl_info *info)
> +{
> + return 0;
> +}
> +
> +static int trill_cmd_port_flush(struct sk_buff *skb, struct genl_info *info)
> +{
> + return 0;
> +}
> +
> +static int trill_cmd_nick_flush(struct sk_buff *skb, struct genl_info *info)
> +{
> + return 0;
> +}
> +
> +static struct genl_ops trill_genl_ops[] = {
> + {
> + .cmd = TRILL_CMD_SET_NICKS_INFO,
> + .flags = GENL_ADMIN_PERM, /* Requires CAP_NET_ADMIN privilege. */
> + .policy = attrs_policy,
> + .doit = trill_cmd_set_nicks_info,
> + },
> + {
> + .cmd = TRILL_CMD_GET_NICKS_INFO,
> + .flags = GENL_ADMIN_PERM, /* Requires CAP_NET_ADMIN privilege. */
> + .policy = attrs_policy,
> + .doit = trill_cmd_get_nicks_info,
> + },
> + {
> + .cmd = TRILL_CMD_ADD_NICKS_INFO,
> + .flags = GENL_ADMIN_PERM, /* Requires CAP_NET_ADMIN privilege. */
> + .policy = attrs_policy,
> + .doit = trill_cmd_add_nicks_info,
> + },
> + {
> + .cmd = TRILL_CMD_SET_TREEROOT_ID,
> + .flags = GENL_ADMIN_PERM, /* Requires CAP_NET_ADMIN privilege. */
> + .policy = attrs_policy,
> + .doit = trill_cmd_set_treeroot_id,
> + },
> + {
> + .cmd = TRILL_CMD_GET_RBRIDGE,
> + .flags = GENL_ADMIN_PERM, /* Requires CAP_NET_ADMIN privilege. */
> + .policy = attrs_policy,
> + .doit = trill_cmd_get_rbridge,
> + },
> + {
> + .cmd = TRILL_CMD_SET_RBRIDGE,
> + .flags = GENL_ADMIN_PERM, /* Requires CAP_NET_ADMIN privilege. */
> + .policy = attrs_policy,
> + .doit = trill_cmd_set_rbridge,
> + },
> + {
> + .cmd = TRILL_CMD_PORT_FLUSH,
> + .flags = GENL_ADMIN_PERM, /* Requires CAP_NET_ADMIN privilege. */
> + .doit = trill_cmd_port_flush,
> + },
> + {
> + .cmd = TRILL_CMD_NICK_FLUSH,
> + .flags = GENL_ADMIN_PERM, /* Requires CAP_NET_ADMIN privilege. */
> + .policy = attrs_policy,
> + .doit = trill_cmd_nick_flush,
> + },
> +};
> +
> +void __exit rbridge_unregister_genl(void)
> +{
> + genl_unregister_family(&trill_genl_family);
> +}
> +
> +int __init rbridge_register_genl(void)
> +{
> + int err;
> +
> + err =
> + genl_register_family_with_ops_groups(&trill_genl_family,
> + trill_genl_ops, trill_mcgrps);
> + if (err)
> + goto fail_genl_register_family;
> +
> + return 0;
> +
> + fail_genl_register_family:
> +
> + return err;
> +}
> diff --git a/net/bridge/rbridge/rbr_netlink.h b/net/bridge/rbridge/rbr_netlink.h
> new file mode 100644
> index 0000000..0556323
> --- /dev/null
> +++ b/net/bridge/rbridge/rbr_netlink.h
> @@ -0,0 +1,62 @@
> +/*
> + * Generic parts
> + * Linux ethernet Rbridge
> + *
> + * Authors:
> + * Ahmed AMAMOU <ahmed@gandi.net>
> + * Kamel Haddadou <kamel@gandi.net>
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * as published by the Free Software Foundation; either version
> + * 2 of the License, or (at your option) any later version.
> + */
> +
> +#ifndef RBR_NETLINK_H_
> +#define RBR_NETLINK_H_
> +
> +/* TRILL Generic Netlink attributes definition*/
> +#define TRILL_NL_VERSION 0x1
> +#define TRILL_NL_FAMILY "TRILL_NL"
> +#define TRILL_MCAST_NAME "TR_NL_MCAST"
> +#define TRILL_MCGRP_OFFSET 0
> +
> +struct trill_nl_header {
> + int ifindex; /* port id */
> + int total_length; /* message total length for mutipart messages check */
> + int msg_number; /* message number for multipart messages check */
> +};
> +
> +enum {
> + TRILL_ATTR_UNSPEC,
> + TRILL_ATTR_U16,
> + TRILL_ATTR_BIN,
> + __TRILL_ATTR_MAX,
> +};
> +#define TRILL_ATTR_MAX (__TRILL_ATTR_MAX-1)
> +
> +/* GET and set are from user space perspective example TRILL_CMD_GET_BRIDGE
> + * means that the kernel will send this bridge name to userspace
> + */
> +enum {
> + TRILL_CMD_UNSPEC,
> + TRILL_CMD_SET_NICKS_INFO,
> + TRILL_CMD_GET_NICKS_INFO,
> + TRILL_CMD_ADD_NICKS_INFO,
> + TRILL_CMD_DEL_NICK,
> + TRILL_CMD_SET_TREEROOT_ID,
> + TRILL_CMD_GET_RBRIDGE,
> + TRILL_CMD_SET_RBRIDGE,
> + TRILL_CMD_PORT_FLUSH,
> + TRILL_CMD_NICK_FLUSH,
> + __TRILL_CMD_MAX,
> +};
> +#define TRILL_CMD_MAX (__TRILL_CMD_MAX - 1)
> +
> +int __init rbridge_register_genl(void);
> +void __exit rbridge_unregister_genl(void);
> +
> +/* used to indicate that message is provided by kernel to user space */
> +#define KERNL_RESPONSE_INTERFACE -1
> +
> +#endif /* RBR_NETLINK_H_ */
>
Bridge is typically configured through rtnetlink and there is an
effort to make this configuration easier. Switching to genl means
there will be yet another tool to configure some part of the bridge.
-vlad
^ permalink raw reply
* Q: State of Linux RSTP support
From: Tilman Schmidt @ 2014-09-24 18:00 UTC (permalink / raw)
To: netdev
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
According to Stephen Hemminger's presentation at
http://www.slideshare.net/shemminger/new-bridge (which seems to be the
most recent information available on the topic) the in-kernel bridging
code only provides STP. RTSP is (should be) provided by a user space
daemon, rtspd. However, none of the distributions I routinely use
provide that daemon. Sourceforge has a project named rstpd but it
seems to be inactive.
A search for RSTP in the current git tree finds
- - in net/bridge/br_netlink.c, a comment:
/* Binary compatibility with old RSTP */
- - in net/bridge/br_private.h, an enum constant for struct net_bridge
member stp_enabled:
BR_USER_STP, /* new RSTP in userspace */
but nothing in, say, the Documentation folder.
Any pointers?
aTdHvAaNnKcSe,
Tilman
- --
Tilman Schmidt E-Mail: tilman@imap.cc
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQEcBAEBAgAGBQJUIwaiAAoJEFPuqx0v+F+q/dIIAI8tK2C7yVPoD3PaLwwVqcxQ
9lV3VCXiRT4v1fGTqEtzTJhoyPAqZw+iHbmoPVZow9GPEAS1m5nPYBE44cejmP6M
SL0OtQmcnYO0UNBsIpwA6F8g+e3ZraivtAv4CVoBLMXGWrAz7zrERIRTkk0XOMdG
t2Is1e+U+48DlOH8CIPhqOEu/kIABz2GMle5S94VzlBkeBsGL9ifDrFxACtxbkEN
YJIm9QKxZa/MGwksgHCoQWDafrcs8RL6FhQDBVCUVhrERlp/12+kKwYXxvH9kv+a
YAAzMXkAu+3zPTI0Bl99M4NEQ57Z0FKtb8pwug9wSKH7UWdx18pKYOsYUdMwROM=
=s37Z
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: Q: State of Linux RSTP support
From: Vlad Yasevich @ 2014-09-24 18:23 UTC (permalink / raw)
To: Tilman Schmidt, netdev
In-Reply-To: <542306A2.7020008@imap.cc>
On 09/24/2014 02:00 PM, Tilman Schmidt wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> According to Stephen Hemminger's presentation at
> http://www.slideshare.net/shemminger/new-bridge (which seems to be the
> most recent information available on the topic) the in-kernel bridging
> code only provides STP. RTSP is (should be) provided by a user space
> daemon, rtspd. However, none of the distributions I routinely use
> provide that daemon. Sourceforge has a project named rstpd but it
> seems to be inactive.
>
> A search for RSTP in the current git tree finds
>
> - - in net/bridge/br_netlink.c, a comment:
> /* Binary compatibility with old RSTP */
>
> - - in net/bridge/br_private.h, an enum constant for struct net_bridge
> member stp_enabled:
> BR_USER_STP, /* new RSTP in userspace */
>
> but nothing in, say, the Documentation folder.
There is https://git.kernel.org/cgit/linux/kernel/git/shemminger/rstp.git/
but it's 3 years old. Don't know if Stephen has anything newer.
-vlad
>
> Any pointers?
>
> aTdHvAaNnKcSe,
> Tilman
>
> - --
> Tilman Schmidt E-Mail: tilman@imap.cc
> Bonn, Germany
> Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
> Ungeöffnet mindestens haltbar bis: (siehe Rückseite)
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
>
> iQEcBAEBAgAGBQJUIwaiAAoJEFPuqx0v+F+q/dIIAI8tK2C7yVPoD3PaLwwVqcxQ
> 9lV3VCXiRT4v1fGTqEtzTJhoyPAqZw+iHbmoPVZow9GPEAS1m5nPYBE44cejmP6M
> SL0OtQmcnYO0UNBsIpwA6F8g+e3ZraivtAv4CVoBLMXGWrAz7zrERIRTkk0XOMdG
> t2Is1e+U+48DlOH8CIPhqOEu/kIABz2GMle5S94VzlBkeBsGL9ifDrFxACtxbkEN
> YJIm9QKxZa/MGwksgHCoQWDafrcs8RL6FhQDBVCUVhrERlp/12+kKwYXxvH9kv+a
> YAAzMXkAu+3zPTI0Bl99M4NEQ57Z0FKtb8pwug9wSKH7UWdx18pKYOsYUdMwROM=
> =s37Z
> -----END PGP SIGNATURE-----
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [net-next PATCH 1/1 V4] qdisc: bulk dequeue support for qdiscs with TCQ_F_ONETXQUEUE
From: Jesper Dangaard Brouer @ 2014-09-24 17:58 UTC (permalink / raw)
To: Eric Dumazet
Cc: netdev, therbert, David S. Miller, Alexander Duyck, toke,
Florian Westphal, jhs, Dave Taht, John Fastabend, Daniel Borkmann,
Hannes Frederic Sowa, brouer
In-Reply-To: <1411579395.15395.41.camel@edumazet-glaptop2.roam.corp.google.com>
On Wed, 24 Sep 2014 10:23:15 -0700
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Wed, 2014-09-24 at 18:12 +0200, Jesper Dangaard Brouer wrote:
> > Based on DaveM's recent API work on dev_hard_start_xmit(), that allows
> > sending/processing an entire skb list.
> >
> > This patch implements qdisc bulk dequeue, by allowing multiple packets
> > to be dequeued in dequeue_skb().
> >
> > The optimization principle for this is two fold, (1) to amortize
> > locking cost and (2) avoid expensive tailptr update for notifying HW.
> > (1) Several packets are dequeued while holding the qdisc root_lock,
> > amortizing locking cost over several packet. The dequeued SKB list is
> > processed under the TXQ lock in dev_hard_start_xmit(), thus also
> > amortizing the cost of the TXQ lock.
> > (2) Further more, dev_hard_start_xmit() will utilize the skb->xmit_more
> > API to delay HW tailptr update, which also reduces the cost per
> > packet.
> >
> > One restriction of the new API is that every SKB must belong to the
> > same TXQ. This patch takes the easy way out, by restricting bulk
> > dequeue to qdisc's with the TCQ_F_ONETXQUEUE flag, that specifies the
> > qdisc only have attached a single TXQ.
> >
> > Some detail about the flow; dev_hard_start_xmit() will process the skb
> > list, and transmit packets individually towards the driver (see
> > xmit_one()). In case the driver stops midway in the list, the
> > remaining skb list is returned by dev_hard_start_xmit(). In
> > sch_direct_xmit() this returned list is requeued by dev_requeue_skb().
> >
> > To avoid overshooting the HW limits, which results in requeuing, the
> > patch limits the amount of bytes dequeued, based on the drivers BQL
> > limits. In-effect bulking will only happen for BQL enabled drivers.
> > Besides the bytelimit from BQL, also limit bulking to maximum 8
> > packets to avoid any issues with available descriptor in HW.
> >
> > For now, as a conservative approach, don't bulk dequeue GSO and
> > segmented GSO packets, because testing showed requeuing occuring
> > with segmented GSO packets.
> >
> > Jointed work with Hannes, Daniel and Florian.
> >
> > Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
> > Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
> > Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
> > Signed-off-by: Florian Westphal <fw@strlen.de>
> >
> > ---
> > V4:
> > - Patch rewritten in the Red Hat Neuchatel office jointed work with
> > Hannes, Daniel and Florian.
> > - Conservative approach of only using on BQL enabled drivers
> > - No user tunable parameter, but limit bulking to 8 packets.
> > - For now, avoid bulking GSO packets packets.
> >
[...]
> > diff --git a/net/sched/sch_generic.c b/net/sched/sch_generic.c
> > index 19696eb..6fba089 100644
> > --- a/net/sched/sch_generic.c
> > +++ b/net/sched/sch_generic.c
> > @@ -56,6 +56,42 @@ static inline int dev_requeue_skb(struct sk_buff *skb, struct Qdisc *q)
> > return 0;
> > }
> >
> > +static struct sk_buff *try_bulk_dequeue_skb(struct Qdisc *q,
> > + struct sk_buff *head_skb,
> > + int bytelimit)
> > +{
> > + struct sk_buff *skb, *tail_skb = head_skb;
> > + int budget = 8; /* Arbitrary, but conservatively choosen limit */
> > +
> > + while (bytelimit > 0 && --budget > 0) {
> > + /* For now, don't bulk dequeue GSO (or GSO segmented) pkts */
>
> Hmm... this is a serious limitation.
We plan to remove this at a later point, this is just to be conservative.
> > + if (tail_skb->next || skb_is_gso(tail_skb))
> > + break;
> > +
> > + skb = q->dequeue(q);
> > + if (!skb)
> > + break;
> > +
> > + bytelimit -= skb->len; /* covers GSO len */
>
> Not really, use qdisc_pkt_len(skb) instead, to have a better byte count.
Understood, will update patch tomorrow.
> > + skb = validate_xmit_skb(skb, qdisc_dev(q));
> > + if (!skb)
> > + break;
> > +
> > + /* "skb" can be a skb list after validate call above
> > + * (GSO segmented), but it is okay to append it to
> > + * current tail_skb->next, because next round will exit
> > + * in-case "tail_skb->next" is a skb list.
> > + */
>
> It would be trivial to change validate_xmit_skb() to return the head and
> tail of the chain. Walking the chain would hit hot cache lines, but it
> is better not having to walk it.
Yes, we could do this when we later add support for GSO segmented packets.
> > + tail_skb->next = skb;
> > + tail_skb = skb;
>
> So that here we do : tail_skb = tail;
>
> > + }
> > +
> > + return head_skb;
> > +}
> > +
> > +/* Note that dequeue_skb can possibly return a SKB list (via skb->next).
> > + * A requeued skb (via q->gso_skb) can also be a SKB list.
> > + */
> > static inline struct sk_buff *dequeue_skb(struct Qdisc *q)
> > {
> > struct sk_buff *skb = q->gso_skb;
> > @@ -70,10 +106,17 @@ static inline struct sk_buff *dequeue_skb(struct Qdisc *q)
> > } else
> > skb = NULL;
> > } else {
> > - if (!(q->flags & TCQ_F_ONETXQUEUE) || !netif_xmit_frozen_or_stopped(txq)) {
> > + if (!(q->flags & TCQ_F_ONETXQUEUE) ||
> > + !netif_xmit_frozen_or_stopped(txq)) {
> > + int bytelimit = qdisc_avail_bulklimit(txq);
> > +
> > skb = q->dequeue(q);
> > - if (skb)
> > + if (skb) {
> > + bytelimit -= skb->len;
>
> qdisc_pkt_len(skb)
Okay, will update patch tomorrow.
> > skb = validate_xmit_skb(skb, qdisc_dev(q));
> > + }
> > + if (skb && qdisc_may_bulk(q))
> > + skb = try_bulk_dequeue_skb(q, skb, bytelimit);
> > }
> > }
> >
>
> It looks good, but we really need to take care of TSO packets.
As notes above, TSO packets are planned as a future feature. Lets
first see if this works well, without introducing any HoL blocking
issues or other regressions.
> pktgen is nice, but do not represent the majority of the traffic we send
> from high performance host where we want this bulk dequeue thing ;)
This patch is actually targetted towards more normal use-cases.
Pktgen cannot even use this work, as it bypass the qdisc layer...
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Sr. Network Kernel Developer at Red Hat
Author of http://www.iptv-analyzer.org
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: [net-next PATCH 1/1 V4] qdisc: bulk dequeue support for qdiscs with TCQ_F_ONETXQUEUE
From: Tom Herbert @ 2014-09-24 18:34 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: Eric Dumazet, Linux Netdev List, David S. Miller, Alexander Duyck,
Toke Høiland-Jørgensen, Florian Westphal,
Jamal Hadi Salim, Dave Taht, John Fastabend, Daniel Borkmann,
Hannes Frederic Sowa
In-Reply-To: <20140924195831.6fb91051@redhat.com>
On Wed, Sep 24, 2014 at 10:58 AM, Jesper Dangaard Brouer
<brouer@redhat.com> wrote:
> On Wed, 24 Sep 2014 10:23:15 -0700
> Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
>> On Wed, 2014-09-24 at 18:12 +0200, Jesper Dangaard Brouer wrote:
>> > Based on DaveM's recent API work on dev_hard_start_xmit(), that allows
>> > sending/processing an entire skb list.
>> >
>> > This patch implements qdisc bulk dequeue, by allowing multiple packets
>> > to be dequeued in dequeue_skb().
>> >
>> > The optimization principle for this is two fold, (1) to amortize
>> > locking cost and (2) avoid expensive tailptr update for notifying HW.
>> > (1) Several packets are dequeued while holding the qdisc root_lock,
>> > amortizing locking cost over several packet. The dequeued SKB list is
>> > processed under the TXQ lock in dev_hard_start_xmit(), thus also
>> > amortizing the cost of the TXQ lock.
>> > (2) Further more, dev_hard_start_xmit() will utilize the skb->xmit_more
>> > API to delay HW tailptr update, which also reduces the cost per
>> > packet.
>> >
>> > One restriction of the new API is that every SKB must belong to the
>> > same TXQ. This patch takes the easy way out, by restricting bulk
>> > dequeue to qdisc's with the TCQ_F_ONETXQUEUE flag, that specifies the
>> > qdisc only have attached a single TXQ.
>> >
>> > Some detail about the flow; dev_hard_start_xmit() will process the skb
>> > list, and transmit packets individually towards the driver (see
>> > xmit_one()). In case the driver stops midway in the list, the
>> > remaining skb list is returned by dev_hard_start_xmit(). In
>> > sch_direct_xmit() this returned list is requeued by dev_requeue_skb().
>> >
>> > To avoid overshooting the HW limits, which results in requeuing, the
>> > patch limits the amount of bytes dequeued, based on the drivers BQL
>> > limits. In-effect bulking will only happen for BQL enabled drivers.
>> > Besides the bytelimit from BQL, also limit bulking to maximum 8
>> > packets to avoid any issues with available descriptor in HW.
>> >
>> > For now, as a conservative approach, don't bulk dequeue GSO and
>> > segmented GSO packets, because testing showed requeuing occuring
>> > with segmented GSO packets.
>> >
>> > Jointed work with Hannes, Daniel and Florian.
>> >
>> > Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
>> > Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
>> > Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
>> > Signed-off-by: Florian Westphal <fw@strlen.de>
>> >
>> > ---
>> > V4:
>> > - Patch rewritten in the Red Hat Neuchatel office jointed work with
>> > Hannes, Daniel and Florian.
>> > - Conservative approach of only using on BQL enabled drivers
>> > - No user tunable parameter, but limit bulking to 8 packets.
>> > - For now, avoid bulking GSO packets packets.
>> >
> [...]
>> > diff --git a/net/sched/sch_generic.c b/net/sched/sch_generic.c
>> > index 19696eb..6fba089 100644
>> > --- a/net/sched/sch_generic.c
>> > +++ b/net/sched/sch_generic.c
>> > @@ -56,6 +56,42 @@ static inline int dev_requeue_skb(struct sk_buff *skb, struct Qdisc *q)
>> > return 0;
>> > }
>> >
>> > +static struct sk_buff *try_bulk_dequeue_skb(struct Qdisc *q,
>> > + struct sk_buff *head_skb,
>> > + int bytelimit)
>> > +{
>> > + struct sk_buff *skb, *tail_skb = head_skb;
>> > + int budget = 8; /* Arbitrary, but conservatively choosen limit */
>> > +
>> > + while (bytelimit > 0 && --budget > 0) {
>> > + /* For now, don't bulk dequeue GSO (or GSO segmented) pkts */
>>
>> Hmm... this is a serious limitation.
>
> We plan to remove this at a later point, this is just to be conservative.
>
>
>> > + if (tail_skb->next || skb_is_gso(tail_skb))
>> > + break;
>> > +
>> > + skb = q->dequeue(q);
>> > + if (!skb)
>> > + break;
>> > +
>> > + bytelimit -= skb->len; /* covers GSO len */
>>
>> Not really, use qdisc_pkt_len(skb) instead, to have a better byte count.
>
> Understood, will update patch tomorrow.
>
I believe drivers typically use skb->len for BQL tracking. Since
bytelimit is based on BQL here, it might be more correct to use
skb->len.
>
>> > + skb = validate_xmit_skb(skb, qdisc_dev(q));
>> > + if (!skb)
>> > + break;
>> > +
>> > + /* "skb" can be a skb list after validate call above
>> > + * (GSO segmented), but it is okay to append it to
>> > + * current tail_skb->next, because next round will exit
>> > + * in-case "tail_skb->next" is a skb list.
>> > + */
>>
>> It would be trivial to change validate_xmit_skb() to return the head and
>> tail of the chain. Walking the chain would hit hot cache lines, but it
>> is better not having to walk it.
>
> Yes, we could do this when we later add support for GSO segmented packets.
>
>
>> > + tail_skb->next = skb;
>> > + tail_skb = skb;
>>
>> So that here we do : tail_skb = tail;
>>
>> > + }
>> > +
>> > + return head_skb;
>> > +}
>> > +
>> > +/* Note that dequeue_skb can possibly return a SKB list (via skb->next).
>> > + * A requeued skb (via q->gso_skb) can also be a SKB list.
>> > + */
>> > static inline struct sk_buff *dequeue_skb(struct Qdisc *q)
>> > {
>> > struct sk_buff *skb = q->gso_skb;
>> > @@ -70,10 +106,17 @@ static inline struct sk_buff *dequeue_skb(struct Qdisc *q)
>> > } else
>> > skb = NULL;
>> > } else {
>> > - if (!(q->flags & TCQ_F_ONETXQUEUE) || !netif_xmit_frozen_or_stopped(txq)) {
>> > + if (!(q->flags & TCQ_F_ONETXQUEUE) ||
>> > + !netif_xmit_frozen_or_stopped(txq)) {
>> > + int bytelimit = qdisc_avail_bulklimit(txq);
>> > +
>> > skb = q->dequeue(q);
>> > - if (skb)
>> > + if (skb) {
>> > + bytelimit -= skb->len;
>>
>> qdisc_pkt_len(skb)
>
> Okay, will update patch tomorrow.
>
>> > skb = validate_xmit_skb(skb, qdisc_dev(q));
>> > + }
>> > + if (skb && qdisc_may_bulk(q))
>> > + skb = try_bulk_dequeue_skb(q, skb, bytelimit);
>> > }
>> > }
>> >
>>
>> It looks good, but we really need to take care of TSO packets.
>
> As notes above, TSO packets are planned as a future feature. Lets
> first see if this works well, without introducing any HoL blocking
> issues or other regressions.
>
>
>> pktgen is nice, but do not represent the majority of the traffic we send
>> from high performance host where we want this bulk dequeue thing ;)
>
> This patch is actually targetted towards more normal use-cases.
> Pktgen cannot even use this work, as it bypass the qdisc layer...
>
> --
> Best regards,
> Jesper Dangaard Brouer
> MSc.CS, Sr. Network Kernel Developer at Red Hat
> Author of http://www.iptv-analyzer.org
> LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* [PATCH 0/4] Fix up remaining defconfigs with missing CONFIG_NET
From: David Miller @ 2014-09-24 18:49 UTC (permalink / raw)
To: netdev; +Cc: linux
This is on top of Michal Marek's series and the IA64 fixups which are
already in Linus's tree.
I validated things two different ways:
1) I scanned every arch config file, and if it mentioned CONFIG_INET or
CONFIG_UNIX, I made sure it had CONFIG_NET=y
2) I scanned every arch config file, and if it did not have CONFIG_NET=y
I made sure it did not reference any networking config options.
Signed-off-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* [PATCH 1/4] mips: Update some more defconfigs which were missing CONFIG_NET.
From: David Miller @ 2014-09-24 18:49 UTC (permalink / raw)
To: netdev; +Cc: linux
Commit df568d8e ("scsi: Use 'depends' with LIBFC instead of
'select'.") removed what happened to be the only instance of 'select
NET'. Defconfigs that were relying on the select now lack networking
support.
Signed-off-by: David S. Miller <davem@davemloft.net>
---
arch/mips/configs/nlm_xlp_defconfig | 1 +
arch/mips/configs/nlm_xlr_defconfig | 1 +
2 files changed, 2 insertions(+)
diff --git a/arch/mips/configs/nlm_xlp_defconfig b/arch/mips/configs/nlm_xlp_defconfig
index 2f660e9..70509a4 100644
--- a/arch/mips/configs/nlm_xlp_defconfig
+++ b/arch/mips/configs/nlm_xlp_defconfig
@@ -63,6 +63,7 @@ CONFIG_MIPS32_O32=y
CONFIG_MIPS32_N32=y
CONFIG_PM_RUNTIME=y
CONFIG_PM_DEBUG=y
+CONFIG_NET=y
CONFIG_PACKET=y
CONFIG_UNIX=y
CONFIG_XFRM_USER=m
diff --git a/arch/mips/configs/nlm_xlr_defconfig b/arch/mips/configs/nlm_xlr_defconfig
index c6f8465..82207e8 100644
--- a/arch/mips/configs/nlm_xlr_defconfig
+++ b/arch/mips/configs/nlm_xlr_defconfig
@@ -43,6 +43,7 @@ CONFIG_PCI_DEBUG=y
CONFIG_BINFMT_MISC=m
CONFIG_PM_RUNTIME=y
CONFIG_PM_DEBUG=y
+CONFIG_NET=y
CONFIG_PACKET=y
CONFIG_UNIX=y
CONFIG_XFRM_USER=m
--
1.7.11.7
^ permalink raw reply related
* [PATCH 2/4] s390: Update defconfigs which were missing CONFIG_NET.
From: David Miller @ 2014-09-24 18:49 UTC (permalink / raw)
To: netdev; +Cc: linux
Commit df568d8e ("scsi: Use 'depends' with LIBFC instead of
'select'.") removed what happened to be the only instance of 'select
NET'. Defconfigs that were relying on the select now lack networking
support.
Signed-off-by: David S. Miller <davem@davemloft.net>
---
arch/s390/configs/default_defconfig | 1 +
arch/s390/configs/gcov_defconfig | 1 +
arch/s390/configs/performance_defconfig | 1 +
arch/s390/configs/zfcpdump_defconfig | 1 +
arch/s390/defconfig | 1 +
5 files changed, 5 insertions(+)
diff --git a/arch/s390/configs/default_defconfig b/arch/s390/configs/default_defconfig
index 3ca1894..9d94fdd 100644
--- a/arch/s390/configs/default_defconfig
+++ b/arch/s390/configs/default_defconfig
@@ -63,6 +63,7 @@ CONFIG_CRASH_DUMP=y
# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
CONFIG_BINFMT_MISC=m
CONFIG_HIBERNATION=y
+CONFIG_NET=y
CONFIG_PACKET=y
CONFIG_PACKET_DIAG=m
CONFIG_UNIX=y
diff --git a/arch/s390/configs/gcov_defconfig b/arch/s390/configs/gcov_defconfig
index 4830aa6..90f514b 100644
--- a/arch/s390/configs/gcov_defconfig
+++ b/arch/s390/configs/gcov_defconfig
@@ -61,6 +61,7 @@ CONFIG_CRASH_DUMP=y
# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
CONFIG_BINFMT_MISC=m
CONFIG_HIBERNATION=y
+CONFIG_NET=y
CONFIG_PACKET=y
CONFIG_PACKET_DIAG=m
CONFIG_UNIX=y
diff --git a/arch/s390/configs/performance_defconfig b/arch/s390/configs/performance_defconfig
index 61db449..13559d3 100644
--- a/arch/s390/configs/performance_defconfig
+++ b/arch/s390/configs/performance_defconfig
@@ -59,6 +59,7 @@ CONFIG_CRASH_DUMP=y
# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
CONFIG_BINFMT_MISC=m
CONFIG_HIBERNATION=y
+CONFIG_NET=y
CONFIG_PACKET=y
CONFIG_PACKET_DIAG=m
CONFIG_UNIX=y
diff --git a/arch/s390/configs/zfcpdump_defconfig b/arch/s390/configs/zfcpdump_defconfig
index 948e0e0..e376789 100644
--- a/arch/s390/configs/zfcpdump_defconfig
+++ b/arch/s390/configs/zfcpdump_defconfig
@@ -23,6 +23,7 @@ CONFIG_CRASH_DUMP=y
# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
# CONFIG_SECCOMP is not set
# CONFIG_IUCV is not set
+CONFIG_NET=y
CONFIG_ATM=y
CONFIG_ATM_LANE=y
CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
diff --git a/arch/s390/defconfig b/arch/s390/defconfig
index 2e56498..fab35a8 100644
--- a/arch/s390/defconfig
+++ b/arch/s390/defconfig
@@ -50,6 +50,7 @@ CONFIG_CMA=y
CONFIG_CRASH_DUMP=y
CONFIG_BINFMT_MISC=m
CONFIG_HIBERNATION=y
+CONFIG_NET=y
CONFIG_PACKET=y
CONFIG_UNIX=y
CONFIG_NET_KEY=y
--
1.7.11.7
^ permalink raw reply related
* [PATCH 3/4] powerpc: Update defconfigs which were missing CONFIG_NET.
From: David Miller @ 2014-09-24 18:49 UTC (permalink / raw)
To: netdev; +Cc: linux
Commit df568d8e ("scsi: Use 'depends' with LIBFC instead of
'select'.") removed what happened to be the only instance of 'select
NET'. Defconfigs that were relying on the select now lack networking
support.
Signed-off-by: David S. Miller <davem@davemloft.net>
---
arch/powerpc/configs/c2k_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/configs/c2k_defconfig b/arch/powerpc/configs/c2k_defconfig
index 5e2aa43..5973491 100644
--- a/arch/powerpc/configs/c2k_defconfig
+++ b/arch/powerpc/configs/c2k_defconfig
@@ -29,6 +29,7 @@ CONFIG_PM=y
CONFIG_PCI_MSI=y
CONFIG_HOTPLUG_PCI=y
CONFIG_HOTPLUG_PCI_SHPC=m
+CONFIG_NET=y
CONFIG_PACKET=y
CONFIG_UNIX=y
CONFIG_XFRM_USER=y
--
1.7.11.7
^ permalink raw reply related
* [PATCH 4/4] parisc: Update defconfigs which were missing CONFIG_NET.
From: David Miller @ 2014-09-24 18:49 UTC (permalink / raw)
To: netdev; +Cc: linux
Commit df568d8e ("scsi: Use 'depends' with LIBFC instead of
'select'.") removed what happened to be the only instance of 'select
NET'. Defconfigs that were relying on the select now lack networking
support.
Signed-off-by: David S. Miller <davem@davemloft.net>
---
arch/parisc/configs/a500_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/parisc/configs/a500_defconfig b/arch/parisc/configs/a500_defconfig
index 9002532..0490199 100644
--- a/arch/parisc/configs/a500_defconfig
+++ b/arch/parisc/configs/a500_defconfig
@@ -31,6 +31,7 @@ CONFIG_PD6729=m
CONFIG_I82092=m
# CONFIG_SUPERIO is not set
# CONFIG_CHASSIS_LCD_LED is not set
+CONFIG_NET=y
CONFIG_PACKET=y
CONFIG_UNIX=y
CONFIG_XFRM_USER=m
--
1.7.11.7
^ permalink raw reply related
* Re: [PATCH net] tcp: Fix TLP implementation in case receive window limits send
From: Yuchung Cheng @ 2014-09-24 18:54 UTC (permalink / raw)
To: Itzcak Pechtalt; +Cc: netdev@vger.kernel.org
In-Reply-To: <6cbd68ba1ef44c5ca4b21bd3f65846af@AM3PR06MB388.eurprd06.prod.outlook.com>
On Tue, Sep 23, 2014 at 9:28 AM, Itzcak Pechtalt
<itzcak@flashnetworks.com> wrote:
> From: Itzcak Pechtalt <itzcak@flashnetworks.com>
>
> TCP Tail loss probe (TLP) algorithm implementation has some problem.
> According to paper (draft-dukkipati-tcpm-tcp-loss-probe-0 ):
> In case recive window of receiver limits send of new packet in probe time than
> a retransmit of last packet send should be done.
>
> Actually, return code from tcp_write_xmit is not checked and only RTO is
> scheduled,
> So, it will take more time for reovery in this case than without TLP.
>
> Signed-off-by: Itzcak Pechtalt <itzcak@flashnetworks.com>
Acked-by: Yuchung Cheng <ycheng@google.com>
> ---
> net/ipv4/tcp_output.c | 2 +-
> 1 file changed, 1 insertions(+), 1 deletions(-)
>
> diff -up a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
> --- a/net/ipv4/tcp_output.c 2014-09-23 18:35:37.113771694 +0300
> +++ b/net/ipv4/tcp_output.c 2014-09-23 18:39:58.207726420 +0300
> @@ -2100,7 +2100,8 @@ void tcp_send_loss_probe(struct sock *sk
>
> if (tcp_send_head(sk) != NULL) {
> err = tcp_write_xmit(sk, mss, TCP_NAGLE_OFF, 2, GFP_ATOMIC);
> - goto rearm_timer;
> + if (!err)
> + goto rearm_timer;
> }
>
> /* At most one outstanding TLP retransmission. */
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net] tcp: Fix TLP implementation in case receive window limits send
From: Nandita Dukkipati @ 2014-09-24 19:00 UTC (permalink / raw)
To: Yuchung Cheng; +Cc: Itzcak Pechtalt, netdev@vger.kernel.org
In-Reply-To: <CAK6E8=fQjqXbbbdCVR-yNBif7C7GRBnPNsq11V7QZbqgb7dtwQ@mail.gmail.com>
> On Tue, Sep 23, 2014 at 9:28 AM, Itzcak Pechtalt
> <itzcak@flashnetworks.com> wrote:
>> From: Itzcak Pechtalt <itzcak@flashnetworks.com>
>>
>> TCP Tail loss probe (TLP) algorithm implementation has some problem.
>> According to paper (draft-dukkipati-tcpm-tcp-loss-probe-0 ):
>> In case recive window of receiver limits send of new packet in probe time than
>> a retransmit of last packet send should be done.
>>
>> Actually, return code from tcp_write_xmit is not checked and only RTO is
>> scheduled,
>> So, it will take more time for reovery in this case than without TLP.
>>
>> Signed-off-by: Itzcak Pechtalt <itzcak@flashnetworks.com>
> Acked-by: Yuchung Cheng <ycheng@google.com>
Acked-by: Nandita Dukkipati <nanditad@google.com>
^ permalink raw reply
* Re: pull request: wireless 2014-09-23
From: David Miller @ 2014-09-24 19:01 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20140923150002.GH23806@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Tue, 23 Sep 2014 11:00:02 -0400
> Please consider pulling this one last batch of fixes intended for the 3.17 stream!
>
> For the NFC bits, Samuel says:
>
> "Hopefully not too late for a handful of NFC fixes:
>
> - 2 potential build failures for ST21NFCA and ST21NFCB, triggered by a
> depmod dependenyc cycle.
> - One potential buffer overflow in the microread driver."
>
> On top of that...
>
> Emil Goode provides a fix for a brcmfmac off-by-one regression which
> was introduced in the 3.17 cycle.
>
> Loic Poulain fixes a polarity mismatch for a variable assignment
> inside of rfkill-gpio.
>
> Wojciech Dubowik prevents a NULL pointer dereference in ath9k.
>
> Please let me know if there are problems!
Pulled, thanks John.
^ permalink raw reply
* Re: [PATCH net] sparc: bpf_jit: fix loads from negative offsets
From: David Miller @ 2014-09-24 19:08 UTC (permalink / raw)
To: ast; +Cc: netdev
In-Reply-To: <1411505410-25215-1-git-send-email-ast@plumgrid.com>
From: Alexei Starovoitov <ast@plumgrid.com>
Date: Tue, 23 Sep 2014 13:50:10 -0700
> - fix BPF_LD|ABS|IND from negative offsets:
> make sure to sign extend lower 32 bits in 64-bit register
> before calling C helpers from JITed code, otherwise 'int k'
> argument of bpf_internal_load_pointer_neg_helper() function
> will be added as large unsigned integer, causing packet size
> check to trigger and abort the program.
>
> It's worth noting that JITed code for 'A = A op K' will affect
> upper 32 bits differently depending whether K is simm13 or not.
> Since small constants are sign extended, whereas large constants
> are stored in temp register and zero extended.
> That is ok and we don't have to pay a penalty of sign extension
> for every sethi, since all classic BPF instructions have 32-bit
> semantics and we only need to set correct upper bits when
> transitioning from JITed code into C.
>
> - though instructions 'A &= 0' and 'A *= 0' are odd, JIT compiler
> should not optimize them out
>
> Signed-off-by: Alexei Starovoitov <ast@plumgrid.com>
Applied, thanks for fixing this.
What we could do longer-term is change is_simm13() into is_simm12()
and therefore know that all constants loaded are 32-bit zero extended
regardless of size.
BTW, there is a trick to load arbitrary negative 32-bit constants sign
extended to 64-bit, in just two instructions:
sethi %(~value), reg
xor reg, ~(0x400 | (value & 0x3ff)), reg
Or something like that, it's been a while. GCC knows how to emit
that sequence too.
Anyways, we could adjust the JIT to do that too.
^ permalink raw reply
* Re: Fw: [Bug 85091] New: neighbour table overflow is not reported and impacts localhost TCP connectivity
From: Cong Wang @ 2014-09-24 19:11 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20140924093216.083c77b4@urahara>
On Wed, Sep 24, 2014 at 9:32 AM, Stephen Hemminger
<stephen@networkplumber.org> wrote:
> Result:
>
> Kernel has to learn the 16k IP/MAC combinations, as soon as gc_thresh3 is hit,
> netperf stalls, no syslog/kernel message indicates the problem.
>
> The only indication are log entries like this:
>
> "net_ratelimit: 1464 callbacks suppressed"
>
> No other messages are logged.
>
Looks like we have a race condition between we check gc_thresh3
and add the new entry into the table after locking in __neigh_create().
Otherwise the application layer should get EINVAL to stop.
^ permalink raw reply
* Re: [net-next PATCH 1/1 V4] qdisc: bulk dequeue support for qdiscs with TCQ_F_ONETXQUEUE
From: Eric Dumazet @ 2014-09-24 19:22 UTC (permalink / raw)
To: Tom Herbert
Cc: Jesper Dangaard Brouer, Linux Netdev List, David S. Miller,
Alexander Duyck, Toke Høiland-Jørgensen,
Florian Westphal, Jamal Hadi Salim, Dave Taht, John Fastabend,
Daniel Borkmann, Hannes Frederic Sowa
In-Reply-To: <CA+mtBx8s63TDe1XS7TzfscwhiRCgyeLkKLz2p-4et1erX0-dUQ@mail.gmail.com>
On Wed, 2014-09-24 at 11:34 -0700, Tom Herbert wrote:
> >
> I believe drivers typically use skb->len for BQL tracking. Since
> bytelimit is based on BQL here, it might be more correct to use
> skb->len.
That is only because drivers dont have access to qdisc_pkt_len(skb) as :
- We can call them without any qdisc traversal
- We escaped from qdisc layer, and gso packet do not have the field set
And drivers actually update BQL inflight, while bulk dequeue do not
update it (its a local copy)
I do not particularly care, as BQL do not have to be 100% precise.
^ permalink raw reply
* Re: [RFC PATCH 15/24] net: rbridge: Add basic trill frame handling function
From: Francois Romieu @ 2014-09-24 19:23 UTC (permalink / raw)
To: Ahmed Amamou; +Cc: netdev, william, f.cachereul, Kamel Haddadou
In-Reply-To: <1411573940-14079-16-git-send-email-ahmed@gandi.net>
Ahmed Amamou <ahmed@gandi.net> :
[...]
> diff --git a/net/bridge/rbridge/rbr.c b/net/bridge/rbridge/rbr.c
> index edd1e7c..4b41d4c 100644
> --- a/net/bridge/rbridge/rbr.c
> +++ b/net/bridge/rbridge/rbr.c
> @@ -129,3 +129,103 @@ static void rbr_del_all(struct rbr *rbr)
[...]
> + /* if trill is not enabled, handle by bridge */
> + if (br->trill_enabled == BR_NO_TRILL) {
> + goto handle_by_bridge;
> + } else {
No need for an 'else' branch after a 'goto'. Please save an indent level.
Same remark apply in patches #19 and and #21 (almost: 'else' before 'goto').
--
Ueimor
^ permalink raw reply
* Re: [PATCH net] tcp: Fix TLP implementation in case receive window limits send
From: Neal Cardwell @ 2014-09-24 19:25 UTC (permalink / raw)
To: Nandita Dukkipati; +Cc: Yuchung Cheng, Itzcak Pechtalt, netdev@vger.kernel.org
In-Reply-To: <CAB_+Fg69V2msVt3dr76VrgdYBOivjsRnvwBAuSWpi-v7Jkd+6Q@mail.gmail.com>
On Wed, Sep 24, 2014 at 3:00 PM, Nandita Dukkipati <nanditad@google.com> wrote:
>> On Tue, Sep 23, 2014 at 9:28 AM, Itzcak Pechtalt
>> <itzcak@flashnetworks.com> wrote:
>>> From: Itzcak Pechtalt <itzcak@flashnetworks.com>
>>>
>>> TCP Tail loss probe (TLP) algorithm implementation has some problem.
>>> According to paper (draft-dukkipati-tcpm-tcp-loss-probe-0 ):
>>> In case recive window of receiver limits send of new packet in probe time than
>>> a retransmit of last packet send should be done.
>>>
>>> Actually, return code from tcp_write_xmit is not checked and only RTO is
>>> scheduled,
>>> So, it will take more time for reovery in this case than without TLP.
>>>
>>> Signed-off-by: Itzcak Pechtalt <itzcak@flashnetworks.com>
>> Acked-by: Yuchung Cheng <ycheng@google.com>
> Acked-by: Nandita Dukkipati <nanditad@google.com>
Acked-by: Neal Cardwell <ncardwell@google.com>
BTW, Itzcak, have you been able to construct a test case where
this patch now allows a TLP in a case where the sender is limited
by the receive window?
Often we will be prevented from doing any kind of TLP if we are
limited by the receive window, due to these lines in
tcp_schedule_loss_probe():
if ((tp->snd_cwnd > tcp_packets_in_flight(tp)) &&
tcp_send_head(sk))
return false;
But there is something else going on as well, since I haven't been
able to force a TLP even when cwnd == rwin == tcp_packets_in_flight()
== 10. But I haven't had much time to spend on it.
neal
^ 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