* Re: [PATCH 1/1] linux-wireless: Added psk in struct cfg80211_connect_params needed for offloading 4way handshake to driver
From: Johannes Berg @ 2014-11-11 10:38 UTC (permalink / raw)
To: Arend van Spriel
Cc: Gautam (Gautam Kumar) Shukla, linville@tuxdriver.com,
linux-wireless@vger.kernel.org, davem@davemloft.net,
linux-api@vger.kernel.org, linux-kernel@vger.kernel.org,
netdev@vger.kernel.org, Jithu Jance, Sreenath S,
Vladimir Kondratiev
In-Reply-To: <5461E67E.7010408@broadcom.com>
On Tue, 2014-11-11 at 11:35 +0100, Arend van Spriel wrote:
> What did pop up is the wiphy flags vs. nl80211 feature flags. When that
> comes up it looks like 'potAtoes, potaetoes' to me.
>
> So is there are clear design rule for when to use which flag. For me the
> wiphy object represents the device/firmware and 4-way handshake offload
> support is determined by what the device/firmware supports.
There are three types of flags:
* wiphy flag attributes - deprecated as far as I'm concerned
* wiphy nl80211 feature flags - much easier to use in kernel (and
userspace)
* nl80211 protocol flags - only one exists
(NL80211_PROTOCOL_FEATURE_SPLIT_WIPHY_DUMP)
johannes
^ permalink raw reply
* Re: [PATCH 1/1] linux-wireless: Added psk in struct cfg80211_connect_params needed for offloading 4way handshake to driver
From: Arend van Spriel @ 2014-11-11 10:35 UTC (permalink / raw)
To: Johannes Berg
Cc: Gautam (Gautam Kumar) Shukla,
linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org,
linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org,
linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Jithu Jance,
Sreenath S, Vladimir Kondratiev
In-Reply-To: <1415700220.2163.3.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
On 11-11-14 11:03, Johannes Berg wrote:
> On Tue, 2014-11-11 at 10:54 +0100, Arend van Spriel wrote:
>
>>> Also, there's a competing approach from QCA that's far more suited.
>>
>> I probably was not paying attention to it, but would you have a
>> reference to this.
>
> ... digs around in email ...
>
> http://mid.gmane.org/1343907187-6686-1-git-send-email-qca_vkondrat-A+ZNKFmMK5xy9aJCnZT0Uw@public.gmane.org
>
> Anyway, looking back at that, it wasn't really all that different, just
> a bit more complete maybe.
Read through the whole thread. It seems some comments from you needed to
be addressed and Vladimir wanted to evaluate it. So that was the end of
the thread.
What did pop up is the wiphy flags vs. nl80211 feature flags. When that
comes up it looks like 'potAtoes, potaetoes' to me.
So is there are clear design rule for when to use which flag. For me the
wiphy object represents the device/firmware and 4-way handshake offload
support is determined by what the device/firmware supports.
Regards,
Arend
> johannes
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
^ permalink raw reply
* RE: [PATCH 1/1] linux-wireless: Added psk in struct cfg80211_connect_params needed for offloading 4way handshake to driver
From: Gautam (Gautam Kumar) Shukla @ 2014-11-11 10:33 UTC (permalink / raw)
To: Arend Van Spriel, Johannes Berg
Cc: linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org,
linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org,
linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Jithu Jance,
Sreenath S
In-Reply-To: <5461DCC9.5050702-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
Thanks a lot Johannes and Arend , for your comments and review .
It will really help me in my next patch submission .
Just wanted to know when QCA patch will get in main line as it was last updated on 23 aug 2012.
Thanks and regards
-----Original Message-----
From: Arend van Spriel [mailto:arend@broadcom.com]
Sent: Tuesday, November 11, 2014 3:24 PM
To: Johannes Berg; Gautam (Gautam Kumar) Shukla
Cc: linville@tuxdriver.com; linux-wireless@vger.kernel.org; davem@davemloft.net; linux-api@vger.kernel.org; linux-kernel@vger.kernel.org; netdev@vger.kernel.org; Jithu Jance; Sreenath S
Subject: Re: [PATCH 1/1] linux-wireless: Added psk in struct cfg80211_connect_params needed for offloading 4way handshake to driver
On 11-11-14 10:29, Johannes Berg wrote:
> On Tue, 2014-11-11 at 05:56 +0000, Gautam (Gautam Kumar) Shukla wrote:
>> For offloading 4 way handshake to driver, currently we don't have any
>> member of struct cfg80211_connect_params to pass PSK from supplicant
>> to driver. I have added psk for the same and added rest of the code
>> needed in nl80211.h and nl80211.c to parse and make it available to
>> driver.
>> From supplicant, we already have psk member field in assoc_params to
>> use .
>>
>> Tested on x86 linux.
>
> Your commit message needs serious work.
>
> Also, there's a competing approach from QCA that's far more suited.
I probably was not paying attention to it, but would you have a reference to this.
> In either case though, I'm going to ask which driver is going to use
> this and when it's going to land in mainline.
I had the same question ;-)
> johannes
>
> --
> To unsubscribe from this list: send the line "unsubscribe
> linux-wireless" 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] ipv6: fix IPV6_PKTINFO with v4 mapped
From: Hannes Frederic Sowa @ 2014-11-11 10:32 UTC (permalink / raw)
To: Eric Dumazet, David Miller; +Cc: netdev
In-Reply-To: <1415670865.9613.24.camel@edumazet-glaptop2.roam.corp.google.com>
On Tue, Nov 11, 2014, at 02:54, Eric Dumazet wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> Use IS_ENABLED(CONFIG_IPV6), to enable this code if IPv6 is
> a module.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Fixes: c8e6ad0829a7 ("ipv6: honor IPV6_PKTINFO with v4 mapped addresses
> on sendmsg")
Oops, thanks for fixing.
Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
^ permalink raw reply
* [patch iproute2] tc: add support for vlan tc action
From: Jiri Pirko @ 2014-11-11 10:16 UTC (permalink / raw)
To: netdev
Cc: davem, jhs, pshelar, therbert, edumazet, willemb, dborkman, mst,
fw, Paul.Durrant, tgraf
In-Reply-To: <reply-to=1415700789-9171-2-git-send-email-jiri@resnulli.us>
Signed-off-by: Jiri Pirko <jiri@resnulli.us>
---
include/linux/tc_act/tc_vlan.h | 35 +++++++
tc/Makefile | 1 +
tc/m_vlan.c | 205 +++++++++++++++++++++++++++++++++++++++++
3 files changed, 241 insertions(+)
create mode 100644 include/linux/tc_act/tc_vlan.h
create mode 100644 tc/m_vlan.c
diff --git a/include/linux/tc_act/tc_vlan.h b/include/linux/tc_act/tc_vlan.h
new file mode 100644
index 0000000..f7b8d44
--- /dev/null
+++ b/include/linux/tc_act/tc_vlan.h
@@ -0,0 +1,35 @@
+/*
+ * 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_TC_VLAN_H
+#define __LINUX_TC_VLAN_H
+
+#include <linux/pkt_cls.h>
+
+#define TCA_ACT_VLAN 12
+
+#define TCA_VLAN_ACT_POP 1
+#define TCA_VLAN_ACT_PUSH 2
+
+struct tc_vlan {
+ tc_gen;
+ int v_action;
+};
+
+enum {
+ TCA_VLAN_UNSPEC,
+ TCA_VLAN_TM,
+ TCA_VLAN_PARMS,
+ TCA_VLAN_PUSH_VLAN_ID,
+ TCA_VLAN_PUSH_VLAN_PROTOCOL,
+ __TCA_VLAN_MAX,
+};
+#define TCA_VLAN_MAX (__TCA_VLAN_MAX - 1)
+
+#endif
diff --git a/tc/Makefile b/tc/Makefile
index 1ab36c6..830c97d 100644
--- a/tc/Makefile
+++ b/tc/Makefile
@@ -40,6 +40,7 @@ TCMODULES += m_pedit.o
TCMODULES += m_skbedit.o
TCMODULES += m_csum.o
TCMODULES += m_simple.o
+TCMODULES += m_vlan.o
TCMODULES += p_ip.o
TCMODULES += p_icmp.o
TCMODULES += p_tcp.o
diff --git a/tc/m_vlan.c b/tc/m_vlan.c
new file mode 100644
index 0000000..54c0ce7
--- /dev/null
+++ b/tc/m_vlan.c
@@ -0,0 +1,205 @@
+/*
+ * m_vlan.c vlan manipulation module
+ *
+ * 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.
+ *
+ * Authors: Jiri Pirko <jiri@resnulli.us>
+ */
+
+#include <stdio.h>
+#include <stdlib.h>
+#include <unistd.h>
+#include <string.h>
+#include "utils.h"
+#include "rt_names.h"
+#include "tc_util.h"
+#include <linux/tc_act/tc_vlan.h>
+
+static void explain(void)
+{
+ fprintf(stderr, "Usage: vlan pop\n");
+ fprintf(stderr, " vlan push [ protocol VLANPROTO ] id VLANID\n");
+}
+
+static void usage(void)
+{
+ explain();
+ exit(-1);
+}
+
+static int parse_vlan(struct action_util *a, int *argc_p, char ***argv_p,
+ int tca_id, struct nlmsghdr *n)
+{
+ int argc = *argc_p;
+ char **argv = *argv_p;
+ struct rtattr *tail;
+ int action = 0;
+ __u16 id;
+ int id_set = 0;
+ __u16 proto;
+ int proto_set = 0;
+ struct tc_vlan parm = { 0 };
+
+ if (matches(*argv, "vlan") != 0)
+ return -1;
+
+ NEXT_ARG();
+
+ while (argc > 0) {
+ if (matches(*argv, "pop") == 0) {
+ if (action) {
+ fprintf(stderr, "unexpexted \"%s\" - action already specified\n",
+ *argv);
+ explain();
+ return -1;
+ }
+ action = TCA_VLAN_ACT_POP;
+ } else if (matches(*argv, "push") == 0) {
+ if (action) {
+ fprintf(stderr, "unexpexted \"%s\" - action already specified\n",
+ *argv);
+ explain();
+ return -1;
+ }
+ action = TCA_VLAN_ACT_PUSH;
+ } else if (matches(*argv, "id") == 0) {
+ if (action != TCA_VLAN_ACT_PUSH) {
+ fprintf(stderr, "\"%s\" is only valid for push\n",
+ *argv);
+ explain();
+ return -1;
+ }
+ NEXT_ARG();
+ if (get_u16(&id, *argv, 0))
+ invarg("id is invalid", *argv);
+ id_set = 1;
+ } else if (matches(*argv, "protocol") == 0) {
+ if (action != TCA_VLAN_ACT_PUSH) {
+ fprintf(stderr, "\"%s\" is only valid for push\n",
+ *argv);
+ explain();
+ return -1;
+ }
+ NEXT_ARG();
+ if (ll_proto_a2n(&proto, *argv))
+ invarg("protocol is invalid", *argv);
+ proto_set = 1;
+ } else if (matches(*argv, "help") == 0) {
+ usage();
+ } else {
+ break;
+ }
+ argc--;
+ argv++;
+ }
+
+ parm.action = TC_ACT_PIPE;
+ if (argc) {
+ if (matches(*argv, "reclassify") == 0) {
+ parm.action = TC_ACT_RECLASSIFY;
+ NEXT_ARG();
+ } else if (matches(*argv, "pipe") == 0) {
+ parm.action = TC_ACT_PIPE;
+ NEXT_ARG();
+ } else if (matches(*argv, "drop") == 0 ||
+ matches(*argv, "shot") == 0) {
+ parm.action = TC_ACT_SHOT;
+ NEXT_ARG();
+ } else if (matches(*argv, "continue") == 0) {
+ parm.action = TC_ACT_UNSPEC;
+ NEXT_ARG();
+ } else if (matches(*argv, "pass") == 0) {
+ parm.action = TC_ACT_OK;
+ NEXT_ARG();
+ }
+ }
+
+ if (argc) {
+ if (matches(*argv, "index") == 0) {
+ NEXT_ARG();
+ if (get_u32(&parm.index, *argv, 10)) {
+ fprintf(stderr, "Pedit: Illegal \"index\"\n");
+ return -1;
+ }
+ argc--;
+ argv++;
+ }
+ }
+
+ if (action == TCA_VLAN_ACT_PUSH && !id_set) {
+ fprintf(stderr, "id needs to be set for push\n");
+ explain();
+ return -1;
+ }
+
+ parm.v_action = action;
+ tail = NLMSG_TAIL(n);
+ addattr_l(n, MAX_MSG, tca_id, NULL, 0);
+ addattr_l(n, MAX_MSG, TCA_VLAN_PARMS, &parm, sizeof(parm));
+ if (id_set)
+ addattr_l(n, MAX_MSG, TCA_VLAN_PUSH_VLAN_ID, &id, 2);
+ if (proto_set)
+ addattr_l(n, MAX_MSG, TCA_VLAN_PUSH_VLAN_PROTOCOL, &proto, 2);
+ tail->rta_len = (char *)NLMSG_TAIL(n) - (char *)tail;
+
+ *argc_p = argc;
+ *argv_p = argv;
+ return 0;
+}
+
+static int print_vlan(struct action_util *au, FILE *f, struct rtattr *arg)
+{
+ struct rtattr *tb[TCA_VLAN_MAX + 1];
+ __u16 val;
+ struct tc_vlan *parm;
+
+ if (arg == NULL)
+ return -1;
+
+ parse_rtattr_nested(tb, TCA_VLAN_MAX, arg);
+
+ if (!tb[TCA_VLAN_PARMS]) {
+ fprintf(f, "[NULL vlan parameters]");
+ return -1;
+ }
+ parm = RTA_DATA(tb[TCA_VLAN_PARMS]);
+
+ fprintf(f, " vlan");
+
+ switch(parm->v_action) {
+ case TCA_VLAN_ACT_POP:
+ fprintf(f, " pop");
+ break;
+ case TCA_VLAN_ACT_PUSH:
+ fprintf(f, " push");
+ if (tb[TCA_VLAN_PUSH_VLAN_ID]) {
+ val = rta_getattr_u16(tb[TCA_VLAN_PUSH_VLAN_ID]);
+ fprintf(f, " id %d", val);
+ }
+ if (tb[TCA_VLAN_PUSH_VLAN_PROTOCOL]) {
+ val = rta_getattr_u16(tb[TCA_VLAN_PUSH_VLAN_PROTOCOL]);
+ fprintf(f, " proto %04x", val);
+ }
+ break;
+ }
+
+ if (show_stats) {
+ if (tb[TCA_VLAN_TM]) {
+ struct tcf_t *tm = RTA_DATA(tb[TCA_VLAN_TM]);
+ print_tm(f, tm);
+ }
+ }
+
+ fprintf(f, "\n ");
+
+ return 0;
+}
+
+struct action_util vlan_action_util = {
+ .id = "vlan",
+ .parse_aopt = parse_vlan,
+ .print_aopt = print_vlan,
+};
--
1.9.3
^ permalink raw reply related
* [patch net-next 2/2] sched: introduce vlan action
From: Jiri Pirko @ 2014-11-11 10:13 UTC (permalink / raw)
To: netdev
Cc: davem, jhs, pshelar, therbert, edumazet, willemb, dborkman, mst,
fw, Paul.Durrant, tgraf
In-Reply-To: <1415700789-9171-1-git-send-email-jiri@resnulli.us>
This tc action allows to work with vlan tagged skbs. Two supported
sub-actions are header pop and header push.
Signed-off-by: Jiri Pirko <jiri@resnulli.us>
---
include/net/tc_act/tc_vlan.h | 27 +++++
include/uapi/linux/tc_act/tc_vlan.h | 35 ++++++
net/sched/Kconfig | 11 ++
net/sched/Makefile | 1 +
net/sched/act_vlan.c | 207 ++++++++++++++++++++++++++++++++++++
5 files changed, 281 insertions(+)
create mode 100644 include/net/tc_act/tc_vlan.h
create mode 100644 include/uapi/linux/tc_act/tc_vlan.h
create mode 100644 net/sched/act_vlan.c
diff --git a/include/net/tc_act/tc_vlan.h b/include/net/tc_act/tc_vlan.h
new file mode 100644
index 0000000..c809c1d
--- /dev/null
+++ b/include/net/tc_act/tc_vlan.h
@@ -0,0 +1,27 @@
+/*
+ * 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 __NET_TC_VLAN_H
+#define __NET_TC_VLAN_H
+
+#include <net/act_api.h>
+
+#define VLAN_F_POP 0x1
+#define VLAN_F_PUSH 0x2
+
+struct tcf_vlan {
+ struct tcf_common common;
+ int tcfv_action;
+ __be16 tcfv_push_vid;
+ __be16 tcfv_push_proto;
+};
+#define to_vlan(a) \
+ container_of(a->priv, struct tcf_vlan, common)
+
+#endif /* __NET_TC_VLAN_H */
diff --git a/include/uapi/linux/tc_act/tc_vlan.h b/include/uapi/linux/tc_act/tc_vlan.h
new file mode 100644
index 0000000..f7b8d44
--- /dev/null
+++ b/include/uapi/linux/tc_act/tc_vlan.h
@@ -0,0 +1,35 @@
+/*
+ * 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_TC_VLAN_H
+#define __LINUX_TC_VLAN_H
+
+#include <linux/pkt_cls.h>
+
+#define TCA_ACT_VLAN 12
+
+#define TCA_VLAN_ACT_POP 1
+#define TCA_VLAN_ACT_PUSH 2
+
+struct tc_vlan {
+ tc_gen;
+ int v_action;
+};
+
+enum {
+ TCA_VLAN_UNSPEC,
+ TCA_VLAN_TM,
+ TCA_VLAN_PARMS,
+ TCA_VLAN_PUSH_VLAN_ID,
+ TCA_VLAN_PUSH_VLAN_PROTOCOL,
+ __TCA_VLAN_MAX,
+};
+#define TCA_VLAN_MAX (__TCA_VLAN_MAX - 1)
+
+#endif
diff --git a/net/sched/Kconfig b/net/sched/Kconfig
index a1a8e29..88618f8 100644
--- a/net/sched/Kconfig
+++ b/net/sched/Kconfig
@@ -686,6 +686,17 @@ config NET_ACT_CSUM
To compile this code as a module, choose M here: the
module will be called act_csum.
+config NET_ACT_VLAN
+ tristate "Vlan manipulation"
+ depends on NET_CLS_ACT
+ ---help---
+ Say Y here to push or pop vlan headers.
+
+ If unsure, say N.
+
+ To compile this code as a module, choose M here: the
+ module will be called act_vlan.
+
config NET_CLS_IND
bool "Incoming device classification"
depends on NET_CLS_U32 || NET_CLS_FW
diff --git a/net/sched/Makefile b/net/sched/Makefile
index 0a869a1..679f24a 100644
--- a/net/sched/Makefile
+++ b/net/sched/Makefile
@@ -16,6 +16,7 @@ obj-$(CONFIG_NET_ACT_PEDIT) += act_pedit.o
obj-$(CONFIG_NET_ACT_SIMP) += act_simple.o
obj-$(CONFIG_NET_ACT_SKBEDIT) += act_skbedit.o
obj-$(CONFIG_NET_ACT_CSUM) += act_csum.o
+obj-$(CONFIG_NET_ACT_VLAN) += act_vlan.o
obj-$(CONFIG_NET_SCH_FIFO) += sch_fifo.o
obj-$(CONFIG_NET_SCH_CBQ) += sch_cbq.o
obj-$(CONFIG_NET_SCH_HTB) += sch_htb.o
diff --git a/net/sched/act_vlan.c b/net/sched/act_vlan.c
new file mode 100644
index 0000000..013b17d
--- /dev/null
+++ b/net/sched/act_vlan.c
@@ -0,0 +1,207 @@
+/*
+ * 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/module.h>
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/skbuff.h>
+#include <linux/rtnetlink.h>
+#include <linux/if_vlan.h>
+#include <net/netlink.h>
+#include <net/pkt_sched.h>
+
+#include <linux/tc_act/tc_vlan.h>
+#include <net/tc_act/tc_vlan.h>
+
+#define VLAN_TAB_MASK 15
+
+static int tcf_vlan(struct sk_buff *skb, const struct tc_action *a,
+ struct tcf_result *res)
+{
+ struct tcf_vlan *v = a->priv;
+ int action;
+ int err;
+
+ spin_lock(&v->tcf_lock);
+ v->tcf_tm.lastuse = jiffies;
+ bstats_update(&v->tcf_bstats, skb);
+ action = v->tcf_action;
+
+ switch (v->tcfv_action) {
+ case TCA_VLAN_ACT_POP:
+ err = skb_vlan_pop(skb);
+ if (err)
+ goto drop;
+ break;
+ case TCA_VLAN_ACT_PUSH:
+ err = skb_vlan_push(skb, v->tcfv_push_proto, v->tcfv_push_vid);
+ if (err)
+ goto drop;
+ break;
+ default:
+ BUG();
+ }
+
+ goto unlock;
+
+drop:
+ action = TC_ACT_SHOT;
+ v->tcf_qstats.drops++;
+unlock:
+ spin_unlock(&v->tcf_lock);
+ return action;
+}
+
+static const struct nla_policy vlan_policy[TCA_VLAN_MAX + 1] = {
+ [TCA_VLAN_PARMS] = { .len = sizeof(struct tc_vlan) },
+ [TCA_VLAN_PUSH_VLAN_ID] = { .type = NLA_U16 },
+ [TCA_VLAN_PUSH_VLAN_PROTOCOL] = { .type = NLA_U16 },
+};
+
+static int tcf_vlan_init(struct net *net, struct nlattr *nla,
+ struct nlattr *est, struct tc_action *a,
+ int ovr, int bind)
+{
+ struct nlattr *tb[TCA_VLAN_MAX + 1];
+ struct tc_vlan *parm;
+ struct tcf_vlan *v;
+ int action;
+ __be16 push_vid = 0;
+ __be16 push_proto = 0;
+ int ret = 0;
+ int err;
+
+ if (!nla)
+ return -EINVAL;
+
+ err = nla_parse_nested(tb, TCA_VLAN_MAX, nla, vlan_policy);
+ if (err < 0)
+ return err;
+
+ if (!tb[TCA_VLAN_PARMS])
+ return -EINVAL;
+ parm = nla_data(tb[TCA_VLAN_PARMS]);
+ switch (parm->v_action) {
+ case TCA_VLAN_ACT_POP:
+ break;
+ case TCA_VLAN_ACT_PUSH:
+ if (!tb[TCA_VLAN_PUSH_VLAN_ID])
+ return -EINVAL;
+ push_vid = nla_get_u16(tb[TCA_VLAN_PUSH_VLAN_ID]);
+ if (push_vid >= VLAN_VID_MASK)
+ return -ERANGE;
+
+ if (tb[TCA_VLAN_PUSH_VLAN_PROTOCOL]) {
+ push_proto = nla_get_be16(tb[TCA_VLAN_PUSH_VLAN_PROTOCOL]);
+ switch (push_proto) {
+ case htons(ETH_P_8021Q):
+ case htons(ETH_P_8021AD):
+ break;
+ default:
+ return -EPROTONOSUPPORT;
+ }
+ } else {
+ push_proto = htons(ETH_P_8021Q);
+ }
+ break;
+ default:
+ return -EINVAL;
+ }
+ action = parm->v_action;
+
+ if (!tcf_hash_check(parm->index, a, bind)) {
+ ret = tcf_hash_create(parm->index, est, a, sizeof(*v), bind);
+ if (ret)
+ return ret;
+
+ ret = ACT_P_CREATED;
+ } else {
+ if (bind)
+ return 0;
+ tcf_hash_release(a, bind);
+ if (!ovr)
+ return -EEXIST;
+ }
+
+ v = to_vlan(a);
+
+ spin_lock_bh(&v->tcf_lock);
+
+ v->tcfv_action = action;
+ v->tcfv_push_vid = push_vid;
+ v->tcfv_push_proto = push_proto;
+
+ v->tcf_action = parm->action;
+
+ spin_unlock_bh(&v->tcf_lock);
+
+ if (ret == ACT_P_CREATED)
+ tcf_hash_insert(a);
+ return ret;
+}
+
+static int tcf_vlan_dump(struct sk_buff *skb, struct tc_action *a,
+ int bind, int ref)
+{
+ unsigned char *b = skb_tail_pointer(skb);
+ struct tcf_vlan *v = a->priv;
+ struct tc_vlan opt = {
+ .index = v->tcf_index,
+ .refcnt = v->tcf_refcnt - ref,
+ .bindcnt = v->tcf_bindcnt - bind,
+ .action = v->tcf_action,
+ .v_action = v->tcfv_action,
+ };
+ struct tcf_t t;
+
+ if (nla_put(skb, TCA_VLAN_PARMS, sizeof(opt), &opt))
+ goto nla_put_failure;
+
+ if (v->tcfv_action == TCA_VLAN_ACT_PUSH &&
+ nla_put_u16(skb, TCA_VLAN_PUSH_VLAN_ID, v->tcfv_push_vid) &&
+ nla_put_u16(skb, TCA_VLAN_PUSH_VLAN_PROTOCOL, v->tcfv_push_proto))
+ goto nla_put_failure;
+
+ t.install = jiffies_to_clock_t(jiffies - v->tcf_tm.install);
+ t.lastuse = jiffies_to_clock_t(jiffies - v->tcf_tm.lastuse);
+ t.expires = jiffies_to_clock_t(v->tcf_tm.expires);
+ if (nla_put(skb, TCA_VLAN_TM, sizeof(t), &t))
+ goto nla_put_failure;
+ return skb->len;
+
+nla_put_failure:
+ nlmsg_trim(skb, b);
+ return -1;
+}
+
+static struct tc_action_ops act_vlan_ops = {
+ .kind = "vlan",
+ .type = TCA_ACT_VLAN,
+ .owner = THIS_MODULE,
+ .act = tcf_vlan,
+ .dump = tcf_vlan_dump,
+ .init = tcf_vlan_init,
+};
+
+static int __init vlan_init_module(void)
+{
+ return tcf_register_action(&act_vlan_ops, VLAN_TAB_MASK);
+}
+
+static void __exit vlan_cleanup_module(void)
+{
+ tcf_unregister_action(&act_vlan_ops);
+}
+
+module_init(vlan_init_module);
+module_exit(vlan_cleanup_module);
+
+MODULE_AUTHOR("Jiri Pirko <jiri@resnulli.us>");
+MODULE_DESCRIPTION("vlan manipulation actions");
+MODULE_LICENSE("GPL v2");
--
1.9.3
^ permalink raw reply related
* [patch net-next 1/2] net: move vlan pop/push functions into common code
From: Jiri Pirko @ 2014-11-11 10:13 UTC (permalink / raw)
To: netdev
Cc: davem, jhs, pshelar, therbert, edumazet, willemb, dborkman, mst,
fw, Paul.Durrant, tgraf
So it can be used from out of openvswitch code.
Did couple of cosmetic changes on the way, namely variable naming and
adding support for 8021AD proto.
Signed-off-by: Jiri Pirko <jiri@resnulli.us>
---
include/linux/skbuff.h | 2 ++
net/core/skbuff.c | 86 +++++++++++++++++++++++++++++++++++++++++++++++
net/openvswitch/actions.c | 76 ++---------------------------------------
3 files changed, 90 insertions(+), 74 deletions(-)
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 103fbe8..3b0445c 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -2673,6 +2673,8 @@ void skb_scrub_packet(struct sk_buff *skb, bool xnet);
unsigned int skb_gso_transport_seglen(const struct sk_buff *skb);
struct sk_buff *skb_segment(struct sk_buff *skb, netdev_features_t features);
struct sk_buff *skb_vlan_untag(struct sk_buff *skb);
+int skb_vlan_pop(struct sk_buff *skb);
+int skb_vlan_push(struct sk_buff *skb, __be16 vlan_proto, u16 vlan_tci);
struct skb_checksum_ops {
__wsum (*update)(const void *mem, int len, __wsum wsum);
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 7001896..75e53d4 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -4151,6 +4151,92 @@ err_free:
}
EXPORT_SYMBOL(skb_vlan_untag);
+/* remove VLAN header from packet and update csum accordingly. */
+static int __skb_vlan_pop(struct sk_buff *skb, u16 *vlan_tci)
+{
+ struct vlan_hdr *vhdr;
+ int err;
+
+ if (!pskb_may_pull(skb, VLAN_ETH_HLEN))
+ return -ENOMEM;
+
+ if (!skb_cloned(skb) || skb_clone_writable(skb, VLAN_ETH_HLEN))
+ return 0;
+
+ err = pskb_expand_head(skb, 0, 0, GFP_ATOMIC);
+ if (unlikely(err))
+ return err;
+
+ if (skb->ip_summed == CHECKSUM_COMPLETE)
+ skb->csum = csum_sub(skb->csum, csum_partial(skb->data
+ + (2 * ETH_ALEN), VLAN_HLEN, 0));
+
+ vhdr = (struct vlan_hdr *)(skb->data + ETH_HLEN);
+ *vlan_tci = ntohs(vhdr->h_vlan_TCI);
+
+ memmove(skb->data + VLAN_HLEN, skb->data, 2 * ETH_ALEN);
+ __skb_pull(skb, VLAN_HLEN);
+
+ vlan_set_encap_proto(skb, vhdr);
+ skb->mac_header += VLAN_HLEN;
+ if (skb_network_offset(skb) < ETH_HLEN)
+ skb_set_network_header(skb, ETH_HLEN);
+ skb_reset_mac_len(skb);
+
+ return 0;
+}
+
+int skb_vlan_pop(struct sk_buff *skb)
+{
+ u16 vlan_tci;
+ __be16 vlan_proto;
+ int err;
+
+ if (likely(vlan_tx_tag_present(skb))) {
+ skb->vlan_tci = 0;
+ } else {
+ if (unlikely((skb->protocol != htons(ETH_P_8021Q) &&
+ skb->protocol != htons(ETH_P_8021AD)) ||
+ skb->len < VLAN_ETH_HLEN))
+ return 0;
+
+ err = __skb_vlan_pop(skb, &vlan_tci);
+ if (err)
+ return err;
+ }
+ /* move next vlan tag to hw accel tag */
+ if (likely((skb->protocol != htons(ETH_P_8021Q) &&
+ skb->protocol != htons(ETH_P_8021AD)) ||
+ skb->len < VLAN_ETH_HLEN))
+ return 0;
+
+ vlan_proto = skb->protocol;
+ err = __skb_vlan_pop(skb, &vlan_tci);
+ if (unlikely(err))
+ return err;
+
+ __vlan_hwaccel_put_tag(skb, vlan_proto, vlan_tci);
+ return 0;
+}
+EXPORT_SYMBOL(skb_vlan_pop);
+
+int skb_vlan_push(struct sk_buff *skb, __be16 vlan_proto, u16 vlan_tci)
+{
+ if (vlan_tx_tag_present(skb)) {
+ /* push down current VLAN tag */
+ if (!__vlan_put_tag(skb, skb->vlan_proto,
+ vlan_tx_tag_get(skb)))
+ return -ENOMEM;
+
+ if (skb->ip_summed == CHECKSUM_COMPLETE)
+ skb->csum = csum_add(skb->csum, csum_partial(skb->data
+ + (2 * ETH_ALEN), VLAN_HLEN, 0));
+ }
+ __vlan_hwaccel_put_tag(skb, vlan_proto, vlan_tci);
+ return 0;
+}
+EXPORT_SYMBOL(skb_vlan_push);
+
/**
* alloc_skb_with_frags - allocate skb with page frags
*
diff --git a/net/openvswitch/actions.c b/net/openvswitch/actions.c
index f7e5891..1b28110 100644
--- a/net/openvswitch/actions.c
+++ b/net/openvswitch/actions.c
@@ -206,86 +206,14 @@ static int set_mpls(struct sk_buff *skb, const __be32 *mpls_lse)
return 0;
}
-/* remove VLAN header from packet and update csum accordingly. */
-static int __pop_vlan_tci(struct sk_buff *skb, __be16 *current_tci)
-{
- struct vlan_hdr *vhdr;
- int err;
-
- err = make_writable(skb, VLAN_ETH_HLEN);
- if (unlikely(err))
- return err;
-
- if (skb->ip_summed == CHECKSUM_COMPLETE)
- skb->csum = csum_sub(skb->csum, csum_partial(skb->data
- + (2 * ETH_ALEN), VLAN_HLEN, 0));
-
- vhdr = (struct vlan_hdr *)(skb->data + ETH_HLEN);
- *current_tci = vhdr->h_vlan_TCI;
-
- memmove(skb->data + VLAN_HLEN, skb->data, 2 * ETH_ALEN);
- __skb_pull(skb, VLAN_HLEN);
-
- vlan_set_encap_proto(skb, vhdr);
- skb->mac_header += VLAN_HLEN;
-
- if (skb_network_offset(skb) < ETH_HLEN)
- skb_set_network_header(skb, ETH_HLEN);
-
- /* Update mac_len for subsequent MPLS actions */
- skb_reset_mac_len(skb);
- return 0;
-}
-
static int pop_vlan(struct sk_buff *skb)
{
- __be16 tci;
- int err;
-
- if (likely(vlan_tx_tag_present(skb))) {
- skb->vlan_tci = 0;
- } else {
- if (unlikely(skb->protocol != htons(ETH_P_8021Q) ||
- skb->len < VLAN_ETH_HLEN))
- return 0;
-
- err = __pop_vlan_tci(skb, &tci);
- if (err)
- return err;
- }
- /* move next vlan tag to hw accel tag */
- if (likely(skb->protocol != htons(ETH_P_8021Q) ||
- skb->len < VLAN_ETH_HLEN))
- return 0;
-
- err = __pop_vlan_tci(skb, &tci);
- if (unlikely(err))
- return err;
-
- __vlan_hwaccel_put_tag(skb, htons(ETH_P_8021Q), ntohs(tci));
- return 0;
+ return skb_vlan_pop(skb);
}
static int push_vlan(struct sk_buff *skb, const struct ovs_action_push_vlan *vlan)
{
- if (unlikely(vlan_tx_tag_present(skb))) {
- u16 current_tag;
-
- /* push down current VLAN tag */
- current_tag = vlan_tx_tag_get(skb);
-
- if (!__vlan_put_tag(skb, skb->vlan_proto, current_tag))
- return -ENOMEM;
- /* Update mac_len for subsequent MPLS actions */
- skb->mac_len += VLAN_HLEN;
-
- if (skb->ip_summed == CHECKSUM_COMPLETE)
- skb->csum = csum_add(skb->csum, csum_partial(skb->data
- + (2 * ETH_ALEN), VLAN_HLEN, 0));
-
- }
- __vlan_hwaccel_put_tag(skb, vlan->vlan_tpid, ntohs(vlan->vlan_tci) & ~VLAN_TAG_PRESENT);
- return 0;
+ return skb_vlan_push(skb, vlan->vlan_tpid, ntohs(vlan->vlan_tci) & ~VLAN_TAG_PRESENT);
}
static int set_eth_addr(struct sk_buff *skb,
--
1.9.3
^ permalink raw reply related
* Re: How to make stack send broadcast ARP request when entry is STALE?
From: Ulf samuelsson @ 2014-11-11 10:08 UTC (permalink / raw)
To: Brian Haley; +Cc: Netdev
In-Reply-To: <54614198.7010306@hp.com>
If I set ucast_solicit to '0', then I always send broadcast, which is not desirable.
In the PROBE state of the ARP state machine, "probes" count from 0 .. ucast_probes.
I can see the following arguments for letting "probes" count from
0.. (ucast_probes + app_probes + mcast_probes)
A: This is how the IPv6 is doing it.
It is not standardized in IPv4, but why should the IPv4 have a different behaviour?
B: If you do not send out broadcast if unicast fails, then a broadcast will be sent out
anyway, once the ARP entry is removed by the garbage collector.
You get an annoyingly long delay before that happens.
C: If a large data centre does not want broadcasts to be sent out,
then they can set mcast_probes to 0, in which case no broadcasts will be sent
out in PROBE state.
D: When in other states, the counter runs until it a reply is had, or the counter wraps around.
It is sending broadcast all the time.
Best Regards
Ulf Samuelsson
ulf@emagii.com
+46 (722) 427 437
> 10 nov 2014 kl. 23:52 skrev Brian Haley <brian.haley@hp.com>:
>
>> On 11/07/2014 05:11 AM, Ulf samuelsson wrote:
>> The HP router is configured by a customer, and they intentionally limit replies
>> to broadcast, and that is how they want it.
>
> So this is the crux of the problem - the customer has configured the router so
> that it doesn't play well with most modern network stacks that try and use
> unicast so they don't send unnecessary broadcast packets. I don't know why I
> thought this was something wrong with the router software.
>
> Did you try this?
>
> $ sudo sysctl net.ipv4.neigh.eth0.ucast_solicit=0
>
> It works for me.
>
> And they really should re-think their decision on that configuration setting.
>
> -Brian
>
>
>> In the previous version of the build system, the Interpeak stack was used
>> and this would in PROBE state send unicast ARP request, and if that failed
>> send broadcast ARP.
>>
>> The native linux stack, when in PROBE state sends only unicast until it decides
>> that it should enter FAILED state.
>>
>> The 'mcast_probes' variable seems to be totally ignored, except the first time,
>> so I do not see why it is there.
>>
>> Best Regards
>> Ulf Samuelsson
>> ulf@emagii.com
>> +46 (722) 427 437
>>
>>
>>>> 7 nov 2014 kl. 10:54 skrev Brian Haley <brian.haley@hp.com>:
>>>>
>>>> On 11/05/2014 07:48 AM, Ulf samuelsson wrote:
>>>> Have a problem with an HP router at a certain location, which
>>>> is configured to only answer to broadcast ARP requests.
>>>> That cannot be changed.
>>>
>>> Sorry to hear about the problem, but my only suggestions would be to try the latest firmware and/or put a call in to support. I don't happen work in the division that makes routers...
>>>
>>>> The first ARP request the kernel sends out, is a broadcast request,
>>>> which is fine, but after the reply, the kernel sends unicast requests,
>>>> which will not get any replies.
>>>
>>> You might be able to hack this by inserting an ebtables rule - check the dnat target section of the man page - don't know the exact syntax but it would probably end in '-j dnat --to-destination ff:ff:ff:ff:ff:ff'
>>>
>>> -Brian
>>> --
>>> 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
>> --
>> 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-next v2 02/10] net: introduce generic switch devices support
From: Jiri Pirko @ 2014-11-11 10:04 UTC (permalink / raw)
To: M. Braun
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, gospo, bcrl
In-Reply-To: <5461DBB0.5090107@fami-braun.de>
Tue, Nov 11, 2014 at 10:49:36AM CET, michael-dev@fami-braun.de wrote:
>
>
>Am 09.11.2014 um 11:51 schrieb Jiri Pirko:
>> diff --git a/Documentation/networking/switchdev.txt b/Documentation/networking/switchdev.txt
>> + ndo_sw_parent_get_id - ...
>
>here the ndo is called get_id
>
>but
>
>> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
>> + *
>> + * int (*ndo_sw_parent_id_get)(struct net_device *dev,
>> + * struct netdev_phys_item_id *psid);
>> @@ -1168,6 +1174,10 @@ struct net_device_ops {
>> + int (*ndo_sw_parent_id_get)(struct net_device *dev,
>> + struct netdev_phys_item_id *psid);
>
>here it is call id_get, which is similar but not the same.
Will fix the docs, thanks.
>
>Regards,
> M. Braun
^ permalink raw reply
* Re: [PATCH 1/1] linux-wireless: Added psk in struct cfg80211_connect_params needed for offloading 4way handshake to driver
From: Johannes Berg @ 2014-11-11 10:03 UTC (permalink / raw)
To: Arend van Spriel
Cc: Gautam (Gautam Kumar) Shukla, linville@tuxdriver.com,
linux-wireless@vger.kernel.org, davem@davemloft.net,
linux-api@vger.kernel.org, linux-kernel@vger.kernel.org,
netdev@vger.kernel.org, Jithu Jance, Sreenath S
In-Reply-To: <5461DCC9.5050702@broadcom.com>
On Tue, 2014-11-11 at 10:54 +0100, Arend van Spriel wrote:
> > Also, there's a competing approach from QCA that's far more suited.
>
> I probably was not paying attention to it, but would you have a
> reference to this.
... digs around in email ...
http://mid.gmane.org/1343907187-6686-1-git-send-email-qca_vkondrat@qca.qualcomm.com
Anyway, looking back at that, it wasn't really all that different, just
a bit more complete maybe.
johannes
^ permalink raw reply
* Re: [patch net-next v2 02/10] net: introduce generic switch devices support
From: M. Braun @ 2014-11-11 9:49 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, 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,
gospo, bcrl
In-Reply-To: <1415530280-9190-3-git-send-email-jiri@resnulli.us>
Am 09.11.2014 um 11:51 schrieb Jiri Pirko:
> diff --git a/Documentation/networking/switchdev.txt b/Documentation/networking/switchdev.txt
> + ndo_sw_parent_get_id - ...
here the ndo is called get_id
but
> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> + *
> + * int (*ndo_sw_parent_id_get)(struct net_device *dev,
> + * struct netdev_phys_item_id *psid);
> @@ -1168,6 +1174,10 @@ struct net_device_ops {
> + int (*ndo_sw_parent_id_get)(struct net_device *dev,
> + struct netdev_phys_item_id *psid);
here it is call id_get, which is similar but not the same.
Regards,
M. Braun
^ permalink raw reply
* Re: [PATCH 1/1] linux-wireless: Added psk in struct cfg80211_connect_params needed for offloading 4way handshake to driver
From: Arend van Spriel @ 2014-11-11 9:54 UTC (permalink / raw)
To: Johannes Berg, Gautam (Gautam Kumar) Shukla
Cc: linville@tuxdriver.com, linux-wireless@vger.kernel.org,
davem@davemloft.net, linux-api@vger.kernel.org,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org, Jithu Jance,
Sreenath S
In-Reply-To: <1415698161.2163.0.camel@sipsolutions.net>
On 11-11-14 10:29, Johannes Berg wrote:
> On Tue, 2014-11-11 at 05:56 +0000, Gautam (Gautam Kumar) Shukla wrote:
>> For offloading 4 way handshake to driver, currently we don't have any
>> member of struct cfg80211_connect_params to pass PSK from supplicant
>> to driver. I have added psk for the same and added rest of the code
>> needed in nl80211.h and nl80211.c to parse and make it available to
>> driver.
>> From supplicant, we already have psk member field in assoc_params to
>> use .
>>
>> Tested on x86 linux.
>
> Your commit message needs serious work.
>
> Also, there's a competing approach from QCA that's far more suited.
I probably was not paying attention to it, but would you have a
reference to this.
> In either case though, I'm going to ask which driver is going to use
> this and when it's going to land in mainline.
I had the same question ;-)
> johannes
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" 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
* [PATCH] ping mdev rounding issue
From: David Buckley @ 2014-11-11 9:16 UTC (permalink / raw)
To: netdev
[-- Attachment #1: Type: text/plain, Size: 2110 bytes --]
ping has a rounding issue in standard deviation computation.
It stores all values as integer micros, and computes standard deviation
as:
sqrt(SUM(time*time)/count - (SUM(time)/count)*(SUM(time)/count))
Because the second 'count' divide is performed before the multiply, a
rounding error results of the order O(sqrt(SUM(time)/count)).
Example: I ping my server twice. One takes 1000us, the second takes
1001us.
Standard deviation computed by ping is:
sqrt((1000000+1002001)/2 - ((1000+1001)/2)*((1000+1001)/2))
= sqrt(1001000 - 1000*1000) = sqrt(1000) = 31
So we got a 1us difference and report a 31 us standard deviation.
If the samples are 999 and 1001
sqrt((998001+1002001)/2 - ((999+1001)/2)*((999+1001)/2))
= sqrt(1000001 - 1000*1000) = sqrt(1) = 0
So more deviation makes for less /reported/ deviation.
This is reduced slightly in this case by more samples (100*1000+1001
reports deviation of 4us, for instance), but really it's caused by the
rounding error ((float)SUM(time)/count) - (SUM(time)/count) being
/multiplied/ by the average time. The expected error is of the order
sqrt(mean).
Example real-world bad computation:
PING 74.125.230.238 (74.125.230.238) 56(84) bytes of data.
64 bytes from 74.125.230.238: icmp_seq=1 ttl=51 time=16.1 ms
64 bytes from 74.125.230.238: icmp_seq=2 ttl=51 time=16.1 ms
64 bytes from 74.125.230.238: icmp_seq=3 ttl=51 time=16.2 ms
64 bytes from 74.125.230.238: icmp_seq=4 ttl=51 time=16.1 ms
^C
--- google.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3003ms
rtt min/avg/max/mdev = 16.132/16.170/16.246/0.161 ms
With patch (attached):
PING 74.125.230.238 (74.125.230.238) 56(84) bytes of data.
64 bytes from 74.125.230.238: icmp_seq=1 ttl=51 time=16.0 ms
64 bytes from 74.125.230.238: icmp_seq=2 ttl=51 time=16.1 ms
64 bytes from 74.125.230.238: icmp_seq=3 ttl=51 time=16.1 ms
64 bytes from 74.125.230.238: icmp_seq=4 ttl=51 time=16.1 ms
^C
--- 74.125.230.238 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3003ms
rtt min/avg/max/mdev = 16.045/16.128/16.197/0.054 ms
--
David Buckley
[-- Attachment #2: fix_rounding.patch --]
[-- Type: text/x-diff, Size: 793 bytes --]
--- a/ping_common.c 2014-11-11 00:02:07.000000000 +0000
+++ b/ping_common.c 2014-11-11 09:04:06.699021939 +0000
@@ -1016,14 +1016,17 @@
}
putchar('\n');
if (nreceived && timing) {
long tmdev;
+ long count = nreceived + nrepeats;
- tsum /= nreceived + nrepeats;
- tsum2 /= nreceived + nrepeats;
- tmdev = llsqrt(tsum2 - tsum * tsum);
+ // mdev = sqrt((tsum2/count) - (tsum/count)*(tsum2/count))
+ // However, we must be careful about rounding!
+ tmdev = llsqrt((tsum2 * count - tsum * tsum) / (count * count));
+ tsum2 /= count;
+ tsum /= count;
printf("rtt min/avg/max/mdev = %ld.%03ld/%lu.%03ld/%ld.%03ld/%ld.%03ld ms",
(long)tmin/1000, (long)tmin%1000,
(unsigned long)(tsum/1000), (long)(tsum%1000),
(long)tmax/1000, (long)tmax%1000,
^ permalink raw reply
* Re: [PATCH 2/2] linux-wireless:Added wiphy capability flag for offloading 4way handshake to driver
From: Arend van Spriel @ 2014-11-11 9:49 UTC (permalink / raw)
To: Gautam (Gautam Kumar) Shukla,
linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org,
davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org,
linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Jithu Jance,
Sreenath S
In-Reply-To: <DF163EE1A432BF4BBE6B2088220663A6743890-HXj2mutaA2pmqaqore1TH5r/X4hKkxxPpWgKQ6/u3Fg@public.gmane.org>
On 11-11-14 07:27, Gautam (Gautam Kumar) Shukla wrote:
>
> For offloading 4 way handshake to driver , currently we don't have WIPHY capability flag to communicate same to supplicant.
> I have added the flag NL80211_ATTR_4WAY_KEY_HANDSHAKE and rest of the code for the same.
>
> Tested on x86 linux machine
>
> Signed-off-by: Gautam kumar shukla <gautams-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
> ---
> include/net/cfg80211.h | 4 ++++
> include/uapi/linux/nl80211.h | 5 ++++-
> net/wireless/nl80211.c | 4 ++++
> 3 files changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
> index 6f744e0..b37de0a 100644
> --- a/include/net/cfg80211.h
> +++ b/include/net/cfg80211.h
> @@ -2629,7 +2629,10 @@ struct cfg80211_ops {
> * TSPEC sessions (TID aka TSID 0-7) with the NL80211_CMD_ADD_TX_TS
> * command. Standard IEEE 802.11 TSPEC setup is not yet supported, it
> * needs to be able to handle Block-Ack agreements and other things.
> + * @WIPHY_FLAG_SUPPORTS_4WAY_HANDHSHAKE:the device supports 4way handshake
Indentation seems wrong here. Also add space after the colon sign.
> + * in the driver/firmware.
> */
> +
> enum wiphy_flags {
> WIPHY_FLAG_SUPPORTS_WMM_ADMISSION = BIT(0),
> /* use hole at 1 */
> @@ -2654,6 +2657,7 @@ enum wiphy_flags {
> WIPHY_FLAG_HAS_REMAIN_ON_CHANNEL = BIT(21),
> WIPHY_FLAG_SUPPORTS_5_10_MHZ = BIT(22),
> WIPHY_FLAG_HAS_CHANNEL_SWITCH = BIT(23),
> + WIPHY_FLAG_SUPPORTS_4WAY_HANDSHAKE = BIT(24),
> };
>
> /**
> diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
> index b01d5dd..2c474a3 100644
> --- a/include/uapi/linux/nl80211.h
> +++ b/include/uapi/linux/nl80211.h
> @@ -1640,9 +1640,11 @@ enum nl80211_commands {
> *
> * @NL80211_ATTR_PSK: a PSK value (u8 attribute).This is 32-octet (256-bit)
> * PSK.
> + * @NL80211_ATTR_4WAY_KEY_HANDSHAKE: Indicates whether the driver is capable
> + * of 4way key handshake
convention is to have a tab in the continuing line.
> *
> *
> - * @NL80211_ATTR_MAX: highest attribute number currently defined
> + * * @NL80211_ATTR_MAX: highest attribute number currently defined
huh?
> * @__NL80211_ATTR_AFTER_LAST: internal use
> */
> enum nl80211_attrs {
> @@ -1995,6 +1997,7 @@ enum nl80211_attrs {
> NL80211_ATTR_SMPS_MODE,
>
> NL80211_ATTR_PSK,
> + NL80211_ATTR_4WAY_KEY_HANDSHAKE,
>
> /* add attributes here, update the policy in nl80211.c */
>
> diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
> index 91c24b1..5f85c41 100644
> --- a/net/wireless/nl80211.c
> +++ b/net/wireless/nl80211.c
> @@ -396,6 +396,7 @@ static const struct nla_policy nl80211_policy[NL80211_ATTR_MAX+1] = {
> [NL80211_ATTR_ADMITTED_TIME] = { .type = NLA_U16 },
> [NL80211_ATTR_SMPS_MODE] = { .type = NLA_U8 },
> [NL80211_ATTR_PSK] = { .type = NLA_BINARY, .len = 32 },
> + [NL80211_ATTR_4WAY_KEY_HANDSHAKE] = { .type = NLA_FLAG },
> };
>
> /* policy for the key attributes */
> @@ -1303,6 +1304,9 @@ static int nl80211_send_wiphy(struct cfg80211_registered_device *rdev,
> if ((rdev->wiphy.flags & WIPHY_FLAG_SUPPORTS_FW_ROAM) &&
> nla_put_flag(msg, NL80211_ATTR_ROAM_SUPPORT))
> goto nla_put_failure;
> + if ((rdev->wiphy.flags & WIPHY_FLAG_SUPPORTS_4WAY_HANDSHAKE) &&
> + nla_put_flag(msg,NL80211_ATTR_4WAY_KEY_HANDSHAKE))
> + goto nla_put_failure;
> if ((rdev->wiphy.flags & WIPHY_FLAG_SUPPORTS_TDLS) &&
> nla_put_flag(msg, NL80211_ATTR_TDLS_SUPPORT))
> goto nla_put_failure;
>
^ permalink raw reply
* Re: [PATCH 1/1] linux-wireless: Added psk in struct cfg80211_connect_params needed for offloading 4way handshake to driver
From: Arend van Spriel @ 2014-11-11 9:44 UTC (permalink / raw)
To: Gautam (Gautam Kumar) Shukla,
linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org,
davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org,
linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Jithu Jance,
Sreenath S
In-Reply-To: <DF163EE1A432BF4BBE6B2088220663A67437BD-HXj2mutaA2pmqaqore1TH5r/X4hKkxxPpWgKQ6/u3Fg@public.gmane.org>
On 11-11-14 06:56, Gautam (Gautam Kumar) Shukla wrote:
>
Hi Gautam,
Good to see more upstream contributions, but it might be useful to have
a driver implementation as well in this series. Maybe we can take a shot
with brcmfmac for obvious reasons. Would you happen to have
wpa_supplicant changes as well?
I added some inline comments below.
Regards,
Arend
> For offloading 4 way handshake to driver, currently we don't have any member of struct cfg80211_connect_params to pass PSK from supplicant to driver. I have added psk for the same and added rest of the code needed in nl80211.h and nl80211.c to parse and make it available to driver.
> From supplicant, we already have psk member field in assoc_params to use .
In the commit message you should not describe what you did, but what
problem you are trying to solve and/or what functional change the patch
provides.
> Tested on x86 linux.
>
> Signed-off-by: Gautam kumar shukla <gautams-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
> ---
> include/net/cfg80211.h | 2 ++
> include/uapi/linux/nl80211.h | 8 +++++++-
> net/wireless/nl80211.c | 4 ++++
> 3 files changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h index a2ddcf2..6f744e0 100644
> --- a/include/net/cfg80211.h
> +++ b/include/net/cfg80211.h
> @@ -1758,6 +1758,7 @@ struct cfg80211_ibss_params {
> * allowed to ignore this @bssid_hint if it has knowledge of a better BSS
> * to use.
> * @ssid: SSID
> + * @psk:preshared key for WPA2-PSK connection or %NULL if not specified
add space after the colon sign.
> * @ssid_len: Length of ssid in octets
> * @auth_type: Authentication type (algorithm)
> * @ie: IEs for association request
> @@ -1783,6 +1784,7 @@ struct cfg80211_connect_params {
> const u8 *bssid;
> const u8 *bssid_hint;
> const u8 *ssid;
> + const u8 *psk;
> size_t ssid_len;
> enum nl80211_auth_type auth_type;
> const u8 *ie;
> diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h index 4b28dc0..b01d5dd 100644
> --- a/include/uapi/linux/nl80211.h
> +++ b/include/uapi/linux/nl80211.h
> @@ -421,7 +421,7 @@
> * %NL80211_ATTR_MAC, %NL80211_ATTR_WIPHY_FREQ, %NL80211_ATTR_CONTROL_PORT,
> * %NL80211_ATTR_CONTROL_PORT_ETHERTYPE,
> * %NL80211_ATTR_CONTROL_PORT_NO_ENCRYPT, %NL80211_ATTR_MAC_HINT, and
> - * %NL80211_ATTR_WIPHY_FREQ_HINT.
> + * %NL80211_ATTR_WIPHY_FREQ_HINT, and %NL80211_ATTR_PSK.
> * If included, %NL80211_ATTR_MAC and %NL80211_ATTR_WIPHY_FREQ are
> * restrictions on BSS selection, i.e., they effectively prevent roaming
> * within the ESS. %NL80211_ATTR_MAC_HINT and %NL80211_ATTR_WIPHY_FREQ_HINT @@ -1638,6 +1638,10 @@ enum nl80211_commands {
> * @NL80211_ATTR_SMPS_MODE: SMPS mode to use (ap mode). see
> * &enum nl80211_smps_mode.
> *
> + * @NL80211_ATTR_PSK: a PSK value (u8 attribute).This is 32-octet
> + (256-bit)
> + * PSK.
> + *
Some indentation gone haywire here. I would remove '(u8 attribute)'. The
mention of 32-octet seems sufficient to me.
> * @NL80211_ATTR_MAX: highest attribute number currently defined
> * @__NL80211_ATTR_AFTER_LAST: internal use
> */
> @@ -1990,6 +1994,8 @@ enum nl80211_attrs {
>
> NL80211_ATTR_SMPS_MODE,
>
> + NL80211_ATTR_PSK,
> +
> /* add attributes here, update the policy in nl80211.c */
>
> __NL80211_ATTR_AFTER_LAST,
> diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c index 5839c85..91c24b1 100644
> --- a/net/wireless/nl80211.c
> +++ b/net/wireless/nl80211.c
> @@ -395,6 +395,7 @@ static const struct nla_policy nl80211_policy[NL80211_ATTR_MAX+1] = {
> [NL80211_ATTR_USER_PRIO] = { .type = NLA_U8 },
> [NL80211_ATTR_ADMITTED_TIME] = { .type = NLA_U16 },
> [NL80211_ATTR_SMPS_MODE] = { .type = NLA_U8 },
> + [NL80211_ATTR_PSK] = { .type = NLA_BINARY, .len = 32 },
> };
>
> /* policy for the key attributes */
> @@ -7310,6 +7311,9 @@ static int nl80211_connect(struct sk_buff *skb, struct genl_info *info)
> connect.flags |= ASSOC_REQ_USE_RRM;
> }
>
> + if (info->attrs[NL80211_ATTR_PSK])
> + connect.psk = nla_data(info->attrs[NL80211_ATTR_PSK]);
> +
> wdev_lock(dev->ieee80211_ptr);
> err = cfg80211_connect(rdev, dev, &connect, connkeys, NULL);
> wdev_unlock(dev->ieee80211_ptr);
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
^ permalink raw reply
* Re: [PATCH net-next 0/3] dev_disable_lro() improvements for stacked devices
From: Michal Kubecek @ 2014-11-11 9:34 UTC (permalink / raw)
To: Veaceslav Falico
Cc: David S. Miller, netdev, linux-kernel, Jay Vosburgh,
Andy Gospodarek, Jiri Pirko
In-Reply-To: <20141111090522.GB20586@raspberrypi>
On Tue, Nov 11, 2014 at 10:05:22AM +0100, Veaceslav Falico wrote:
> On Tue, Nov 11, 2014 at 09:21:30AM +0100, Michal Kubecek wrote:
> >Large receive offloading is known to cause problems if received packets
> >are passed to other host. Therefore the kernel disables it by calling
> >dev_disable_lro() whenever a network device is enslaved in a bridge or
> >forwarding is enabled for it (or globally). For virtual devices we need
> >to disable LRO on the underlying physical device (which is actually
> >receiving the packets).
> >
> >Current dev_disable_lro() code handles this propagation for a vlan
> >(including 802.1ad nested vlan), macvlan or a vlan on top of a macvlan.
> >This patch adds LRO disabling propagation for
> >
> > - macvlan on top of a vlan or any stacked combination of those
> > - bonding
> > - teaming
>
> All of these drivers use the netdev_upper and friends, so why not make it
> generic with netdev_for_each_all_lower() in dev_disable_lro()?
I wanted to preserve current approach where for vlan and macvlan, LRO is
disabled on the real device instead of the original one (rather than in
addition to it) as LRO is always disabled on them.
Handling all four uniformly would make the code nicer but would bring
unnecessary overhead of traversing the list and dev_disable_lro()
recursion. On the other hand, this operation is not time critical so it
might be acceptable after all.
Michal Kubecek
^ permalink raw reply
* Re: [PATCH 1/1] linux-wireless: Added psk in struct cfg80211_connect_params needed for offloading 4way handshake to driver
From: Johannes Berg @ 2014-11-11 9:29 UTC (permalink / raw)
To: Gautam (Gautam Kumar) Shukla
Cc: linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org,
linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org,
linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Jithu Jance,
Sreenath S
In-Reply-To: <DF163EE1A432BF4BBE6B2088220663A67437BD-HXj2mutaA2pmqaqore1TH5r/X4hKkxxPpWgKQ6/u3Fg@public.gmane.org>
On Tue, 2014-11-11 at 05:56 +0000, Gautam (Gautam Kumar) Shukla wrote:
> For offloading 4 way handshake to driver, currently we don't have any
> member of struct cfg80211_connect_params to pass PSK from supplicant
> to driver. I have added psk for the same and added rest of the code
> needed in nl80211.h and nl80211.c to parse and make it available to
> driver.
> From supplicant, we already have psk member field in assoc_params to
> use .
>
> Tested on x86 linux.
Your commit message needs serious work.
Also, there's a competing approach from QCA that's far more suited.
In either case though, I'm going to ask which driver is going to use
this and when it's going to land in mainline.
johannes
^ permalink raw reply
* Re: Face some error after applying commit 7dfa4b414d4(net/mlx4_en: Code cleanups in tx path)
From: Wei Yang @ 2014-11-11 9:12 UTC (permalink / raw)
To: Amir Vadai
Cc: Wei Yang, Eric Dumazet, Eric Dumazet, David Miller, netdev,
gerlitz.or
In-Reply-To: <CAPcc5PgFqzSVZ9rj8yj7LyuCjQXafP5J4bohcL4h7SFMc-rAJg@mail.gmail.com>
On Tue, Nov 11, 2014 at 10:40:24AM +0200, Amir Vadai wrote:
>On Tue, Nov 11, 2014 at 9:42 AM, Wei Yang <weiyang@linux.vnet.ibm.com> wrote:
>>>>>Hi,
>>>>>
>>>>>Lets see that we're on the same page here:
>>>>>1. There was a compilation problem that you fixed (Yes, it was my fault
>>>>>- I just discovered it a minute after the code was applied).
>>>>>2. When you're using SR-IOV, during initialization, you get a CQE error
>>>>>with syndrome 0x2 on one of the probed VF's.
>>>>
>>>> From the log, seems yes.
>>>>
>>>>>3. Regarding the BlueFlame - I don't see how it is related to the issue
>>>>>that you see. But it is a very easy experiment. Issue: "ethtool
>>>>>--set-priv-flags eth1 blueflame off"
>>>>
>>>> I tried to use this after mlx4_en is loaded, still see the CQE error.
>>>>
>>>>>
>>>>>Please send me the module parameters you used when loading mlx4_core, a
>>>>>full dmesg with both mlx4_core and mlx4_en loading.
>>>>
>>>> The command line I use is:
>>>> modprobe mlx4_core num_vfs=1 probe_vf=1 port_type_array=2,2
>>>>
>>>> The log I sent in the first mail is the full log, including the CQE error, one
>>>> warning in watchdog, and then print the CQE error periodicly. What else
>>>> message you would like me to capture?
>>>
>>>The log in the first mail has only mlx4_en logs. I would like to see
>>>the full log, that has mlx4_core messages too. And as Or suggested,
>>>debug_level=1 could be useful here too.
>>>
>>
>> Ah, you need the log from mlx4_core too. Ok, I will do it again.
>>
>> BTW, how to add the debug_level=1 in the command line? Like this?
>>
>> modprobe mlx4_core num_vfs=1 probe_vf=1 port_type_array=2,2 debug_level=1
>yes
>
I past the full log here, but I don't see the log level affact.
[ 5723.612882] mlx4_core: Mellanox ConnectX core driver v2.2-1 (Feb, 2014)
[ 5723.612979] mlx4_core: Initializing 0003:05:00.0
[ 5723.613023] pci 0003:05: 0.1: [PE# 222] VF 0003:05:00.1 associated with PE#222
[ 5723.613299] pci 0003:05: 0.1: [PE# 222] Setting up 32-bit TCE table at 0..80000000
[ 5723.684140] pci 0003:05: 0.1: [PE# 222] Enabling 64-bit DMA bypass
[ 5723.684215] pci 0003:05: 0.2: [PE# 223] VF 0003:05:00.2 associated with PE#223
[ 5723.684409] pci 0003:05: 0.2: [PE# 223] Setting up 32-bit TCE table at 0..80000000
[ 5723.754871] pci 0003:05: 0.2: [PE# 223] Enabling 64-bit DMA bypass
[ 5723.754944] pci 0003:05: 0.3: [PE# 224] VF 0003:05:00.3 associated with PE#224
[ 5723.755150] pci 0003:05: 0.3: [PE# 224] Setting up 32-bit TCE table at 0..80000000
[ 5723.825646] pci 0003:05: 0.3: [PE# 224] Enabling 64-bit DMA bypass
[ 5723.825718] pci 0003:05: 0.4: [PE# 225] VF 0003:05:00.4 associated with PE#225
[ 5723.825911] pci 0003:05: 0.4: [PE# 225] Setting up 32-bit TCE table at 0..80000000
[ 5723.896342] pci 0003:05: 0.4: [PE# 225] Enabling 64-bit DMA bypass
[ 5723.896416] pci 0003:05: 0.5: [PE# 226] VF 0003:05:00.5 associated with PE#226
[ 5723.896610] pci 0003:05: 0.5: [PE# 226] Setting up 32-bit TCE table at 0..80000000
[ 5723.967052] pci 0003:05: 0.5: [PE# 226] Enabling 64-bit DMA bypass
[ 5723.967135] pci 0003:05: 0.6: [PE# 227] VF 0003:05:00.6 associated with PE#227
[ 5723.967328] pci 0003:05: 0.6: [PE# 227] Setting up 32-bit TCE table at 0..80000000
[ 5724.037755] pci 0003:05: 0.6: [PE# 227] Enabling 64-bit DMA bypass
[ 5724.037829] pci 0003:05: 0.7: [PE# 228] VF 0003:05:00.7 associated with PE#228
[ 5724.038022] pci 0003:05: 0.7: [PE# 228] Setting up 32-bit TCE table at 0..80000000
[ 5724.108452] pci 0003:05: 0.7: [PE# 228] Enabling 64-bit DMA bypass
[ 5724.108525] pci 0003:05: 1.0: [PE# 229] VF 0003:05:01.0 associated with PE#229
[ 5724.108718] pci 0003:05: 1.0: [PE# 229] Setting up 32-bit TCE table at 0..80000000
[ 5724.179209] pci 0003:05: 1.0: [PE# 229] Enabling 64-bit DMA bypass
[ 5724.179293] pci 0003:05: 1.1: [PE# 230] VF 0003:05:01.1 associated with PE#230
[ 5724.179486] pci 0003:05: 1.1: [PE# 230] Setting up 32-bit TCE table at 0..80000000
[ 5724.249946] pci 0003:05: 1.1: [PE# 230] Enabling 64-bit DMA bypass
[ 5724.250020] pci 0003:05: 1.2: [PE# 231] VF 0003:05:01.2 associated with PE#231
[ 5724.250214] pci 0003:05: 1.2: [PE# 231] Setting up 32-bit TCE table at 0..80000000
[ 5724.320703] pci 0003:05: 1.2: [PE# 231] Enabling 64-bit DMA bypass
[ 5724.320787] pci 0003:05: 1.3: [PE# 232] VF 0003:05:01.3 associated with PE#232
[ 5724.320982] pci 0003:05: 1.3: [PE# 232] Setting up 32-bit TCE table at 0..80000000
[ 5724.391424] pci 0003:05: 1.3: [PE# 232] Enabling 64-bit DMA bypass
[ 5724.391497] pci 0003:05: 1.4: [PE# 233] VF 0003:05:01.4 associated with PE#233
[ 5724.391690] pci 0003:05: 1.4: [PE# 233] Setting up 32-bit TCE table at 0..80000000
[ 5724.462129] pci 0003:05: 1.4: [PE# 233] Enabling 64-bit DMA bypass
[ 5724.462215] pci 0003:05: 1.5: [PE# 234] VF 0003:05:01.5 associated with PE#234
[ 5724.462408] pci 0003:05: 1.5: [PE# 234] Setting up 32-bit TCE table at 0..80000000
[ 5724.532834] pci 0003:05: 1.5: [PE# 234] Enabling 64-bit DMA bypass
[ 5724.532907] pci 0003:05: 1.6: [PE# 235] VF 0003:05:01.6 associated with PE#235
[ 5724.533100] pci 0003:05: 1.6: [PE# 235] Setting up 32-bit TCE table at 0..80000000
[ 5724.603556] pci 0003:05: 1.6: [PE# 235] Enabling 64-bit DMA bypass
[ 5724.603628] pci 0003:05: 1.7: [PE# 236] VF 0003:05:01.7 associated with PE#236
[ 5724.603822] pci 0003:05: 1.7: [PE# 236] Setting up 32-bit TCE table at 0..80000000
[ 5724.674261] pci 0003:05: 1.7: [PE# 236] Enabling 64-bit DMA bypass
[ 5724.674334] pci 0003:05: 2.0: [PE# 237] VF 0003:05:02.0 associated with PE#237
[ 5724.674528] pci 0003:05: 2.0: [PE# 237] Setting up 32-bit TCE table at 0..80000000
[ 5724.745012] pci 0003:05: 2.0: [PE# 237] Enabling 64-bit DMA bypass
[ 5724.745088] pci 0003:05: 2.1: [PE# 238] VF 0003:05:02.1 associated with PE#238
[ 5724.745281] pci 0003:05: 2.1: [PE# 238] Setting up 32-bit TCE table at 0..80000000
[ 5724.815714] pci 0003:05: 2.1: [PE# 238] Enabling 64-bit DMA bypass
[ 5724.815786] pci 0003:05: 2.2: [PE# 239] VF 0003:05:02.2 associated with PE#239
[ 5724.815979] pci 0003:05: 2.2: [PE# 239] Setting up 32-bit TCE table at 0..80000000
[ 5724.886413] pci 0003:05: 2.2: [PE# 239] Enabling 64-bit DMA bypass
[ 5724.886487] pci 0003:05: 2.3: [PE# 240] VF 0003:05:02.3 associated with PE#240
[ 5724.886680] pci 0003:05: 2.3: [PE# 240] Setting up 32-bit TCE table at 0..80000000
[ 5724.957126] pci 0003:05: 2.3: [PE# 240] Enabling 64-bit DMA bypass
[ 5724.957210] pci 0003:05: 2.4: [PE# 241] VF 0003:05:02.4 associated with PE#241
[ 5724.957403] pci 0003:05: 2.4: [PE# 241] Setting up 32-bit TCE table at 0..80000000
[ 5725.027842] pci 0003:05: 2.4: [PE# 241] Enabling 64-bit DMA bypass
[ 5725.027917] pci 0003:05: 2.5: [PE# 242] VF 0003:05:02.5 associated with PE#242
[ 5725.028109] pci 0003:05: 2.5: [PE# 242] Setting up 32-bit TCE table at 0..80000000
[ 5725.098551] pci 0003:05: 2.5: [PE# 242] Enabling 64-bit DMA bypass
[ 5725.098624] pci 0003:05: 2.6: [PE# 243] VF 0003:05:02.6 associated with PE#243
[ 5725.098818] pci 0003:05: 2.6: [PE# 243] Setting up 32-bit TCE table at 0..80000000
[ 5725.169255] pci 0003:05: 2.6: [PE# 243] Enabling 64-bit DMA bypass
[ 5725.169338] pci 0003:05: 2.7: [PE# 244] VF 0003:05:02.7 associated with PE#244
[ 5725.169532] pci 0003:05: 2.7: [PE# 244] Setting up 32-bit TCE table at 0..80000000
[ 5725.239962] pci 0003:05: 2.7: [PE# 244] Enabling 64-bit DMA bypass
[ 5725.240036] pci 0003:05: 3.0: [PE# 245] VF 0003:05:03.0 associated with PE#245
[ 5725.240229] pci 0003:05: 3.0: [PE# 245] Setting up 32-bit TCE table at 0..80000000
[ 5725.310678] pci 0003:05: 3.0: [PE# 245] Enabling 64-bit DMA bypass
[ 5725.310751] pci 0003:05: 3.1: [PE# 246] VF 0003:05:03.1 associated with PE#246
[ 5725.310944] pci 0003:05: 3.1: [PE# 246] Setting up 32-bit TCE table at 0..80000000
[ 5725.381375] pci 0003:05: 3.1: [PE# 246] Enabling 64-bit DMA bypass
[ 5725.381459] pci 0003:05: 3.2: [PE# 247] VF 0003:05:03.2 associated with PE#247
[ 5725.381653] pci 0003:05: 3.2: [PE# 247] Setting up 32-bit TCE table at 0..80000000
[ 5725.452087] pci 0003:05: 3.2: [PE# 247] Enabling 64-bit DMA bypass
[ 5725.452171] pci 0003:05: 3.3: [PE# 248] VF 0003:05:03.3 associated with PE#248
[ 5725.452365] pci 0003:05: 3.3: [PE# 248] Setting up 32-bit TCE table at 0..80000000
[ 5725.522815] pci 0003:05: 3.3: [PE# 248] Enabling 64-bit DMA bypass
[ 5725.522889] pci 0003:05: 3.4: [PE# 249] VF 0003:05:03.4 associated with PE#249
[ 5725.523082] pci 0003:05: 3.4: [PE# 249] Setting up 32-bit TCE table at 0..80000000
[ 5725.593516] pci 0003:05: 3.4: [PE# 249] Enabling 64-bit DMA bypass
[ 5725.593590] pci 0003:05: 3.5: [PE# 250] VF 0003:05:03.5 associated with PE#250
[ 5725.593783] pci 0003:05: 3.5: [PE# 250] Setting up 32-bit TCE table at 0..80000000
[ 5725.664330] pci 0003:05: 3.5: [PE# 250] Enabling 64-bit DMA bypass
[ 5725.664403] pci 0003:05: 3.6: [PE# 251] VF 0003:05:03.6 associated with PE#251
[ 5725.664597] pci 0003:05: 3.6: [PE# 251] Setting up 32-bit TCE table at 0..80000000
[ 5725.735081] pci 0003:05: 3.6: [PE# 251] Enabling 64-bit DMA bypass
[ 5725.735154] pci 0003:05: 3.7: [PE# 252] VF 0003:05:03.7 associated with PE#252
[ 5725.735348] pci 0003:05: 3.7: [PE# 252] Setting up 32-bit TCE table at 0..80000000
[ 5725.805792] pci 0003:05: 3.7: [PE# 252] Enabling 64-bit DMA bypass
[ 5725.805865] pci 0003:05: 4.0: [PE# 253] VF 0003:05:04.0 associated with PE#253
[ 5725.806058] pci 0003:05: 4.0: [PE# 253] Setting up 32-bit TCE table at 0..80000000
[ 5725.876496] pci 0003:05: 4.0: [PE# 253] Enabling 64-bit DMA bypass
[ 5725.876570] pci 0003:05: 4.1: [PE# 254] VF 0003:05:04.1 associated with PE#254
[ 5725.876763] pci 0003:05: 4.1: [PE# 254] Setting up 32-bit TCE table at 0..80000000
[ 5725.945133] pci 0003:05: 4.1: [PE# 254] Enabling 64-bit DMA bypass
[ 5725.945212] pci 0003:05: 4.2: [PE# 255] VF 0003:05:04.2 associated with PE#255
[ 5725.945316] pci 0003:05: 4.2: [PE# 255] Setting up 32-bit TCE table at 0..80000000
[ 5726.006975] pci 0003:05: 4.2: [PE# 255] Enabling 64-bit DMA bypass
[ 5726.007163] mlx4_core 0003:05:00.0: Using 64-bit DMA iommu bypass
[ 5726.007227] mlx4_core 0003:05:00.0: Enabling SR-IOV with 1 VFs
[ 5726.116742] mlx4_core: Initializing 0003:05:00.1
[ 5726.116825] mlx4_core 0003:05:00.1: enabling device (0000 -> 0002)
[ 5726.116914] mlx4_core 0003:05:00.1: Using 64-bit DMA iommu bypass
[ 5726.116976] mlx4_core 0003:05:00.1: Detected virtual function - running in slave mode
[ 5726.117191] mlx4_core 0003:05:00.1: PF is not ready - Deferring probe
[ 5726.117276] pci 0003:05:00.1: Driver mlx4_core requests probe deferral
[ 5726.117363] mlx4_core 0003:05:00.0: Running in master mode
[ 5731.123148] mlx4_core 0003:05:00.0: PCIe link speed is 8.0GT/s, device supports 8.0GT/s
[ 5731.123227] mlx4_core 0003:05:00.0: PCIe link width is x8, device supports x8
[ 5731.151307] mlx4_core: Initializing 0003:05:00.1
[ 5731.151389] mlx4_core 0003:05:00.1: enabling device (0000 -> 0002)
[ 5731.151501] mlx4_core 0003:05:00.1: Using 64-bit DMA iommu bypass
[ 5731.151559] mlx4_core 0003:05:00.1: Detected virtual function - running in slave mode
[ 5731.151636] mlx4_core 0003:05:00.1: Sending reset
[ 5731.151770] mlx4_core 0003:05:00.0: Received reset from slave:1
[ 5731.152189] mlx4_core 0003:05:00.1: Sending vhcr0
[ 5731.152991] mlx4_core 0003:05:00.1: HCA minimum page size:512
[ 5731.153444] mlx4_core 0003:05:00.1: Timestamping is not supported in slave mode
[root@tian-lp1 ywywyang]# [ 5731.229958] mlx4_en: Mellanox ConnectX HCA Ethernet driver v2.2-1 (Feb 2014)
[ 5731.230572] mlx4_en 0003:05:00.0: registered PHC clock
[ 5731.230817] mlx4_en 0003:05:00.0: Activating port:1
[ 5731.262377] mlx4_en: eth12: Using 256 TX rings
[ 5731.262494] mlx4_en: eth12: Using 4 RX rings
[ 5731.262546] mlx4_en: eth12: frag:0 - size:1518 prefix:0 align:0 stride:1536
[ 5731.262761] mlx4_en: eth12: Initializing port
[ 5731.263357] mlx4_en 0003:05:00.1: Activating port:1
[ 5731.263467] mlx4_en: 0003:05:00.1: Port 1: Assigned random MAC address d6:0f:0b:57:36:24
[ 5731.442926] mlx4_en: eth13: Using 256 TX rings
[ 5731.443010] mlx4_en: eth13: Using 4 RX rings
[ 5731.443018] mlx4_en: eth13: frag:0 - size:1518 prefix:0 align:0 stride:1536
[ 5731.443304] mlx4_en: eth13: Initializing port
[ 5732.096548] mlx4_en: eth13: frag:0 - size:1518 prefix:0 align:0 stride:1536
[ 5732.452283] IPv6: ADDRCONF(NETDEV_UP): eth13: link is not ready
[ 5732.951420] mlx4_en: eth12: Link Up
[ 5732.951477] mlx4_en: eth13: Link Up
[ 5732.951627] IPv6: ADDRCONF(NETDEV_CHANGE): eth13: link becomes ready
[ 5733.171020] mlx4_en: eth13: CQE error - vendor syndrome: 0x6f syndrome: 0x2
[ 5733.315756] mlx4_en: eth13: CQE error - vendor syndrome: 0x6f syndrome: 0x2
[ 5734.165387] mlx4_en: eth13: CQE error - vendor syndrome: 0x6f syndrome: 0x2
[ 5748.045084] NETDEV WATCHDOG: eth13 (mlx4_core): transmit queue 1 timed out
[ 5748.045245] ------------[ cut here ]------------
[ 5748.045301] WARNING: at net/sched/sch_generic.c:303
[ 5748.045355] Modules linked in: mlx4_en(O) mlx4_core nf_conntrack_ipv6 nf_defrag_ipv6 bnep nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack bluetooth rfkill ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_mangle ip6table_security ip6table_raw ip6table_filter ip6_tables iptable_mangle iptable_security iptable_raw be2net tg3 ptp pps_core nfsd nfs_acl ses enclosure kvm_hv kvm_pr kvm lockd grace binfmt_misc shpchp sunrpc uinput lpfc ipr scsi_transport_fc [last unloaded: mlx4_core]
[ 5748.046069] CPU: 1 PID: 0 Comm: swapper/1 Tainted: P O 3.18.0-rc2yw+ #161
[ 5748.046142] task: c0000027ef4f92d0 ti: c0000027ef574000 task.ti: c0000027ef574000
[ 5748.046215] NIP: c00000000079a9d4 LR: c00000000079a9d0 CTR: 0000000030044878
[ 5748.046286] REGS: c0000027ef5772d0 TRAP: 0700 Tainted: P O (3.18.0-rc2yw+)
[ 5748.046357] MSR: 9000000000029032 <SF,HV,EE,ME,IR,DR,RI> CR: 28004024 XER: 00000000
[ 5748.046524] CFAR: c0000000008be150 SOFTE: 1
GPR00: c00000000079a9d0 c0000027ef577550 c00000000147acf0 000000000000003e
GPR04: c000002004145888 c000002004156240 9000000000009032 0000000000000029
GPR08: c000000000d1acf0 0000000000000000 0000002003430000 0000000030044954
GPR12: 0000000028004022 c00000000fdc0900 0000000000000001 c0000000008f10a8
GPR16: c0000027ef795438 c0000027ef795838 c0000027ef795c38 0000000000000000
GPR20: c0000027ef795038 c0000000014b2200 0000000000000000 0000000000000000
GPR24: 0000000000000000 ffffffffffffffff 0000000000000000 0000000000000001
GPR28: 0000000000000004 c0000000014b2200 c000002781340000 0000000000000001
[ 5748.047435] NIP [c00000000079a9d4] .dev_watchdog+0x354/0x370
[ 5748.047496] LR [c00000000079a9d0] .dev_watchdog+0x350/0x370
[ 5748.047544] Call Trace:
[ 5748.047570] [c0000027ef577550] [c00000000079a9d0] .dev_watchdog+0x350/0x370 (unreliable)
[ 5748.047655] [c0000027ef577600] [c0000000001275a4] .call_timer_fn+0x64/0x190
[ 5748.047727] [c0000027ef5776b0] [c00000000012814c] .run_timer_softirq+0x2bc/0x3d0
[ 5748.047812] [c0000027ef5777b0] [c0000000000ad738] .__do_softirq+0x168/0x390
[ 5748.047885] [c0000027ef5778b0] [c0000000000adcc8] .irq_exit+0xc8/0x110
[ 5748.047958] [c0000027ef577930] [c00000000001d15c] .timer_interrupt+0x9c/0xd0
[ 5748.048030] [c0000027ef5779b0] [c000000000002658] decrementer_common+0x158/0x180
[ 5748.048116] --- interrupt: 901 at .arch_local_irq_restore+0x74/0x90
[ 5748.048116] LR = .arch_local_irq_restore+0x74/0x90
[ 5748.048224] [c0000027ef577ca0] [c0000027ef577d30] 0xc0000027ef577d30 (unreliable)
[ 5748.048309] [c0000027ef577d10] [c00000000070887c] .cpuidle_enter_state+0xac/0x260
[ 5748.048393] [c0000027ef577dd0] [c0000000000f6c90] .cpu_startup_entry+0x410/0x460
[ 5748.048478] [c0000027ef577ed0] [c000000000040b40] .start_secondary+0x310/0x340
[ 5748.048562] [c0000027ef577f90] [c000000000008b6c] start_secondary_prolog+0x10/0x14
[ 5748.048643] Instruction dump:
[ 5748.048680] 994d02d4 4bffff10 7fc3f378 4bfd5ff1 60000000 7fc4f378 7fe6fb78 7c651b78
[ 5748.048799] 3c62ff75 3863afb8 48123721 60000000 <0fe00000> 39200001 3d02fff0 99282b88
[ 5748.048920] ---[ end trace a04deb5eef8eba41 ]---
[ 5748.385369] mlx4_en: eth13: frag:0 - size:1518 prefix:0 align:0 stride:1536
[ 5760.841519] mlx4_en: eth13: CQE error - vendor syndrome: 0x6f syndrome: 0x2
[ 5781.165457] mlx4_en: eth13: CQE error - vendor syndrome: 0x6f syndrome: 0x2
[ 5781.315631] mlx4_en: eth13: CQE error - vendor syndrome: 0x6f syndrome: 0x2
[ 5782.165413] mlx4_en: eth13: CQE error - vendor syndrome: 0x6f syndrome: 0x2
>>
>> But for mlx4_en, I am not sure I could raise the debug level with ethtool,
>> since the ethernet driver may not work properly. Actually I am not sure how to
>> raise the level with ethtool. Could you give me an example?
>
># ethtool -s ens5f1d1 msglvl 0xffff
>
>>
>>>>
>>>> And this error is reported from VF always. After the error, the other network
>>>> interface seems can't function.
>>>>
>>>>>
>>>>>Amir.
>>>>
>>>> --
>>>> Richard Yang
>>>> Help you, Help me
>>>>
>>>> --
>>>> 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
>>
>> --
>> Richard Yang
>> Help you, Help me
>>
>> --
>> 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
--
Richard Yang
Help you, Help me
^ permalink raw reply
* Re: [PATCH net-next 0/3] dev_disable_lro() improvements for stacked devices
From: Veaceslav Falico @ 2014-11-11 9:05 UTC (permalink / raw)
To: Michal Kubecek
Cc: David S. Miller, netdev, linux-kernel, Jay Vosburgh,
Andy Gospodarek, Jiri Pirko
In-Reply-To: <cover.1415692212.git.mkubecek@suse.cz>
On Tue, Nov 11, 2014 at 09:21:30AM +0100, Michal Kubecek wrote:
>Large receive offloading is known to cause problems if received packets
>are passed to other host. Therefore the kernel disables it by calling
>dev_disable_lro() whenever a network device is enslaved in a bridge or
>forwarding is enabled for it (or globally). For virtual devices we need
>to disable LRO on the underlying physical device (which is actually
>receiving the packets).
>
>Current dev_disable_lro() code handles this propagation for a vlan
>(including 802.1ad nested vlan), macvlan or a vlan on top of a macvlan.
>This patch adds LRO disabling propagation for
>
> - macvlan on top of a vlan or any stacked combination of those
> - bonding
> - teaming
All of these drivers use the netdev_upper and friends, so why not make it
generic with netdev_for_each_all_lower() in dev_disable_lro()?
>
>In the bonding and teaming case, it is necessary to disable LRO not only
>on slaves when dev_disable_lro() is called but also on any slave (port)
>added later.
>
>Michal Kubecek (3):
> net: handle more general stacking in dev_disable_lro()
> team: add helper to check if device is a team master
> net: propagate LRO disabling to bond and team slaves
>
> drivers/net/bonding/bond_main.c | 3 +++
> drivers/net/team/team.c | 6 +++++-
> include/linux/netdevice.h | 7 +++++++
> net/core/dev.c | 31 ++++++++++++++++++++++---------
> 4 files changed, 37 insertions(+), 10 deletions(-)
>
>--
>1.8.4.5
>
^ permalink raw reply
* Re: [patch net-next v2 00/10] introduce rocker switch driver with hardware accelerated datapath api - phase 1: bridge fdb offload
From: Simon Horman @ 2014-11-11 8:51 UTC (permalink / raw)
To: John Fastabend
Cc: Jamal Hadi Salim, 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, roopa, linville, jasowang,
ebiederm, nicolas.dichtel, ryazanov.s.a, buytenh, aviadr, nbd,
alexei.starovoitov, Neil.Jerram, ronye, alexander.h.duyck,
john.ronciak, mleitner, shrijeet, gospo
In-Reply-To: <54613AD3.7030600@gmail.com>
On Mon, Nov 10, 2014 at 02:23:15PM -0800, John Fastabend wrote:
> On 11/09/2014 08:58 PM, Simon Horman wrote:
> >On Sun, Nov 09, 2014 at 11:03:40PM -0500, Jamal Hadi Salim wrote:
> >>Hi Simon,
> >>
> >>On 11/09/14 22:46, Simon Horman wrote:
> >>>Hi Jamal, Hi Jiri,
> >>>
> >>>On a somewhat related note I am also wondering what if any progress has
> >>>been made regarding discussions of (and code for) the following:
> >>>
> >>>1. Exposing flow tables to user-space
> >>> - I realise that this is Open vSwitch specific to some extent
> >>> but I am in no way implying that it should be done instead of
> >>> non-Open vSwitch specific work.
> >>> - Jiri, IIRC this was part ~v2 of your earlier offload patchset
> >>>
> >>
> >>I dont know what Rocker crowd is doing; however, I know
> >>John F. has been doing some work which i have stared at
> >>and I was hoping to join in with Ben's effort and show tc flow
> >>offload on the realtek chip in my infinite spare time unles.
> >>(for both Linux bridge and ports).
> >>The priority is to merge the obvious bits first.
> >
> >Merging the obvious bits first is quite fine my me.
> >
>
> +1
>
> >>>2. Describing Switch Hardware
> >>> - I see John Fastabend moving forwards on this in his git repository
> >>> https://github.com/jrfastab/flow-net-next
> >>>
> >>>The way that I see things is that both of the above could be exposed via
> >>>netlink. And that the first at least could be backed by NDOs. As such I
> >>>see this work as complementary and perhaps applying on top of this
> >>>patchset. If I am mistaken in this regards it would be good to know :)
> >>>
> >>
> >>You are correct - I will let John speak on his work, but
> >>that is the intent.
> >>The challenge is there are many schools of thoughts and i am hoping
> >>it is not an arms race.
> >
> >That is also my hope.
>
> My intent is to submit the Flow API bits once the base rocker switch
> gets committed. I've implemented the Flow API against ixgbe and a
> sadly a proprietary SDK. I'll implement it against the rocker switch
> as well.
Understood, that seems like a good approach to me.
> >>>I am of course also interested to know if the above are moving forwards.
> >>>To be clear I am very interested in being able to use these APIs to
> >>>perform Open vSwitch offloads and I am very happy to help.
> >>>(Jamal: I'm also interested in non-Open vSwitch offloads :)
> >>>
> >>
>
> I think they are moving forward. I have some code cleanup to do on
> the flow API, but its mostly in place. Then I want to implement
> an example on Rocker switch so we could experiment with something
> why we wait for a real hardware driver. From my side assuming I at
> least got it close to correct should be doable in the next few week.
>
> After that I want to work with Jesse/Jamal and look at integrating
> with OVS and other stacks. I thought a bit about the OVS integration
> path but I'll hold that discussion for the moment.
I am looking forward to that discussion.
> Simon, if your feeling adventurous any feedback on the repo link
> would be great. I still need to smash the commit log into something
> coherent though at the moment you can see all the errors and rewrites,
> etc as I made them.
Sure, will do. I took a look over your code about two weeks ago but I
believe you have made some updates since then.
> >>Hey, OVS should be able to use these APIs; i am just interested in making
> >>sure they are not just for OVS or OF. Then we are all happy;->
> >
> >I think we are all happy :)
>
> I'm happy :) Also my intent is the flow API is more general then
> just OVS. My view is OVS should be one user of the API.
I agree entirely.
^ permalink raw reply
* [PATCH v2] usbnet: smsc95xx: dereferencing NULL pointer
From: Sudip Mukherjee @ 2014-11-11 8:40 UTC (permalink / raw)
To: Steve Glendinning; +Cc: Sudip Mukherjee, netdev, linux-usb, linux-kernel
we were dereferencing dev to initialize pdata. but just after that we
have a BUG_ON(!dev). so we were basically dereferencing the pointer
first and then tesing it for NULL.
Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org>
---
change in v2: suspend_flags is initialised after pdata is initialised.
v1 had a very silly but serious mistake of making pdata NULL, and trying
to dereference it.
sorry again for that.
drivers/net/usb/smsc95xx.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/usb/smsc95xx.c b/drivers/net/usb/smsc95xx.c
index d07bf4c..26423ad 100644
--- a/drivers/net/usb/smsc95xx.c
+++ b/drivers/net/usb/smsc95xx.c
@@ -1670,12 +1670,14 @@ done:
static int smsc95xx_resume(struct usb_interface *intf)
{
struct usbnet *dev = usb_get_intfdata(intf);
- struct smsc95xx_priv *pdata = (struct smsc95xx_priv *)(dev->data[0]);
- u8 suspend_flags = pdata->suspend_flags;
+ struct smsc95xx_priv *pdata;
+ u8 suspend_flags;
int ret;
u32 val;
BUG_ON(!dev);
+ pdata = (struct smsc95xx_priv *)(dev->data[0]);
+ suspend_flags = pdata->suspend_flags;
netdev_dbg(dev->net, "resume suspend_flags=0x%02x\n", suspend_flags);
--
1.8.1.2
^ permalink raw reply related
* Re: Face some error after applying commit 7dfa4b414d4(net/mlx4_en: Code cleanups in tx path)
From: Amir Vadai @ 2014-11-11 8:40 UTC (permalink / raw)
To: Wei Yang
Cc: Amir Vadai, Eric Dumazet, Eric Dumazet, David Miller, netdev,
gerlitz.or
In-Reply-To: <20141111074243.GA25321@richard>
On Tue, Nov 11, 2014 at 9:42 AM, Wei Yang <weiyang@linux.vnet.ibm.com> wrote:
> On Tue, Nov 11, 2014 at 09:28:34AM +0200, Amir Vadai wrote:
>>On Tue, Nov 11, 2014 at 3:57 AM, Wei Yang <weiyang@linux.vnet.ibm.com> wrote:
>>> On Mon, Nov 10, 2014 at 10:00:21AM +0200, Amir Vadai wrote:
>>>>On 11/10/2014 7:40 AM, Wei Yang wrote:
>>>>> On Sun, Nov 09, 2014 at 06:46:14PM -0800, Eric Dumazet wrote:
>>>>>> On Mon, 2014-11-10 at 09:59 +0800, Wei Yang wrote:
>>>>>>> On Fri, Nov 07, 2014 at 07:38:15PM -0800, Eric Dumazet wrote:
>>>>>>>> On Fri, Nov 7, 2014 at 6:57 PM, Wei Yang <weiyang@linux.vnet.ibm.com> wrote:
>>>>>>>>> Eric and Amir
>>>>>>>>>
>>>>
>>>>[...]
>>>>
>>>>>>>
>>>>>>
>>>>>> Okay, your message was not clear : I thought you had a compilation error
>>>>>> on current tree.
>>>>>>
>>>>>> The true story of these patches is that Mellanox split an initial big
>>>>>> chunk [1] I gave into multiple patches.
>>>>>>
>>>>>> Maybe they missed that one patch did not actually compile.
>>>>>>
>>>>>> [1] https://patchwork.ozlabs.org/patch/394256/
>>>>>>
>>>>>> Now, it is done, there is nothing we can do.
>>>>>>
>>>>>> I'll let Mellanox comment, but it looks like your hardware does not like
>>>>>> something.
>>>>>>
>>>>>> Have you tried to disable Blue Frame ?
>>>>>>
>>>>>
>>>>> Yep, looks the PF works fine. But the current FW I can't just enable the PF.
>>>>>
>>>>> How to disable Blue Frame? I am not clear about this.
>>>>>
>>>>Hi,
>>>>
>>>>Lets see that we're on the same page here:
>>>>1. There was a compilation problem that you fixed (Yes, it was my fault
>>>>- I just discovered it a minute after the code was applied).
>>>>2. When you're using SR-IOV, during initialization, you get a CQE error
>>>>with syndrome 0x2 on one of the probed VF's.
>>>
>>> From the log, seems yes.
>>>
>>>>3. Regarding the BlueFlame - I don't see how it is related to the issue
>>>>that you see. But it is a very easy experiment. Issue: "ethtool
>>>>--set-priv-flags eth1 blueflame off"
>>>
>>> I tried to use this after mlx4_en is loaded, still see the CQE error.
>>>
>>>>
>>>>Please send me the module parameters you used when loading mlx4_core, a
>>>>full dmesg with both mlx4_core and mlx4_en loading.
>>>
>>> The command line I use is:
>>> modprobe mlx4_core num_vfs=1 probe_vf=1 port_type_array=2,2
>>>
>>> The log I sent in the first mail is the full log, including the CQE error, one
>>> warning in watchdog, and then print the CQE error periodicly. What else
>>> message you would like me to capture?
>>
>>The log in the first mail has only mlx4_en logs. I would like to see
>>the full log, that has mlx4_core messages too. And as Or suggested,
>>debug_level=1 could be useful here too.
>>
>
> Ah, you need the log from mlx4_core too. Ok, I will do it again.
>
> BTW, how to add the debug_level=1 in the command line? Like this?
>
> modprobe mlx4_core num_vfs=1 probe_vf=1 port_type_array=2,2 debug_level=1
yes
>
> But for mlx4_en, I am not sure I could raise the debug level with ethtool,
> since the ethernet driver may not work properly. Actually I am not sure how to
> raise the level with ethtool. Could you give me an example?
# ethtool -s ens5f1d1 msglvl 0xffff
>
>>>
>>> And this error is reported from VF always. After the error, the other network
>>> interface seems can't function.
>>>
>>>>
>>>>Amir.
>>>
>>> --
>>> Richard Yang
>>> Help you, Help me
>>>
>>> --
>>> 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
>
> --
> Richard Yang
> Help you, Help me
>
> --
> 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 4/5] fm10k/igb/ixgbe: Replace __skb_alloc_page with netdev_alloc_page
From: Jeff Kirsher @ 2014-11-11 8:32 UTC (permalink / raw)
To: Alexander Duyck
Cc: netdev, linux-usb, leedom, hariprasad, donald.c.skidmore, oliver,
balbi, matthew.vick, mgorman, davem
In-Reply-To: <20141110195221.16182.16080.stgit@ahduyck-vm-fedora20>
[-- Attachment #1: Type: text/plain, Size: 1113 bytes --]
On Mon, 2014-11-10 at 11:52 -0800, Alexander Duyck wrote:
> The Intel drivers were pretty much just using the plain vanilla GFP
> flags
> in their calls to __skb_alloc_page so this change makes it so that
> they use
> netdev_alloc_page which just uses GFP_ATOMIC for the gfp_flags value.
>
> Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> Cc: Matthew Vick <matthew.vick@intel.com>
> Cc: Don Skidmore <donald.c.skidmore@intel.com>
> Signed-off-by: Alexander Duyck <alexander.h.duyck@redhat.com>
> ---
> drivers/net/ethernet/intel/fm10k/fm10k_main.c | 2 +-
> drivers/net/ethernet/intel/igb/igb_main.c | 2 +-
> drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 3 +--
> 3 files changed, 3 insertions(+), 4 deletions(-)
I know that this patch is dependent upon the changes in patch 01 of the
series, so I do not want to necessarily break up the series by having
Dave wait for us to test and ACK this patch internally. But I will add
your patch to my queue so that I can get what testing I can on these
changes.
FWIW...
Acked-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] net: s6gmac: remove driver
From: Paul Bolle @ 2014-11-11 8:32 UTC (permalink / raw)
To: David Miller; +Cc: Valentin Rothberg, jcmvbkbc, dg, netdev, linux-kernel
In-Reply-To: <20141019.132801.424495087167944921.davem@davemloft.net>
On Sun, 2014-10-19 at 13:28 -0400, David Miller wrote:
> From: Max Filippov <jcmvbkbc@gmail.com>
> Date: Sun, 19 Oct 2014 21:26:05 +0400
>
> > On Sun, Oct 19, 2014 at 8:45 PM, David Miller <davem@davemloft.net> wrote:
> >> From: Daniel Glöckner <dg@emlix.com>
> >> Date: Sun, 19 Oct 2014 00:49:05 +0200
> >>
> >>> The s6000 Xtensa support is removed from the kernel. There are no
> >>> other chips using this driver.
> >>
> >> That's not what I see in Linus's current tree:
> >
> > David, s6000 removal is queued for 3.18.
>
> Then there is zero reason for me to apply this to my networking
> tree.
Commit 4006e565e150 ("xtensa: remove s6000 variant and s6105 platform")
is included in linux-next as of next-20141111. So now we see:
$ git grep XTENSA_VARIANT_S6000 next-20141111
next-20141111:drivers/net/ethernet/Kconfig: depends on XTENSA_VARIANT_S6000
Should Daniel resubmit, for net-next, perhaps with a commit explanation
that references this commit?
Paul Bolle
^ permalink raw reply
* Re: [net-next PATCH] ixgbe: Remove IXGBE_FLAG_IN_NETPOLL since it doesn't do anything
From: Jeff Kirsher @ 2014-11-11 8:26 UTC (permalink / raw)
To: Alexander Duyck; +Cc: netdev, donald.c.skidmore, davem
In-Reply-To: <20141110224922.7245.35078.stgit@ahduyck-vm-fedora20>
[-- Attachment #1: Type: text/plain, Size: 759 bytes --]
On Mon, 2014-11-10 at 14:50 -0800, Alexander Duyck wrote:
> This patch removes some dead code from the cleanup path for ixgbe.
>
> Setting and clearing the flag doesn't do anything since all we are
> doing is
> setting the flag, scheduling napi, clearing the flag and then letting
> netpoll do the polling cleanup. As such it doesn't make much sense to
> have
> it there.
>
> This patch also removes one minor white-space error.
>
> Signed-off-by: Alexander Duyck <alexander.h.duyck@redhat.com>
> ---
> drivers/net/ethernet/intel/ixgbe/ixgbe.h | 1 -
> drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 16 ++++------------
> 2 files changed, 4 insertions(+), 13 deletions(-)
Thanks Alex, I have added your patch to my queue.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ 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