* Re: [patch net-next v3 04/17] net: introduce generic switch devices support
From: Jamal Hadi Salim @ 2014-11-25 15:51 UTC (permalink / raw)
To: Jiri Pirko, netdev
Cc: davem, nhorman, andy, tgraf, dborkman, ogerlitz, jesse, pshelar,
azhou, ben, stephen, jeffrey.t.kirsher, vyasevic, xiyou.wangcong,
john.r.fastabend, edumazet, sfeldma, f.fainelli, roopa, linville,
jasowang, ebiederm, nicolas.dichtel, ryazanov.s.a, buytenh,
aviadr, nbd, alexei.starovoitov, Neil.Jerram, ronye, simon.horman,
alexander.h.duyck, john.ronciak, mleitner, shrijeet, gospo, bcrl
In-Reply-To: <1416911328-10979-5-git-send-email-jiri@resnulli.us>
On 11/25/14 05:28, Jiri Pirko wrote:
> The goal of this is to provide a possibility to support various switch
> chips. Drivers should implement relevant ndos to do so. Now there is
> only one ndo defined:
> - for getting physical switch id is in place.
>
I am not sure switch id is the right term. I have a network processor
that *does not* do switching. I am not sure if "chip" or "ASIC" or
"offload_id" would be the right term. switch doesnt sound right.
cheers,
jamal
^ permalink raw reply
* Re: [patch net-next v3 06/17] net-sysfs: expose physical switch id for particular device
From: Jamal Hadi Salim @ 2014-11-25 15:53 UTC (permalink / raw)
To: Jiri Pirko, netdev
Cc: davem, nhorman, andy, tgraf, dborkman, ogerlitz, jesse, pshelar,
azhou, ben, stephen, jeffrey.t.kirsher, vyasevic, xiyou.wangcong,
john.r.fastabend, edumazet, sfeldma, f.fainelli, roopa, linville,
jasowang, ebiederm, nicolas.dichtel, ryazanov.s.a, buytenh,
aviadr, nbd, alexei.starovoitov, Neil.Jerram, ronye, simon.horman,
alexander.h.duyck, john.ronciak, mleitner, shrijeet, gospo, bcrl
In-Reply-To: <1416911328-10979-7-git-send-email-jiri@resnulli.us>
On 11/25/14 05:28, Jiri Pirko wrote:
> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
> Reviewed-by: Thomas Graf <tgraf@suug.ch>
> Acked-by: John Fastabend <john.r.fastabend@intel.com>
> ---
> v2->v3:
> -changed "sw" string to "switch" to avoid confusion
> v1->v2:
> -no change
tied to patches 5 and 4 in terms of the noun used.
cheers,
jamal
^ permalink raw reply
* Re: linux-next: manual merge of the net-next tree with the vfs tree
From: Pablo Neira Ayuso @ 2014-11-25 15:56 UTC (permalink / raw)
To: Marcelo Ricardo Leitner
Cc: Stephen Rothwell, David Miller, netdev, Al Viro, linux-next,
linux-kernel, Steven Rostedt (Red Hat)
In-Reply-To: <547466C8.1000203@redhat.com>
On Tue, Nov 25, 2014 at 09:23:52AM -0200, Marcelo Ricardo Leitner wrote:
> On 25-11-2014 00:42, Stephen Rothwell wrote:
> >Hi all,
> >
> >Today's linux-next merge of the net-next tree got a conflict in
> >net/netfilter/nf_log.c between commit e71456ae9871 ("netfilter: Remove
> >checks of seq_printf() return values") from the vfs tree and commit
> >0c26ed1c07f1 ("netfilter: nf_log: Introduce nft_log_dereference()
> >macro") from the net-next tree.
> >
> >I fixed it up (see below) and can carry the fix as necessary (no action
> >is required).
> >
>
> Looks good to me, thanks Stephen.
Also to me, thanks Stephen and Marcelo.
^ permalink raw reply
* Re: [patch net-next v3 07/17] rocker: introduce rocker switch driver
From: Jamal Hadi Salim @ 2014-11-25 15:57 UTC (permalink / raw)
To: Jiri Pirko, netdev
Cc: davem, nhorman, andy, tgraf, dborkman, ogerlitz, jesse, pshelar,
azhou, ben, stephen, jeffrey.t.kirsher, vyasevic, xiyou.wangcong,
john.r.fastabend, edumazet, sfeldma, f.fainelli, roopa, linville,
jasowang, ebiederm, nicolas.dichtel, ryazanov.s.a, buytenh,
aviadr, nbd, alexei.starovoitov, Neil.Jerram, ronye, simon.horman,
alexander.h.duyck, john.ronciak, mleitner, shrijeet, gospo, bcrl
In-Reply-To: <1416911328-10979-8-git-send-email-jiri@resnulli.us>
On 11/25/14 05:28, Jiri Pirko wrote:
> This patch introduces the first driver to benefit from the switchdev
> infrastructure and to implement newly introduced switch ndos. This is a
> driver for emulated switch chip implemented in qemu:
> https://github.com/sfeldma/qemu-rocker/
>
> This patch is a result of joint work with Scott Feldman.
>
> Signed-off-by: Scott Feldman <sfeldma@gmail.com>
> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
> Reviewed-by: Thomas Graf <tgraf@suug.ch>
> Reviewed-by: John Fastabend <john.r.fastabend@intel.com>
Users should be a different patch set for easier review.
I think you should separate rocker to be another patch series.
cheers,
jamal
^ permalink raw reply
* Re: [patch net-next v3 08/17] bridge: call netdev_sw_port_stp_update when bridge port STP status changes
From: Andy Gospodarek @ 2014-11-25 15:58 UTC (permalink / raw)
To: Jiri Pirko
Cc: netdev, davem, nhorman, andy, tgraf, dborkman, ogerlitz, jesse,
pshelar, azhou, ben, stephen, jeffrey.t.kirsher, vyasevic,
xiyou.wangcong, john.r.fastabend, edumazet, jhs, sfeldma,
f.fainelli, roopa, linville, jasowang, ebiederm, nicolas.dichtel,
ryazanov.s.a, buytenh, aviadr, nbd, alexei.starovoitov,
Neil.Jerram, ronye, simon.horman, alexander.h.duyck, john.ronciak,
mleitner, shrijeet, bcrl
In-Reply-To: <1416911328-10979-9-git-send-email-jiri@resnulli.us>
On Tue, Nov 25, 2014 at 11:28:39AM +0100, Jiri Pirko wrote:
> From: Scott Feldman <sfeldma@gmail.com>
>
> To notify switch driver of change in STP state of bridge port, add new
> .ndo op and provide switchdev wrapper func to call ndo op. Use it in bridge
> code then.
>
> Signed-off-by: Scott Feldman <sfeldma@gmail.com>
> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
> ---
> v2->v3:
> -changed "sw" string to "switch" to avoid confusion
> v1->v2:
> -no change
> ---
> include/linux/netdevice.h | 5 +++++
> include/net/switchdev.h | 7 +++++++
> net/bridge/br_stp.c | 2 ++
> net/switchdev/switchdev.c | 19 +++++++++++++++++++
> 4 files changed, 33 insertions(+)
>
> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> index ce096dc..66cb64e 100644
> --- a/include/linux/netdevice.h
> +++ b/include/linux/netdevice.h
> @@ -1024,6 +1024,9 @@ typedef u16 (*select_queue_fallback_t)(struct net_device *dev,
> * Called to get an ID of the switch chip this port is part of.
> * If driver implements this, it indicates that it represents a port
> * of a switch chip.
> + * int (*ndo_switch_port_stp_update)(struct net_device *dev, u8 state);
> + * Called to notify switch device port of bridge port STP
> + * state change.
> */
> struct net_device_ops {
> int (*ndo_init)(struct net_device *dev);
> @@ -1180,6 +1183,8 @@ struct net_device_ops {
> #ifdef CONFIG_NET_SWITCHDEV
> int (*ndo_switch_parent_id_get)(struct net_device *dev,
> struct netdev_phys_item_id *psid);
> + int (*ndo_switch_port_stp_update)(struct net_device *dev,
> + u8 state);
> #endif
> };
>
> diff --git a/include/net/switchdev.h b/include/net/switchdev.h
> index 7a52360..8a6d164 100644
> --- a/include/net/switchdev.h
> +++ b/include/net/switchdev.h
> @@ -16,6 +16,7 @@
>
> int netdev_switch_parent_id_get(struct net_device *dev,
> struct netdev_phys_item_id *psid);
> +int netdev_switch_port_stp_update(struct net_device *dev, u8 state);
>
> #else
>
> @@ -25,6 +26,12 @@ static inline int netdev_switch_parent_id_get(struct net_device *dev,
> return -EOPNOTSUPP;
> }
>
> +static inline int netdev_switch_port_stp_update(struct net_device *dev,
> + u8 state)
> +{
> + return -EOPNOTSUPP;
> +}
> +
> #endif
>
> #endif /* _LINUX_SWITCHDEV_H_ */
> diff --git a/net/bridge/br_stp.c b/net/bridge/br_stp.c
> index 2b047bc..35e016c 100644
> --- a/net/bridge/br_stp.c
> +++ b/net/bridge/br_stp.c
> @@ -12,6 +12,7 @@
> */
> #include <linux/kernel.h>
> #include <linux/rculist.h>
> +#include <net/switchdev.h>
>
> #include "br_private.h"
> #include "br_private_stp.h"
> @@ -39,6 +40,7 @@ void br_log_state(const struct net_bridge_port *p)
> void br_set_state(struct net_bridge_port *p, unsigned int state)
> {
> p->state = state;
> + netdev_switch_port_stp_update(p->dev, state);
The only thing that concerns me about this patch is the fact that there
is nothing paying attention to the return code.
This means if *something* in the driver fails to set the STP state we
have no way to feed this information back to the user to let them know
that their hardware isn't exactly functioning as we expect.
I do not expect that this first set would provide full feedback to
br_make_forwarding, br_make_blocking, etc, to allow spanning tree to
properly deal with the failure (that change is fine to add later), but a
short one-liner indicating that the call to the hardware failed would e
good. What about something simple like this:
void br_set_state(struct net_bridge_port *p, unsigned int state)
{
int ret;
p->state = state;
ret = netdev_switch_port_stp_update(p->dev, state);
if (ret && ret != -EOPNOTSUPP)
br_warn(br, "error setting offload STP state for interface %s\n",
p->dev->name);
}
>
> /* called under bridge lock */
> diff --git a/net/switchdev/switchdev.c b/net/switchdev/switchdev.c
> index 66973de..d162b21 100644
> --- a/net/switchdev/switchdev.c
> +++ b/net/switchdev/switchdev.c
> @@ -31,3 +31,22 @@ int netdev_switch_parent_id_get(struct net_device *dev,
> return ops->ndo_switch_parent_id_get(dev, psid);
> }
> EXPORT_SYMBOL(netdev_switch_parent_id_get);
> +
> +/**
> + * netdev_switch_port_stp_update - Notify switch device port of STP
> + * state change
> + * @dev: port device
> + * @state: port STP state
> + *
> + * Notify switch device port of bridge port STP state change.
> + */
> +int netdev_switch_port_stp_update(struct net_device *dev, u8 state)
> +{
> + const struct net_device_ops *ops = dev->netdev_ops;
> +
> + if (!ops->ndo_switch_port_stp_update)
> + return -EOPNOTSUPP;
> + WARN_ON(!ops->ndo_switch_parent_id_get);
> + return ops->ndo_switch_port_stp_update(dev, state);
> +}
> +EXPORT_SYMBOL(netdev_switch_port_stp_update);
> --
> 1.9.3
>
^ permalink raw reply
* Re: [patch net-next v3 09/17] bridge: add API to notify bridge driver of learned FBD on offloaded device
From: Jamal Hadi Salim @ 2014-11-25 16:01 UTC (permalink / raw)
To: Jiri Pirko, netdev
Cc: davem, nhorman, andy, tgraf, dborkman, ogerlitz, jesse, pshelar,
azhou, ben, stephen, jeffrey.t.kirsher, vyasevic, xiyou.wangcong,
john.r.fastabend, edumazet, sfeldma, f.fainelli, roopa, linville,
jasowang, ebiederm, nicolas.dichtel, ryazanov.s.a, buytenh,
aviadr, nbd, alexei.starovoitov, Neil.Jerram, ronye, simon.horman,
alexander.h.duyck, john.ronciak, mleitner, shrijeet, gospo, bcrl
In-Reply-To: <1416911328-10979-10-git-send-email-jiri@resnulli.us>
On 11/25/14 05:28, Jiri Pirko wrote:
> From: Scott Feldman <sfeldma@gmail.com>
>
> When the swdev device learns a new mac/vlan on a port, it sends some async
> notification to the driver and the driver installs an FDB in the device.
> To give a holistic system view, the learned mac/vlan should be reflected
> in the bridge's FBD table, so the user, using normal iproute2 cmds, can view
> what is currently learned by the device. This API on the bridge driver gives
> a way for the swdev driver to install an FBD entry in the bridge FBD table.
> (And remove one).
>
> This is equivalent to the device running these cmds:
>
> bridge fdb [add|del] <mac> dev <dev> vid <vlan id> master
>
> This patch needs some extra eyeballs for review, in paricular around the
> locking and contexts.
>
> Signed-off-by: Scott Feldman <sfeldma@gmail.com>
> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
Like it (thanks for taking the earlier feedback) but I do not see
other issue we discussed on policy attribute check that
says "I need you to sync this from offload/chip to kernel" so for now
only conditional Acked-by: Jamal Hadi Salim <jhs@mojatatu.com>
cheers,
jamal
^ permalink raw reply
* Re: [patch net-next v3 13/17] bridge: move private brport flags to if_bridge.h so port drivers can use flags
From: Andy Gospodarek @ 2014-11-25 16:01 UTC (permalink / raw)
To: Jiri Pirko
Cc: netdev, davem, nhorman, andy, tgraf, dborkman, ogerlitz, jesse,
pshelar, azhou, ben, stephen, jeffrey.t.kirsher, vyasevic,
xiyou.wangcong, john.r.fastabend, edumazet, jhs, sfeldma,
f.fainelli, roopa, linville, jasowang, ebiederm, nicolas.dichtel,
ryazanov.s.a, buytenh, aviadr, nbd, alexei.starovoitov,
Neil.Jerram, ronye, simon.horman, alexander.h.duyck, john.ronciak,
mleitner, shrijeet, bcrl
In-Reply-To: <1416911328-10979-14-git-send-email-jiri@resnulli.us>
On Tue, Nov 25, 2014 at 11:28:44AM +0100, Jiri Pirko wrote:
> From: Scott Feldman <sfeldma@gmail.com>
>
> Signed-off-by: Scott Feldman <sfeldma@gmail.com>
> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
Acked-by: Andy Gospodarek <gospo@cumulusnetworks.com>
> ---
> new in v3
> ---
> include/linux/if_bridge.h | 11 +++++++++++
> net/bridge/br_private.h | 10 ----------
> 2 files changed, 11 insertions(+), 10 deletions(-)
>
> diff --git a/include/linux/if_bridge.h b/include/linux/if_bridge.h
> index fa2eca6..b4bb104 100644
> --- a/include/linux/if_bridge.h
> +++ b/include/linux/if_bridge.h
> @@ -32,6 +32,17 @@ struct br_ip_list {
> struct br_ip addr;
> };
>
> +#define BR_HAIRPIN_MODE 0x00000001
> +#define BR_BPDU_GUARD 0x00000002
> +#define BR_ROOT_BLOCK 0x00000004
> +#define BR_MULTICAST_FAST_LEAVE 0x00000008
> +#define BR_ADMIN_COST 0x00000010
> +#define BR_LEARNING 0x00000020
> +#define BR_FLOOD 0x00000040
> +#define BR_AUTO_MASK (BR_FLOOD | BR_LEARNING)
> +#define BR_PROMISC 0x00000080
> +#define BR_PROXYARP 0x00000100
> +
> extern void brioctl_set(int (*ioctl_hook)(struct net *, unsigned int, void __user *));
>
> typedef int br_should_route_hook_t(struct sk_buff *skb);
> diff --git a/net/bridge/br_private.h b/net/bridge/br_private.h
> index 02cd63b..3116bb0 100644
> --- a/net/bridge/br_private.h
> +++ b/net/bridge/br_private.h
> @@ -164,16 +164,6 @@ struct net_bridge_port
> struct rcu_head rcu;
>
> unsigned long flags;
> -#define BR_HAIRPIN_MODE 0x00000001
> -#define BR_BPDU_GUARD 0x00000002
> -#define BR_ROOT_BLOCK 0x00000004
> -#define BR_MULTICAST_FAST_LEAVE 0x00000008
> -#define BR_ADMIN_COST 0x00000010
> -#define BR_LEARNING 0x00000020
> -#define BR_FLOOD 0x00000040
> -#define BR_AUTO_MASK (BR_FLOOD | BR_LEARNING)
> -#define BR_PROMISC 0x00000080
> -#define BR_PROXYARP 0x00000100
>
> #ifdef CONFIG_BRIDGE_IGMP_SNOOPING
> struct bridge_mcast_own_query ip4_own_query;
> --
> 1.9.3
>
^ permalink raw reply
* Re: [patch net-next v3 10/17] rocker: implement rocker ofdpa flow table manipulation
From: Jamal Hadi Salim @ 2014-11-25 16:03 UTC (permalink / raw)
To: Jiri Pirko, netdev
Cc: davem, nhorman, andy, tgraf, dborkman, ogerlitz, jesse, pshelar,
azhou, ben, stephen, jeffrey.t.kirsher, vyasevic, xiyou.wangcong,
john.r.fastabend, edumazet, sfeldma, f.fainelli, roopa, linville,
jasowang, ebiederm, nicolas.dichtel, ryazanov.s.a, buytenh,
aviadr, nbd, alexei.starovoitov, Neil.Jerram, ronye, simon.horman,
alexander.h.duyck, john.ronciak, mleitner, shrijeet, gospo, bcrl
In-Reply-To: <1416911328-10979-11-git-send-email-jiri@resnulli.us>
On 11/25/14 05:28, Jiri Pirko wrote:
> From: Scott Feldman <sfeldma@gmail.com>
>
> The rocker driver maintains 4 hash tables: flows, groups, FDB, and VLANs.
>
> Flow and group tables track the entries installed to OF-DPA tables,
> per the OF-DPA spec. See OF-DPA spec for full description of fields
> in each flow and group table. New table entries are pushed to the
> device with ADD cmd. Updated entries are pushed to the device with
> MOD cmd. For flow table entries, a crc32 key is made from fields of
> the particular field. For group table entries, the group_id is used
> as the key.
>
> The FDB table tracks fdb entries learned by the device or manually
> pushed to the bridge by the user. A crc32 key is made from the
> port/mac/vlan tuple for the fdb entry.
>
> The VLAN table tracks the ifindex-to-internal-vlan mapping for
> untagged pkts. On ingress, an untagged pkt is inserted with an
> internal VLAN ID based on the input port's current internal VLAN ID.
> The input port's internal VLAN will either be referenced by the port's
> ifindex, if not bridged, or the containing bridge's ifindex, if
> bridged. Since the ifindex space isn't within a fixed range, uses a
> hash table (with ifindex as key) to track internal VLAN ID for a given
> ifindex. The internal VLAN ID range is fixed and currently uses the
> upper 255 VLAN IDs, starting at 0xf00.
>
> Signed-off-by: Scott Feldman <sfeldma@gmail.com>
> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
Same comment as before:
I think Rocker should be a separate patch. I will make time to review
if you do that..
cheers,
jamal
^ permalink raw reply
* Re: [patch net-next v3 15/17] bridge: add new hwmode swdev
From: Roopa Prabhu @ 2014-11-25 16:03 UTC (permalink / raw)
To: Jiri Pirko
Cc: netdev, davem, nhorman, andy, tgraf, dborkman, ogerlitz, jesse,
pshelar, azhou, ben, stephen, jeffrey.t.kirsher, vyasevic,
xiyou.wangcong, john.r.fastabend, edumazet, jhs, sfeldma,
f.fainelli, linville, jasowang, ebiederm, nicolas.dichtel,
ryazanov.s.a, buytenh, aviadr, nbd, alexei.starovoitov,
Neil.Jerram, ronye, simon.horman, alexander.h.duyck, john.ronciak,
mleitner, shrijeet, gospo, bcrl
In-Reply-To: <1416911328-10979-16-git-send-email-jiri@resnulli.us>
On 11/25/14, 2:28 AM, Jiri Pirko wrote:
> From: Scott Feldman <sfeldma@gmail.com>
>
> Current hwmode settings are "vepa" or "veb". These are for NIC interfaces
> with basic bridging function offloaded to HW. Add new "swdev" for full
> switch device offloads.
still voting for a generic feature flag like NETIF_F_HW_OFFLOAD for use
by bridge/bond/vxlan. I can resubmit my patch that does this.
>
> Signed-off-by: Scott Feldman <sfeldma@gmail.com>
> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
> ---
> new in v3
> ---
> include/uapi/linux/if_bridge.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/include/uapi/linux/if_bridge.h b/include/uapi/linux/if_bridge.h
> index da17e45..60425ca 100644
> --- a/include/uapi/linux/if_bridge.h
> +++ b/include/uapi/linux/if_bridge.h
> @@ -105,6 +105,7 @@ struct __fdb_entry {
>
> #define BRIDGE_MODE_VEB 0 /* Default loopback mode */
> #define BRIDGE_MODE_VEPA 1 /* 802.1Qbg defined VEPA mode */
> +#define BRIDGE_MODE_SWDEV 2 /* Full switch device offload */
>
> /* Bridge management nested attributes
> * [IFLA_AF_SPEC] = {
^ permalink raw reply
* Re: [patch net-next v3 02/17] net: make vid as a parameter for ndo_fdb_add/ndo_fdb_del
From: John Fastabend @ 2014-11-25 16:01 UTC (permalink / raw)
To: Jamal Hadi Salim, Jiri Pirko, netdev
Cc: davem, nhorman, andy, tgraf, dborkman, ogerlitz, jesse, pshelar,
azhou, ben, stephen, jeffrey.t.kirsher, vyasevic, xiyou.wangcong,
edumazet, sfeldma, f.fainelli, roopa, linville, jasowang,
ebiederm, nicolas.dichtel, ryazanov.s.a, buytenh, aviadr, nbd,
alexei.starovoitov, Neil.Jerram, ronye, simon.horman,
alexander.h.duyck, john.ronciak, mleitner, shrijeet, gospo, bcrl
In-Reply-To: <5474A25C.3080505@mojatatu.com>
On 11/25/2014 07:38 AM, Jamal Hadi Salim wrote:
> On 11/25/14 05:28, Jiri Pirko wrote:
>> Do the work of parsing NDA_VLAN directly in rtnetlink code, pass simple
>> u16 vid to drivers from there.
>>
>
> Acked-by: Jamal Hadi Salim <jhs@mojatatu.com>
>
> I know this maintains status quo of what is already in the kernel.
> But we need to take care of policy (pass it from user space) which
> dictates how to proceed on failure. Three possible options:
> 1) If something fails just continue with the rest of the transaction.
> Return success if at least one thing succeeds.
I'm not sure how (1) works. We can't just let user-space/management
software run along thinking its configuration is set when its
not. At least it doesn't look very appealing for the software I'm
looking at.
> 2) If something fails stop transaction and return some partial success code
Option (2) is the current behavior of fdb this is straight forward
and punts the complexity to user space. And at least the state is
always known.
> 3) If something fails undo everything that has been done and return failure.
>
Sure this would be nice to have when doing bulk updates and is more
useful on hardware that has a commit phase where updates don't actually
occur until they are committed.
> So two bits from somewhere would be useful to send from userspace->kernel
>
+1 for a follow up patch though.
>
>> +static int fbd_vid_parse(struct nlattr *vlan_attr, u16 *p_vid)
>
> typo fbd_vid_parse -> fdb_vid_parse
>
> cheers,
> jamal
>
>
^ permalink raw reply
* Re: [patch net-next v3 11/17] rocker: implement L2 bridge offloading
From: Jamal Hadi Salim @ 2014-11-25 16:04 UTC (permalink / raw)
To: Jiri Pirko, netdev
Cc: davem, nhorman, andy, tgraf, dborkman, ogerlitz, jesse, pshelar,
azhou, ben, stephen, jeffrey.t.kirsher, vyasevic, xiyou.wangcong,
john.r.fastabend, edumazet, sfeldma, f.fainelli, roopa, linville,
jasowang, ebiederm, nicolas.dichtel, ryazanov.s.a, buytenh,
aviadr, nbd, alexei.starovoitov, Neil.Jerram, ronye, simon.horman,
alexander.h.duyck, john.ronciak, mleitner, shrijeet, gospo, bcrl
In-Reply-To: <1416911328-10979-12-git-send-email-jiri@resnulli.us>
Same comment on rocker.
Please make a separate patch set.
cheers,
jamal
^ permalink raw reply
* Re: [patch net-next v3 12/17] rocker: implement ndo_fdb_dump
From: Jamal Hadi Salim @ 2014-11-25 16:04 UTC (permalink / raw)
To: Jiri Pirko, netdev
Cc: davem, nhorman, andy, tgraf, dborkman, ogerlitz, jesse, pshelar,
azhou, ben, stephen, jeffrey.t.kirsher, vyasevic, xiyou.wangcong,
john.r.fastabend, edumazet, sfeldma, f.fainelli, roopa, linville,
jasowang, ebiederm, nicolas.dichtel, ryazanov.s.a, buytenh,
aviadr, nbd, alexei.starovoitov, Neil.Jerram, ronye, simon.horman,
alexander.h.duyck, john.ronciak, mleitner, shrijeet, gospo, bcrl
In-Reply-To: <1416911328-10979-13-git-send-email-jiri@resnulli.us>
On 11/25/14 05:28, Jiri Pirko wrote:
> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
> ---
> new in v3
Same comment as before on rocker
cheers,
jamal
^ permalink raw reply
* Re: [patch net-next v3 14/17] bridge: add new brport flag LEARNING_SYNC
From: Roopa Prabhu @ 2014-11-25 16:05 UTC (permalink / raw)
To: Jiri Pirko
Cc: netdev, davem, nhorman, andy, tgraf, dborkman, ogerlitz, jesse,
pshelar, azhou, ben, stephen, jeffrey.t.kirsher, vyasevic,
xiyou.wangcong, john.r.fastabend, edumazet, jhs, sfeldma,
f.fainelli, linville, jasowang, ebiederm, nicolas.dichtel,
ryazanov.s.a, buytenh, aviadr, nbd, alexei.starovoitov,
Neil.Jerram, ronye, simon.horman, alexander.h.duyck, john.ronciak,
mleitner, shrijeet, gospo, bcrl
In-Reply-To: <1416911328-10979-15-git-send-email-jiri@resnulli.us>
On 11/25/14, 2:28 AM, Jiri Pirko wrote:
> From: Scott Feldman <sfeldma@gmail.com>
>
> This policy flag controls syncing of learned FDB entries to bridge's FDB. If
> on, FDB entries learned on bridge port device will be synced. If off, device
> may still learn new FDB entries but they will not be synced with bridge's FDB.
>
> Signed-off-by: Scott Feldman <sfeldma@gmail.com>
> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
Acked-by: Roopa Prabhu<roopa@cumulusnetworks.com>
> ---
> new in v3
> ---
> include/linux/if_bridge.h | 1 +
> include/uapi/linux/if_link.h | 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/include/linux/if_bridge.h b/include/linux/if_bridge.h
> index b4bb104..67b7a8e 100644
> --- a/include/linux/if_bridge.h
> +++ b/include/linux/if_bridge.h
> @@ -42,6 +42,7 @@ struct br_ip_list {
> #define BR_AUTO_MASK (BR_FLOOD | BR_LEARNING)
> #define BR_PROMISC 0x00000080
> #define BR_PROXYARP 0x00000100
> +#define BR_LEARNING_SYNC 0x00000200
>
> extern void brioctl_set(int (*ioctl_hook)(struct net *, unsigned int, void __user *));
>
> diff --git a/include/uapi/linux/if_link.h b/include/uapi/linux/if_link.h
> index 4163753..d8e6a31 100644
> --- a/include/uapi/linux/if_link.h
> +++ b/include/uapi/linux/if_link.h
> @@ -245,6 +245,7 @@ enum {
> IFLA_BRPORT_LEARNING, /* mac learning */
> IFLA_BRPORT_UNICAST_FLOOD, /* flood unicast traffic */
> IFLA_BRPORT_PROXYARP, /* proxy ARP */
> + IFLA_BRPORT_LEARNING_SYNC, /* mac learning sync from device */
> __IFLA_BRPORT_MAX
> };
> #define IFLA_BRPORT_MAX (__IFLA_BRPORT_MAX - 1)
^ permalink raw reply
* Re: [patch net-next v3 13/17] bridge: move private brport flags to if_bridge.h so port drivers can use flags
From: Jamal Hadi Salim @ 2014-11-25 16:05 UTC (permalink / raw)
To: Jiri Pirko, netdev
Cc: davem, nhorman, andy, tgraf, dborkman, ogerlitz, jesse, pshelar,
azhou, ben, stephen, jeffrey.t.kirsher, vyasevic, xiyou.wangcong,
john.r.fastabend, edumazet, sfeldma, f.fainelli, roopa, linville,
jasowang, ebiederm, nicolas.dichtel, ryazanov.s.a, buytenh,
aviadr, nbd, alexei.starovoitov, Neil.Jerram, ronye, simon.horman,
alexander.h.duyck, john.ronciak, mleitner, shrijeet, gospo, bcrl
In-Reply-To: <1416911328-10979-14-git-send-email-jiri@resnulli.us>
On 11/25/14 05:28, Jiri Pirko wrote:
> From: Scott Feldman <sfeldma@gmail.com>
>
> Signed-off-by: Scott Feldman <sfeldma@gmail.com>
> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
> ---
Acked-by: Jamal Hadi Salim <jhs@mojatatu.com>
cheers,
jamal
^ permalink raw reply
* Re: [patch net-next v3 14/17] bridge: add new brport flag LEARNING_SYNC
From: Jamal Hadi Salim @ 2014-11-25 16:06 UTC (permalink / raw)
To: Jiri Pirko, netdev
Cc: davem, nhorman, andy, tgraf, dborkman, ogerlitz, jesse, pshelar,
azhou, ben, stephen, jeffrey.t.kirsher, vyasevic, xiyou.wangcong,
john.r.fastabend, edumazet, sfeldma, f.fainelli, roopa, linville,
jasowang, ebiederm, nicolas.dichtel, ryazanov.s.a, buytenh,
aviadr, nbd, alexei.starovoitov, Neil.Jerram, ronye, simon.horman,
alexander.h.duyck, john.ronciak, mleitner, shrijeet, gospo, bcrl
In-Reply-To: <1416911328-10979-15-git-send-email-jiri@resnulli.us>
On 11/25/14 05:28, Jiri Pirko wrote:
> From: Scott Feldman <sfeldma@gmail.com>
>
> This policy flag controls syncing of learned FDB entries to bridge's FDB. If
> on, FDB entries learned on bridge port device will be synced. If off, device
> may still learn new FDB entries but they will not be synced with bridge's FDB.
>
> Signed-off-by: Scott Feldman <sfeldma@gmail.com>
> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
Ah - so this is hiding over here.
If you introduced this patch first then showed in patch 9 that *it is
checked against* for policy, then you can add my ACK for both
cheers,
jamal
^ permalink raw reply
* Re: [patch net-next v3 04/17] net: introduce generic switch devices support
From: Roopa Prabhu @ 2014-11-25 16:07 UTC (permalink / raw)
To: Jiri Pirko
Cc: netdev, davem, nhorman, andy, tgraf, dborkman, ogerlitz, jesse,
pshelar, azhou, ben, stephen, jeffrey.t.kirsher, vyasevic,
xiyou.wangcong, john.r.fastabend, edumazet, jhs, sfeldma,
f.fainelli, linville, jasowang, ebiederm, nicolas.dichtel,
ryazanov.s.a, buytenh, aviadr, nbd, alexei.starovoitov,
Neil.Jerram, ronye, simon.horman, alexander.h.duyck, john.ronciak,
mleitner, shrijeet, gospo, bcrl
In-Reply-To: <1416911328-10979-5-git-send-email-jiri@resnulli.us>
On 11/25/14, 2:28 AM, Jiri Pirko wrote:
> The goal of this is to provide a possibility to support various switch
> chips. Drivers should implement relevant ndos to do so. Now there is
> only one ndo defined:
> - for getting physical switch id is in place.
>
> Note that user can use random port netdevice to access the switch.
>
> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
> Reviewed-by: Thomas Graf <tgraf@suug.ch>
> ---
> v2->v3:
> -fixed documentation typo pointed out by M. Braun
> -changed "sw" string to "switch" to avoid confusion
Still voting for something generic like "hw" or "offload" or "hw_offload"
> v1->v2:
> -no change
> ---
> Documentation/networking/switchdev.txt | 59 ++++++++++++++++++++++++++++++++++
> MAINTAINERS | 7 ++++
> include/linux/netdevice.h | 10 ++++++
> include/net/switchdev.h | 30 +++++++++++++++++
> net/Kconfig | 1 +
> net/Makefile | 3 ++
> net/switchdev/Kconfig | 13 ++++++++
> net/switchdev/Makefile | 5 +++
> net/switchdev/switchdev.c | 33 +++++++++++++++++++
> 9 files changed, 161 insertions(+)
> create mode 100644 Documentation/networking/switchdev.txt
> create mode 100644 include/net/switchdev.h
> create mode 100644 net/switchdev/Kconfig
> create mode 100644 net/switchdev/Makefile
> create mode 100644 net/switchdev/switchdev.c
>
> diff --git a/Documentation/networking/switchdev.txt b/Documentation/networking/switchdev.txt
> new file mode 100644
> index 0000000..f981a92
> --- /dev/null
> +++ b/Documentation/networking/switchdev.txt
> @@ -0,0 +1,59 @@
> +Switch (and switch-ish) device drivers HOWTO
> +===========================
> +
> +Please note that the word "switch" is here used in very generic meaning.
> +This include devices supporting L2/L3 but also various flow offloading chips,
> +including switches embedded into SR-IOV NICs.
> +
> +Lets describe a topology a bit. Imagine the following example:
> +
> + +----------------------------+ +---------------+
> + | SOME switch chip | | CPU |
> + +----------------------------+ +---------------+
> + port1 port2 port3 port4 MNGMNT | PCI-E |
> + | | | | | +---------------+
> + PHY PHY | | | | NIC0 NIC1
> + | | | | | |
> + | | +- PCI-E -+ | |
> + | +------- MII -------+ |
> + +------------- MII ------------+
> +
> +In this example, there are two independent lines between the switch silicon
> +and CPU. NIC0 and NIC1 drivers are not aware of a switch presence. They are
> +separate from the switch driver. SOME switch chip is by managed by a driver
> +via PCI-E device MNGMNT. Note that MNGMNT device, NIC0 and NIC1 may be
> +connected to some other type of bus.
> +
> +Now, for the previous example show the representation in kernel:
> +
> + +----------------------------+ +---------------+
> + | SOME switch chip | | CPU |
> + +----------------------------+ +---------------+
> + sw0p0 sw0p1 sw0p2 sw0p3 MNGMNT | PCI-E |
> + | | | | | +---------------+
> + PHY PHY | | | | eth0 eth1
> + | | | | | |
> + | | +- PCI-E -+ | |
> + | +------- MII -------+ |
> + +------------- MII ------------+
> +
> +Lets call the example switch driver for SOME switch chip "SOMEswitch". This
> +driver takes care of PCI-E device MNGMNT. There is a netdevice instance sw0pX
> +created for each port of a switch. These netdevices are instances
> +of "SOMEswitch" driver. sw0pX netdevices serve as a "representation"
> +of the switch chip. eth0 and eth1 are instances of some other existing driver.
> +
> +The only difference of the switch-port netdevice from the ordinary netdevice
> +is that is implements couple more NDOs:
> +
> + ndo_switch_parent_id_get - This returns the same ID for two port netdevices
> + of the same physical switch chip. This is
> + mandatory to be implemented by all switch drivers
> + and serves the caller for recognition of a port
> + netdevice.
> + ndo_switch_parent_* - Functions that serve for a manipulation of the switch
> + chip itself (it can be though of as a "parent" of the
> + port, therefore the name). They are not port-specific.
> + Caller might use arbitrary port netdevice of the same
> + switch and it will make no difference.
> + ndo_switch_port_* - Functions that serve for a port-specific manipulation.
> diff --git a/MAINTAINERS b/MAINTAINERS
> index a545d68..05addb6 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -9058,6 +9058,13 @@ F: lib/swiotlb.c
> F: arch/*/kernel/pci-swiotlb.c
> F: include/linux/swiotlb.h
>
> +SWITCHDEV
> +M: Jiri Pirko <jiri@resnulli.us>
> +L: netdev@vger.kernel.org
> +S: Supported
> +F: net/switchdev/
> +F: include/net/switchdev.h
> +
> SYNOPSYS ARC ARCHITECTURE
> M: Vineet Gupta <vgupta@synopsys.com>
> S: Supported
> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> index 5b491b3..ce096dc 100644
> --- a/include/linux/netdevice.h
> +++ b/include/linux/netdevice.h
> @@ -1018,6 +1018,12 @@ typedef u16 (*select_queue_fallback_t)(struct net_device *dev,
> * performing GSO on a packet. The device returns true if it is
> * able to GSO the packet, false otherwise. If the return value is
> * false the stack will do software GSO.
> + *
> + * int (*ndo_switch_parent_id_get)(struct net_device *dev,
> + * struct netdev_phys_item_id *psid);
> + * Called to get an ID of the switch chip this port is part of.
> + * If driver implements this, it indicates that it represents a port
> + * of a switch chip.
> */
> struct net_device_ops {
> int (*ndo_init)(struct net_device *dev);
> @@ -1171,6 +1177,10 @@ struct net_device_ops {
> int (*ndo_get_lock_subclass)(struct net_device *dev);
> bool (*ndo_gso_check) (struct sk_buff *skb,
> struct net_device *dev);
> +#ifdef CONFIG_NET_SWITCHDEV
> + int (*ndo_switch_parent_id_get)(struct net_device *dev,
> + struct netdev_phys_item_id *psid);
> +#endif
> };
>
> /**
> diff --git a/include/net/switchdev.h b/include/net/switchdev.h
> new file mode 100644
> index 0000000..7a52360
> --- /dev/null
> +++ b/include/net/switchdev.h
> @@ -0,0 +1,30 @@
> +/*
> + * include/net/switchdev.h - Switch device API
> + * Copyright (c) 2014 Jiri Pirko <jiri@resnulli.us>
> + *
> + * 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 _LINUX_SWITCHDEV_H_
> +#define _LINUX_SWITCHDEV_H_
> +
> +#include <linux/netdevice.h>
> +
> +#ifdef CONFIG_NET_SWITCHDEV
> +
> +int netdev_switch_parent_id_get(struct net_device *dev,
> + struct netdev_phys_item_id *psid);
> +
> +#else
> +
> +static inline int netdev_switch_parent_id_get(struct net_device *dev,
> + struct netdev_phys_item_id *psid)
> +{
> + return -EOPNOTSUPP;
> +}
> +
> +#endif
> +
> +#endif /* _LINUX_SWITCHDEV_H_ */
> diff --git a/net/Kconfig b/net/Kconfig
> index 99815b5..ff9ffc1 100644
> --- a/net/Kconfig
> +++ b/net/Kconfig
> @@ -228,6 +228,7 @@ source "net/vmw_vsock/Kconfig"
> source "net/netlink/Kconfig"
> source "net/mpls/Kconfig"
> source "net/hsr/Kconfig"
> +source "net/switchdev/Kconfig"
>
> config RPS
> boolean
> diff --git a/net/Makefile b/net/Makefile
> index 7ed1970..95fc694 100644
> --- a/net/Makefile
> +++ b/net/Makefile
> @@ -73,3 +73,6 @@ obj-$(CONFIG_OPENVSWITCH) += openvswitch/
> obj-$(CONFIG_VSOCKETS) += vmw_vsock/
> obj-$(CONFIG_NET_MPLS_GSO) += mpls/
> obj-$(CONFIG_HSR) += hsr/
> +ifneq ($(CONFIG_NET_SWITCHDEV),)
> +obj-y += switchdev/
> +endif
> diff --git a/net/switchdev/Kconfig b/net/switchdev/Kconfig
> new file mode 100644
> index 0000000..1557545
> --- /dev/null
> +++ b/net/switchdev/Kconfig
> @@ -0,0 +1,13 @@
> +#
> +# Configuration for Switch device support
> +#
> +
> +config NET_SWITCHDEV
> + boolean "Switch (and switch-ish) device support (EXPERIMENTAL)"
> + depends on INET
> + ---help---
> + This module provides glue between core networking code and device
> + drivers in order to support hardware switch chips in very generic
> + meaning of the word "switch". This include devices supporting L2/L3 but
> + also various flow offloading chips, including switches embedded into
> + SR-IOV NICs.
> diff --git a/net/switchdev/Makefile b/net/switchdev/Makefile
> new file mode 100644
> index 0000000..5ed63ed
> --- /dev/null
> +++ b/net/switchdev/Makefile
> @@ -0,0 +1,5 @@
> +#
> +# Makefile for the Switch device API
> +#
> +
> +obj-$(CONFIG_NET_SWITCHDEV) += switchdev.o
> diff --git a/net/switchdev/switchdev.c b/net/switchdev/switchdev.c
> new file mode 100644
> index 0000000..66973de
> --- /dev/null
> +++ b/net/switchdev/switchdev.c
> @@ -0,0 +1,33 @@
> +/*
> + * net/switchdev/switchdev.c - Switch device API
> + * Copyright (c) 2014 Jiri Pirko <jiri@resnulli.us>
> + *
> + * 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 <linux/kernel.h>
> +#include <linux/types.h>
> +#include <linux/init.h>
> +#include <linux/netdevice.h>
> +#include <net/switchdev.h>
> +
> +/**
> + * netdev_switch_parent_id_get - Get ID of a switch
> + * @dev: port device
> + * @psid: switch ID
> + *
> + * Get ID of a switch this port is part of.
> + */
> +int netdev_switch_parent_id_get(struct net_device *dev,
> + struct netdev_phys_item_id *psid)
> +{
> + const struct net_device_ops *ops = dev->netdev_ops;
> +
> + if (!ops->ndo_switch_parent_id_get)
> + return -EOPNOTSUPP;
> + return ops->ndo_switch_parent_id_get(dev, psid);
> +}
> +EXPORT_SYMBOL(netdev_switch_parent_id_get);
^ permalink raw reply
* Re: [patch net-next v3 15/17] bridge: add new hwmode swdev
From: Jamal Hadi Salim @ 2014-11-25 16:07 UTC (permalink / raw)
To: Jiri Pirko, netdev
Cc: davem, nhorman, andy, tgraf, dborkman, ogerlitz, jesse, pshelar,
azhou, ben, stephen, jeffrey.t.kirsher, vyasevic, xiyou.wangcong,
john.r.fastabend, edumazet, sfeldma, f.fainelli, roopa, linville,
jasowang, ebiederm, nicolas.dichtel, ryazanov.s.a, buytenh,
aviadr, nbd, alexei.starovoitov, Neil.Jerram, ronye, simon.horman,
alexander.h.duyck, john.ronciak, mleitner, shrijeet, gospo, bcrl
In-Reply-To: <1416911328-10979-16-git-send-email-jiri@resnulli.us>
On 11/25/14 05:28, Jiri Pirko wrote:
> From: Scott Feldman <sfeldma@gmail.com>
>
> Current hwmode settings are "vepa" or "veb". These are for NIC interfaces
> with basic bridging function offloaded to HW. Add new "swdev" for full
> switch device offloads.
>
> Signed-off-by: Scott Feldman <sfeldma@gmail.com>
> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
> ---
> new in v3
> ---
> include/uapi/linux/if_bridge.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/include/uapi/linux/if_bridge.h b/include/uapi/linux/if_bridge.h
> index da17e45..60425ca 100644
> --- a/include/uapi/linux/if_bridge.h
> +++ b/include/uapi/linux/if_bridge.h
> @@ -105,6 +105,7 @@ struct __fdb_entry {
>
> #define BRIDGE_MODE_VEB 0 /* Default loopback mode */
> #define BRIDGE_MODE_VEPA 1 /* 802.1Qbg defined VEPA mode */
> +#define BRIDGE_MODE_SWDEV 2 /* Full switch device offload */
>
> /* Bridge management nested attributes
> * [IFLA_AF_SPEC] = {
>
Again - Why is this not a generic interface the way Roopa had it?
We need to do offloads for a lot of other things than just bridge..
cheers,
jamal
^ permalink raw reply
* Re: [patch net-next v3 16/17] bridge: add brport flags to dflt bridge_getlink
From: Jamal Hadi Salim @ 2014-11-25 16:08 UTC (permalink / raw)
To: Jiri Pirko, netdev
Cc: davem, nhorman, andy, tgraf, dborkman, ogerlitz, jesse, pshelar,
azhou, ben, stephen, jeffrey.t.kirsher, vyasevic, xiyou.wangcong,
john.r.fastabend, edumazet, sfeldma, f.fainelli, roopa, linville,
jasowang, ebiederm, nicolas.dichtel, ryazanov.s.a, buytenh,
aviadr, nbd, alexei.starovoitov, Neil.Jerram, ronye, simon.horman,
alexander.h.duyck, john.ronciak, mleitner, shrijeet, gospo, bcrl
In-Reply-To: <1416911328-10979-17-git-send-email-jiri@resnulli.us>
On 11/25/14 05:28, Jiri Pirko wrote:
> From: Scott Feldman <sfeldma@gmail.com>
>
> To allow brport device to return current brport flags set on port. Add
> returned flags to nested IFLA_PROTINFO netlink msg built in dflt getlink.
> With this change, netlink msg returned for bridge_getlink contains the port's
> offloaded flag settings (the port's SELF settings).
>
> Signed-off-by: Scott Feldman <sfeldma@gmail.com>
> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
Not sure i followed this. VEPA etc are offload modes, no?
I like the harvesting from netlink->internal format but
not sure i followed the rest: VEPA etc are offload modes, no?
cheers,
jamal
^ permalink raw reply
* Re: [patch net-next v3 17/17] rocker: add ndo_bridge_setlnk/getlink support for learning policy
From: Jamal Hadi Salim @ 2014-11-25 16:09 UTC (permalink / raw)
To: Jiri Pirko, netdev
Cc: davem, nhorman, andy, tgraf, dborkman, ogerlitz, jesse, pshelar,
azhou, ben, stephen, jeffrey.t.kirsher, vyasevic, xiyou.wangcong,
john.r.fastabend, edumazet, sfeldma, f.fainelli, roopa, linville,
jasowang, ebiederm, nicolas.dichtel, ryazanov.s.a, buytenh,
aviadr, nbd, alexei.starovoitov, Neil.Jerram, ronye, simon.horman,
alexander.h.duyck, john.ronciak, mleitner, shrijeet, gospo, bcrl
In-Reply-To: <1416911328-10979-18-git-send-email-jiri@resnulli.us>
On 11/25/14 05:28, Jiri Pirko wrote:
> From: Scott Feldman <sfeldma@gmail.com>
>
> Rocker ports will use new "swdev" hwmode for bridge port offload policy.
> Current supported policy settings are BR_LEARNING and BR_LEARNING_SYNC.
> User can turn on/off device port FDB learning and syncing to bridge.
>
> Signed-off-by: Scott Feldman <sfeldma@gmail.com>
> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
as previous comments - please submit rocker separately
cheers,
jamal
^ permalink raw reply
* RE: [patch net-next v3 07/17] rocker: introduce rocker switch driver
From: David Laight @ 2014-11-25 16:13 UTC (permalink / raw)
To: 'Jiri Pirko', netdev@vger.kernel.org
Cc: davem@davemloft.net, nhorman@tuxdriver.com, andy@greyhouse.net,
tgraf@suug.ch, dborkman@redhat.com, ogerlitz@mellanox.com,
jesse@nicira.com, pshelar@nicira.com, azhou@nicira.com,
ben@decadent.org.uk, stephen@networkplumber.org,
jeffrey.t.kirsher@intel.com, vyasevic@redhat.com,
xiyou.wangcong@gmail.com, john.r.fastabend@intel.com,
edumazet@google.com, jhs@mojatatu.com, sfeldma@gmail.com,
f.fainelli@gmail.com
In-Reply-To: <1416911328-10979-8-git-send-email-jiri@resnulli.us>
From: Jiri Pirko
>
> This patch introduces the first driver to benefit from the switchdev
> infrastructure and to implement newly introduced switch ndos. This is a
> driver for emulated switch chip implemented in qemu:
> https://github.com/sfeldma/qemu-rocker/
If this driver caller 'rocker' just to get the (bad) pun 'rocker switch'?
IMHO A more descriptive name would be a lot better.
David
^ permalink raw reply
* Re: [patch net-next v3 15/17] bridge: add new hwmode swdev
From: Andy Gospodarek @ 2014-11-25 16:17 UTC (permalink / raw)
To: Roopa Prabhu
Cc: Jiri Pirko, netdev, davem, nhorman, andy, tgraf, dborkman,
ogerlitz, jesse, pshelar, azhou, ben, stephen, jeffrey.t.kirsher,
vyasevic, xiyou.wangcong, john.r.fastabend, edumazet, jhs,
sfeldma, f.fainelli, linville, jasowang, ebiederm,
nicolas.dichtel, ryazanov.s.a, buytenh, aviadr, nbd,
alexei.starovoitov, Neil.Jerram, ronye, simon.horman,
alexander.h.duyck, john.ronciak, mleitner, shrijeet, bcrl
In-Reply-To: <5474A83F.7040006@cumulusnetworks.com>
On Tue, Nov 25, 2014 at 08:03:11AM -0800, Roopa Prabhu wrote:
> On 11/25/14, 2:28 AM, Jiri Pirko wrote:
> >From: Scott Feldman <sfeldma@gmail.com>
> >
> >Current hwmode settings are "vepa" or "veb". These are for NIC interfaces
> >with basic bridging function offloaded to HW. Add new "swdev" for full
> >switch device offloads.
>
> still voting for a generic feature flag like NETIF_F_HW_OFFLOAD for use by
> bridge/bond/vxlan. I can resubmit my patch that does this.
I know it is _early_ to propose this, but I would even suggest this:
diff --git a/include/linux/netdev_features.h b/include/linux/netdev_features.h
index 8e30685..6cea162 100644
--- a/include/linux/netdev_features.h
+++ b/include/linux/netdev_features.h
@@ -124,6 +124,7 @@ enum {
#define NETIF_F_HW_VLAN_STAG_TX __NETIF_F(HW_VLAN_STAG_TX)
#define NETIF_F_HW_L2FW_DOFFLOAD __NETIF_F(HW_L2FW_DOFFLOAD)
#define NETIF_F_BUSY_POLL __NETIF_F(BUSY_POLL)
+#define NETIF_F_HW_SWITCHING __NETIF_F(HW_SWITCHING)
/* Features valid for ethtool to change */
/* = all defined minus driver/device-class-related */
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 2cb7724..ca5a5e1 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -1508,7 +1508,7 @@ struct net_device {
netdev_features_t hw_features;
netdev_features_t wanted_features;
netdev_features_t vlan_features;
- netdev_features_t hw_enc_features;
+ netdev_features_t offload_features;
netdev_features_t mpls_features;
int ifindex;
> >
> >Signed-off-by: Scott Feldman <sfeldma@gmail.com>
> >Signed-off-by: Jiri Pirko <jiri@resnulli.us>
> >---
> >new in v3
> >---
> > include/uapi/linux/if_bridge.h | 1 +
> > 1 file changed, 1 insertion(+)
> >
> >diff --git a/include/uapi/linux/if_bridge.h b/include/uapi/linux/if_bridge.h
> >index da17e45..60425ca 100644
> >--- a/include/uapi/linux/if_bridge.h
> >+++ b/include/uapi/linux/if_bridge.h
> >@@ -105,6 +105,7 @@ struct __fdb_entry {
> > #define BRIDGE_MODE_VEB 0 /* Default loopback mode */
> > #define BRIDGE_MODE_VEPA 1 /* 802.1Qbg defined VEPA mode */
> >+#define BRIDGE_MODE_SWDEV 2 /* Full switch device offload */
> > /* Bridge management nested attributes
> > * [IFLA_AF_SPEC] = {
>
^ permalink raw reply related
* Re: [patch net-next v3 02/17] net: make vid as a parameter for ndo_fdb_add/ndo_fdb_del
From: Jamal Hadi Salim @ 2014-11-25 16:18 UTC (permalink / raw)
To: John Fastabend, Jiri Pirko, netdev
Cc: davem, nhorman, andy, tgraf, dborkman, ogerlitz, jesse, pshelar,
azhou, ben, stephen, jeffrey.t.kirsher, vyasevic, xiyou.wangcong,
edumazet, sfeldma, f.fainelli, roopa, linville, jasowang,
ebiederm, nicolas.dichtel, ryazanov.s.a, buytenh, aviadr, nbd,
alexei.starovoitov, Neil.Jerram, ronye, simon.horman,
alexander.h.duyck, john.ronciak, mleitner, shrijeet, gospo, bcrl
In-Reply-To: <5474A7EE.8000300@intel.com>
On 11/25/14 11:01, John Fastabend wrote:
> On 11/25/2014 07:38 AM, Jamal Hadi Salim wrote:
>> On 11/25/14 05:28, Jiri Pirko wrote:
>>> Do the work of parsing NDA_VLAN directly in rtnetlink code, pass simple
>>> u16 vid to drivers from there.
>>>
>>
>> Acked-by: Jamal Hadi Salim <jhs@mojatatu.com>
>>
>> I know this maintains status quo of what is already in the kernel.
>> But we need to take care of policy (pass it from user space) which
>> dictates how to proceed on failure. Three possible options:
>> 1) If something fails just continue with the rest of the transaction.
>> Return success if at least one thing succeeds.
>
> I'm not sure how (1) works. We can't just let user-space/management
> software run along thinking its configuration is set when its
> not. At least it doesn't look very appealing for the software I'm
> looking at.
>
Thats why it is a policy - just dont use it ;->
IOW, if the user made that choice the consequences are clear i.e there
is no confusion.
Example:
I could add 100 entries and if the 10th one failed for some reason to
apply to software version, I want to continue adding as many as i can
possibly add in the hardware etc.
>> 2) If something fails stop transaction and return some partial success code
>
> Option (2) is the current behavior of fdb this is straight forward
> and punts the complexity to user space. And at least the state is
> always known.
>
I dont think we return "partial" success code, do we?
I think we stop when software fails and dont care if hardware fails.
So this is status quo - we can do better..
>> 3) If something fails undo everything that has been done and return failure.
>>
>
> Sure this would be nice to have when doing bulk updates and is more
> useful on hardware that has a commit phase where updates don't actually
> occur until they are committed.
>
Indeed - i dont expect this option to be used as much but identifying
as a need now is important.
>> So two bits from somewhere would be useful to send from userspace->kernel
>>
>
> +1 for a follow up patch though.
>
As long as we are not adding any new behavior - agreed.
I dont see us doing that, so no controversy (hence my ACK).
cheers,
jamal
^ permalink raw reply
* Re: [patch net-next v3 02/17] net: make vid as a parameter for ndo_fdb_add/ndo_fdb_del
From: Roopa Prabhu @ 2014-11-25 16:19 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: Jiri Pirko, netdev, davem, nhorman, andy, tgraf, dborkman,
ogerlitz, jesse, pshelar, azhou, ben, stephen, jeffrey.t.kirsher,
vyasevic, xiyou.wangcong, john.r.fastabend, edumazet, sfeldma,
f.fainelli, linville, jasowang, ebiederm, nicolas.dichtel,
ryazanov.s.a, buytenh, aviadr, nbd, alexei.starovoitov,
Neil.Jerram, ronye, simon.horman, alexander.h.duyck, john.ronciak,
mleitner, shrijeet, gospo, bcrl
In-Reply-To: <5474A25C.3080505@mojatatu.com>
On 11/25/14, 7:38 AM, Jamal Hadi Salim wrote:
> On 11/25/14 05:28, Jiri Pirko wrote:
>> Do the work of parsing NDA_VLAN directly in rtnetlink code, pass simple
>> u16 vid to drivers from there.
>>
>
> Acked-by: Jamal Hadi Salim <jhs@mojatatu.com>
>
> I know this maintains status quo of what is already in the kernel.
> But we need to take care of policy (pass it from user space) which
> dictates how to proceed on failure. Three possible options:
> 1) If something fails just continue with the rest of the transaction.
> Return success if at least one thing succeeds.
> 2) If something fails stop transaction and return some partial success
> code
> 3) If something fails undo everything that has been done and return
> failure.
>
> So two bits from somewhere would be useful to send from userspace->kernel
>
>
ack to what jamal said. In the model where sw and hw must be in sync,
we need a mechanism to roll back in this approach.
I like that you are using existing ops.
To avoid the synchronization problem or to make the rollback easier, You
can still use existing ops and move this into the bridge driver.
ie call ndo_fdb_add/del and ndo_bridge_setlink/ndo_bridge_getlink on the
bridge port from within the bridge driver.
Again, vote for change ndo_bridge_setlink/ndo_bridge_getlink to be
renamed to ndo_setlink/getlink for other netdevs. I can submit a patch.
^ permalink raw reply
* [PATCH] tg3: fix ring init when there are more TX than RX channels
From: Thadeu Lima de Souza Cascardo @ 2014-11-25 16:21 UTC (permalink / raw)
To: netdev; +Cc: prashant, mchan, Thadeu Lima de Souza Cascardo
If TX channels are set to 4 and RX channels are set to less than 4,
using ethtool -L, the driver will try to initialize more RX channels
than it has allocated, causing an oops.
This fix only initializes the RX ring if it has been allocated.
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>
---
drivers/net/ethernet/broadcom/tg3.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/broadcom/tg3.c b/drivers/net/ethernet/broadcom/tg3.c
index dbb41c19..77f8f83 100644
--- a/drivers/net/ethernet/broadcom/tg3.c
+++ b/drivers/net/ethernet/broadcom/tg3.c
@@ -8563,7 +8563,8 @@ static int tg3_init_rings(struct tg3 *tp)
if (tnapi->rx_rcb)
memset(tnapi->rx_rcb, 0, TG3_RX_RCB_RING_BYTES(tp));
- if (tg3_rx_prodring_alloc(tp, &tnapi->prodring)) {
+ if (tnapi->prodring.rx_std &&
+ tg3_rx_prodring_alloc(tp, &tnapi->prodring)) {
tg3_free_rings(tp);
return -ENOMEM;
}
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH v5 2/4] arch: Add lightweight memory barriers dma_rmb() and dma_wmb()
From: Alexander Duyck @ 2014-11-25 16:26 UTC (permalink / raw)
To: Will Deacon
Cc: linux-arch@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, mathieu.desnoyers@polymtl.ca,
peterz@infradead.org, benh@kernel.crashing.org,
heiko.carstens@de.ibm.com, mingo@kernel.org, mikey@neuling.org,
linux@arm.linux.org.uk, donald.c.skidmore@intel.com,
matthew.vick@intel.com, geert@linux-m68k.org,
jeffrey.t.kirsher@intel.com, romieu@fr.zoreil.com,
paulmck@linux.vnet.ibm.com,
"nic_swsd@realtek.com" <nic_
In-Reply-To: <20141125140130.GC8541@arm.com>
On 11/25/2014 06:01 AM, Will Deacon wrote:
> On Wed, Nov 19, 2014 at 01:24:02AM +0000, Alexander Duyck wrote:
>> diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt
>> index 22a969c..a1c589b 100644
>> --- a/Documentation/memory-barriers.txt
>> +++ b/Documentation/memory-barriers.txt
>> @@ -1615,6 +1615,47 @@ There are some more advanced barrier functions:
>> operations" subsection for information on where to use these.
>>
>>
>> + (*) dma_wmb();
>> + (*) dma_rmb();
>> +
>> + These are for use with memory based device I/O to guarantee the ordering
>> + of cache coherent writes or reads with respect to other writes or reads
>> + to cache coherent DMA memory.
> Can you please make it crystal clear that "memory based device I/O" != MMIO?
> If people get these barriers wrong, then debugging will be a nightmare.
I think I'll update that to the following to avoid any confusion:
These are for use with consistent memory to guarantee the ordering
of writes or reads of shared memory accessible to both the CPU and a
DMA capable device.
I will also add a reference to DMA-API.txt at the end for more info on
what consistent memory is.
>> diff --git a/arch/arm/include/asm/barrier.h b/arch/arm/include/asm/barrier.h
>> index c6a3e73..d2f81e6 100644
>> --- a/arch/arm/include/asm/barrier.h
>> +++ b/arch/arm/include/asm/barrier.h
>> @@ -43,10 +43,14 @@
>> #define mb() do { dsb(); outer_sync(); } while (0)
>> #define rmb() dsb()
>> #define wmb() do { dsb(st); outer_sync(); } while (0)
>> +#define dma_rmb() dmb(osh)
>> +#define dma_wmb() dmb(oshst)
>> #else
>> #define mb() barrier()
>> #define rmb() barrier()
>> #define wmb() barrier()
>> +#define dma_rmb() barrier()
>> +#define dma_wmb() barrier()
>> #endif
>>
>> #ifndef CONFIG_SMP
>> diff --git a/arch/arm64/include/asm/barrier.h b/arch/arm64/include/asm/barrier.h
>> index 6389d60..a5abb00 100644
>> --- a/arch/arm64/include/asm/barrier.h
>> +++ b/arch/arm64/include/asm/barrier.h
>> @@ -32,6 +32,9 @@
>> #define rmb() dsb(ld)
>> #define wmb() dsb(st)
>>
>> +#define dma_rmb() dmb(oshld)
>> +#define dma_wmb() dmb(oshst)
>> +
>> #ifndef CONFIG_SMP
>> #define smp_mb() barrier()
>> #define smp_rmb() barrier()
> The arm/arm64 bits look fine to me.
>
> Acked-by: Will Deacon <will.deacon@arm.com>
Thanks for the review.
> If we ever see platforms using Linux/dma_alloc_coherent with devices
> mastering from a different outer-shareable domain that the one containing
> the CPUs, then we'll need to revisit this.
Would we just need a system wide memory barrier in that case instead of
an outer shareable memory barrier, or would we need to look as something
like a sync barrier?
- Alex
^ 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