Netdev List
 help / color / mirror / Atom feed
* Re: [PATCH] VNIC: Adding support for Cavium ThunderX network controller
From: Stephen Hemminger @ 2014-11-03 18:16 UTC (permalink / raw)
  To: Sunil Kovvuri
  Cc: Robert Richter, David S. Miller, Sunil Goutham, Robert Richter,
	Stefan Assmann, LKML, LAKML, netdev
In-Reply-To: <CA+sq2CfV-90CRvo-FCizkzoxHq-AsfOEDW2Z5pXtnNLNXCfTUg@mail.gmail.com>

On Fri, 31 Oct 2014 22:44:11 +0530
Sunil Kovvuri <sunil.kovvuri@gmail.com> wrote:

> On Fri, Oct 31, 2014 at 8:24 AM, Stephen Hemminger
> <stephen@networkplumber.org> wrote:
> > On Thu, 30 Oct 2014 17:54:34 +0100
> > Robert Richter <rric@kernel.org> wrote:
> >
> >> +#ifdef       VNIC_RSS_SUPPORT
> >> +static int rss_config = RSS_IP_HASH_ENA | RSS_TCP_HASH_ENA | RSS_UDP_HASH_ENA;
> >> +module_param(rss_config, int, S_IRUGO);
> >> +MODULE_PARM_DESC(rss_config,
> >> +              "RSS hash config [bits 8:0] (Bit0:L2 extended, 1:IP, 2:TCP, 3:TCP SYN, 4:UDP, 5:L4 extended, 6:ROCE 7:L3 bi-directional, 8:L4 bi-directional)");
> >> +#endif
> >
> > This should managed  be via ethtool ETHTOOL_GRXFH rather than a module parameter.
> Thanks, i will add setting hash options via ETHTOOL_SRXFH as well.
> The idea here is to have a choice of hash while module load (through
> module params) and if it needs to be changed runtime then
> via Ethtool.
> 
> Sunil.

Network developers do not like vendor unique module parameters.
Anything device specific doesn't work in a generic distro environment.

^ permalink raw reply

* [Patch net-next v2] neigh: remove dynamic neigh table registration support
From: Cong Wang @ 2014-11-03 18:14 UTC (permalink / raw)
  To: netdev; +Cc: David S. Miller, Cong Wang

Currently there are only three neigh tables in the whole kernel:
arp table, ndisc table and decnet neigh table. What's more,
we don't support registering multiple tables per family.
Therefore we can just make these tables statically built-in.

Cc: David S. Miller <davem@davemloft.net>
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
---
v2: remove useless #ifdef's
    move the assignment to the end of neigh_table_init()

 include/net/neighbour.h |   9 +-
 net/core/neighbour.c    | 244 ++++++++++++++++++++++--------------------------
 net/decnet/dn_neigh.c   |   2 +-
 net/ipv4/arp.c          |   2 +-
 net/ipv6/ndisc.c        |   2 +-
 5 files changed, 121 insertions(+), 138 deletions(-)

diff --git a/include/net/neighbour.h b/include/net/neighbour.h
index dedfb18..1e65c68 100644
--- a/include/net/neighbour.h
+++ b/include/net/neighbour.h
@@ -220,6 +220,13 @@ struct neigh_table {
 	struct pneigh_entry	**phash_buckets;
 };
 
+enum {
+	NEIGH_ARP_TABLE = 0,
+	NEIGH_ND_TABLE = 1,
+	NEIGH_DN_TABLE = 2,
+	NEIGH_NR_TABLES,
+};
+
 static inline int neigh_parms_family(struct neigh_parms *p)
 {
 	return p->tbl->family;
@@ -240,7 +247,7 @@ static inline void *neighbour_priv(const struct neighbour *n)
 #define NEIGH_UPDATE_F_ISROUTER			0x40000000
 #define NEIGH_UPDATE_F_ADMIN			0x80000000
 
-void neigh_table_init(struct neigh_table *tbl);
+void neigh_table_init(int index, struct neigh_table *tbl);
 int neigh_table_clear(struct neigh_table *tbl);
 struct neighbour *neigh_lookup(struct neigh_table *tbl, const void *pkey,
 			       struct net_device *dev);
diff --git a/net/core/neighbour.c b/net/core/neighbour.c
index edd0411..55b7e0b 100644
--- a/net/core/neighbour.c
+++ b/net/core/neighbour.c
@@ -56,7 +56,6 @@ static void __neigh_notify(struct neighbour *n, int type, int flags);
 static void neigh_update_notify(struct neighbour *neigh);
 static int pneigh_ifdown(struct neigh_table *tbl, struct net_device *dev);
 
-static struct neigh_table *neigh_tables;
 #ifdef CONFIG_PROC_FS
 static const struct file_operations neigh_stat_seq_fops;
 #endif
@@ -87,13 +86,8 @@ static const struct file_operations neigh_stat_seq_fops;
    the most complicated procedure, which we allow is dev->hard_header.
    It is supposed, that dev->hard_header is simplistic and does
    not make callbacks to neighbour tables.
-
-   The last lock is neigh_tbl_lock. It is pure SMP lock, protecting
-   list of neighbour tables. This list is used only in process context,
  */
 
-static DEFINE_RWLOCK(neigh_tbl_lock);
-
 static int neigh_blackhole(struct neighbour *neigh, struct sk_buff *skb)
 {
 	kfree_skb(skb);
@@ -1520,7 +1514,9 @@ static void neigh_parms_destroy(struct neigh_parms *parms)
 
 static struct lock_class_key neigh_table_proxy_queue_class;
 
-static void neigh_table_init_no_netlink(struct neigh_table *tbl)
+static struct neigh_table *neigh_tables[NEIGH_NR_TABLES] __read_mostly;
+
+void neigh_table_init(int index, struct neigh_table *tbl)
 {
 	unsigned long now = jiffies;
 	unsigned long phsize;
@@ -1566,34 +1562,13 @@ static void neigh_table_init_no_netlink(struct neigh_table *tbl)
 
 	tbl->last_flush = now;
 	tbl->last_rand	= now + tbl->parms.reachable_time * 20;
-}
-
-void neigh_table_init(struct neigh_table *tbl)
-{
-	struct neigh_table *tmp;
 
-	neigh_table_init_no_netlink(tbl);
-	write_lock(&neigh_tbl_lock);
-	for (tmp = neigh_tables; tmp; tmp = tmp->next) {
-		if (tmp->family == tbl->family)
-			break;
-	}
-	tbl->next	= neigh_tables;
-	neigh_tables	= tbl;
-	write_unlock(&neigh_tbl_lock);
-
-	if (unlikely(tmp)) {
-		pr_err("Registering multiple tables for family %d\n",
-		       tbl->family);
-		dump_stack();
-	}
+	neigh_tables[index] = tbl;
 }
 EXPORT_SYMBOL(neigh_table_init);
 
 int neigh_table_clear(struct neigh_table *tbl)
 {
-	struct neigh_table **tp;
-
 	/* It is not clean... Fix it to unload IPv6 module safely */
 	cancel_delayed_work_sync(&tbl->gc_work);
 	del_timer_sync(&tbl->proxy_timer);
@@ -1601,14 +1576,6 @@ int neigh_table_clear(struct neigh_table *tbl)
 	neigh_ifdown(tbl, NULL);
 	if (atomic_read(&tbl->entries))
 		pr_crit("neighbour leakage\n");
-	write_lock(&neigh_tbl_lock);
-	for (tp = &neigh_tables; *tp; tp = &(*tp)->next) {
-		if (*tp == tbl) {
-			*tp = tbl->next;
-			break;
-		}
-	}
-	write_unlock(&neigh_tbl_lock);
 
 	call_rcu(&rcu_dereference_protected(tbl->nht, 1)->rcu,
 		 neigh_hash_free_rcu);
@@ -1626,12 +1593,32 @@ int neigh_table_clear(struct neigh_table *tbl)
 }
 EXPORT_SYMBOL(neigh_table_clear);
 
+static struct neigh_table *neigh_find_table(int family)
+{
+	struct neigh_table *tbl = NULL;
+
+	switch (family) {
+	case AF_INET:
+		tbl = neigh_tables[NEIGH_ARP_TABLE];
+		break;
+	case AF_INET6:
+		tbl = neigh_tables[NEIGH_ND_TABLE];
+		break;
+	case AF_DECnet:
+		tbl = neigh_tables[NEIGH_DN_TABLE];
+		break;
+	}
+
+	return tbl;
+}
+
 static int neigh_delete(struct sk_buff *skb, struct nlmsghdr *nlh)
 {
 	struct net *net = sock_net(skb->sk);
 	struct ndmsg *ndm;
 	struct nlattr *dst_attr;
 	struct neigh_table *tbl;
+	struct neighbour *neigh;
 	struct net_device *dev = NULL;
 	int err = -EINVAL;
 
@@ -1652,39 +1639,31 @@ static int neigh_delete(struct sk_buff *skb, struct nlmsghdr *nlh)
 		}
 	}
 
-	read_lock(&neigh_tbl_lock);
-	for (tbl = neigh_tables; tbl; tbl = tbl->next) {
-		struct neighbour *neigh;
-
-		if (tbl->family != ndm->ndm_family)
-			continue;
-		read_unlock(&neigh_tbl_lock);
-
-		if (nla_len(dst_attr) < tbl->key_len)
-			goto out;
+	tbl = neigh_find_table(ndm->ndm_family);
+	if (tbl == NULL)
+		return -EAFNOSUPPORT;
 
-		if (ndm->ndm_flags & NTF_PROXY) {
-			err = pneigh_delete(tbl, net, nla_data(dst_attr), dev);
-			goto out;
-		}
+	if (nla_len(dst_attr) < tbl->key_len)
+		goto out;
 
-		if (dev == NULL)
-			goto out;
+	if (ndm->ndm_flags & NTF_PROXY) {
+		err = pneigh_delete(tbl, net, nla_data(dst_attr), dev);
+		goto out;
+	}
 
-		neigh = neigh_lookup(tbl, nla_data(dst_attr), dev);
-		if (neigh == NULL) {
-			err = -ENOENT;
-			goto out;
-		}
+	if (dev == NULL)
+		goto out;
 
-		err = neigh_update(neigh, NULL, NUD_FAILED,
-				   NEIGH_UPDATE_F_OVERRIDE |
-				   NEIGH_UPDATE_F_ADMIN);
-		neigh_release(neigh);
+	neigh = neigh_lookup(tbl, nla_data(dst_attr), dev);
+	if (neigh == NULL) {
+		err = -ENOENT;
 		goto out;
 	}
-	read_unlock(&neigh_tbl_lock);
-	err = -EAFNOSUPPORT;
+
+	err = neigh_update(neigh, NULL, NUD_FAILED,
+			   NEIGH_UPDATE_F_OVERRIDE |
+			   NEIGH_UPDATE_F_ADMIN);
+	neigh_release(neigh);
 
 out:
 	return err;
@@ -1692,11 +1671,14 @@ static int neigh_delete(struct sk_buff *skb, struct nlmsghdr *nlh)
 
 static int neigh_add(struct sk_buff *skb, struct nlmsghdr *nlh)
 {
+	int flags = NEIGH_UPDATE_F_ADMIN | NEIGH_UPDATE_F_OVERRIDE;
 	struct net *net = sock_net(skb->sk);
 	struct ndmsg *ndm;
 	struct nlattr *tb[NDA_MAX+1];
 	struct neigh_table *tbl;
 	struct net_device *dev = NULL;
+	struct neighbour *neigh;
+	void *dst, *lladdr;
 	int err;
 
 	ASSERT_RTNL();
@@ -1720,70 +1702,60 @@ static int neigh_add(struct sk_buff *skb, struct nlmsghdr *nlh)
 			goto out;
 	}
 
-	read_lock(&neigh_tbl_lock);
-	for (tbl = neigh_tables; tbl; tbl = tbl->next) {
-		int flags = NEIGH_UPDATE_F_ADMIN | NEIGH_UPDATE_F_OVERRIDE;
-		struct neighbour *neigh;
-		void *dst, *lladdr;
+	tbl = neigh_find_table(ndm->ndm_family);
+	if (tbl == NULL)
+		return -EAFNOSUPPORT;
 
-		if (tbl->family != ndm->ndm_family)
-			continue;
-		read_unlock(&neigh_tbl_lock);
+	if (nla_len(tb[NDA_DST]) < tbl->key_len)
+		goto out;
+	dst = nla_data(tb[NDA_DST]);
+	lladdr = tb[NDA_LLADDR] ? nla_data(tb[NDA_LLADDR]) : NULL;
 
-		if (nla_len(tb[NDA_DST]) < tbl->key_len)
-			goto out;
-		dst = nla_data(tb[NDA_DST]);
-		lladdr = tb[NDA_LLADDR] ? nla_data(tb[NDA_LLADDR]) : NULL;
+	if (ndm->ndm_flags & NTF_PROXY) {
+		struct pneigh_entry *pn;
+
+		err = -ENOBUFS;
+		pn = pneigh_lookup(tbl, net, dst, dev, 1);
+		if (pn) {
+			pn->flags = ndm->ndm_flags;
+			err = 0;
+		}
+		goto out;
+	}
 
-		if (ndm->ndm_flags & NTF_PROXY) {
-			struct pneigh_entry *pn;
+	if (dev == NULL)
+		goto out;
 
-			err = -ENOBUFS;
-			pn = pneigh_lookup(tbl, net, dst, dev, 1);
-			if (pn) {
-				pn->flags = ndm->ndm_flags;
-				err = 0;
-			}
+	neigh = neigh_lookup(tbl, dst, dev);
+	if (neigh == NULL) {
+		if (!(nlh->nlmsg_flags & NLM_F_CREATE)) {
+			err = -ENOENT;
 			goto out;
 		}
 
-		if (dev == NULL)
+		neigh = __neigh_lookup_errno(tbl, dst, dev);
+		if (IS_ERR(neigh)) {
+			err = PTR_ERR(neigh);
+			goto out;
+		}
+	} else {
+		if (nlh->nlmsg_flags & NLM_F_EXCL) {
+			err = -EEXIST;
+			neigh_release(neigh);
 			goto out;
-
-		neigh = neigh_lookup(tbl, dst, dev);
-		if (neigh == NULL) {
-			if (!(nlh->nlmsg_flags & NLM_F_CREATE)) {
-				err = -ENOENT;
-				goto out;
-			}
-
-			neigh = __neigh_lookup_errno(tbl, dst, dev);
-			if (IS_ERR(neigh)) {
-				err = PTR_ERR(neigh);
-				goto out;
-			}
-		} else {
-			if (nlh->nlmsg_flags & NLM_F_EXCL) {
-				err = -EEXIST;
-				neigh_release(neigh);
-				goto out;
-			}
-
-			if (!(nlh->nlmsg_flags & NLM_F_REPLACE))
-				flags &= ~NEIGH_UPDATE_F_OVERRIDE;
 		}
 
-		if (ndm->ndm_flags & NTF_USE) {
-			neigh_event_send(neigh, NULL);
-			err = 0;
-		} else
-			err = neigh_update(neigh, lladdr, ndm->ndm_state, flags);
-		neigh_release(neigh);
-		goto out;
+		if (!(nlh->nlmsg_flags & NLM_F_REPLACE))
+			flags &= ~NEIGH_UPDATE_F_OVERRIDE;
 	}
 
-	read_unlock(&neigh_tbl_lock);
-	err = -EAFNOSUPPORT;
+	if (ndm->ndm_flags & NTF_USE) {
+		neigh_event_send(neigh, NULL);
+		err = 0;
+	} else
+		err = neigh_update(neigh, lladdr, ndm->ndm_state, flags);
+	neigh_release(neigh);
+
 out:
 	return err;
 }
@@ -1982,7 +1954,8 @@ static int neightbl_set(struct sk_buff *skb, struct nlmsghdr *nlh)
 	struct neigh_table *tbl;
 	struct ndtmsg *ndtmsg;
 	struct nlattr *tb[NDTA_MAX+1];
-	int err;
+	bool found = false;
+	int err, tidx;
 
 	err = nlmsg_parse(nlh, sizeof(*ndtmsg), tb, NDTA_MAX,
 			  nl_neightbl_policy);
@@ -1995,19 +1968,21 @@ static int neightbl_set(struct sk_buff *skb, struct nlmsghdr *nlh)
 	}
 
 	ndtmsg = nlmsg_data(nlh);
-	read_lock(&neigh_tbl_lock);
-	for (tbl = neigh_tables; tbl; tbl = tbl->next) {
+
+	for (tidx = 0; tidx < NEIGH_NR_TABLES; tidx++) {
+		tbl = neigh_tables[tidx];
+		if (!tbl)
+			continue;
 		if (ndtmsg->ndtm_family && tbl->family != ndtmsg->ndtm_family)
 			continue;
-
-		if (nla_strcmp(tb[NDTA_NAME], tbl->id) == 0)
+		if (nla_strcmp(tb[NDTA_NAME], tbl->id) == 0) {
+			found = true;
 			break;
+		}
 	}
 
-	if (tbl == NULL) {
-		err = -ENOENT;
-		goto errout_locked;
-	}
+	if (!found)
+		return -ENOENT;
 
 	/*
 	 * We acquire tbl->lock to be nice to the periodic timers and
@@ -2118,8 +2093,6 @@ static int neightbl_set(struct sk_buff *skb, struct nlmsghdr *nlh)
 
 errout_tbl_lock:
 	write_unlock_bh(&tbl->lock);
-errout_locked:
-	read_unlock(&neigh_tbl_lock);
 errout:
 	return err;
 }
@@ -2134,10 +2107,13 @@ static int neightbl_dump_info(struct sk_buff *skb, struct netlink_callback *cb)
 
 	family = ((struct rtgenmsg *) nlmsg_data(cb->nlh))->rtgen_family;
 
-	read_lock(&neigh_tbl_lock);
-	for (tbl = neigh_tables, tidx = 0; tbl; tbl = tbl->next, tidx++) {
+	for (tidx = 0; tidx < NEIGH_NR_TABLES; tidx++) {
 		struct neigh_parms *p;
 
+		tbl = neigh_tables[tidx];
+		if (!tbl)
+			continue;
+
 		if (tidx < tbl_skip || (family && tbl->family != family))
 			continue;
 
@@ -2168,7 +2144,6 @@ static int neightbl_dump_info(struct sk_buff *skb, struct netlink_callback *cb)
 		neigh_skip = 0;
 	}
 out:
-	read_unlock(&neigh_tbl_lock);
 	cb->args[0] = tidx;
 	cb->args[1] = nidx;
 
@@ -2351,7 +2326,6 @@ static int neigh_dump_info(struct sk_buff *skb, struct netlink_callback *cb)
 	int proxy = 0;
 	int err;
 
-	read_lock(&neigh_tbl_lock);
 	family = ((struct rtgenmsg *) nlmsg_data(cb->nlh))->rtgen_family;
 
 	/* check for full ndmsg structure presence, family member is
@@ -2363,8 +2337,11 @@ static int neigh_dump_info(struct sk_buff *skb, struct netlink_callback *cb)
 
 	s_t = cb->args[0];
 
-	for (tbl = neigh_tables, t = 0; tbl;
-	     tbl = tbl->next, t++) {
+	for (t = 0; t < NEIGH_NR_TABLES; t++) {
+		tbl = neigh_tables[t];
+
+		if (!tbl)
+			continue;
 		if (t < s_t || (family && tbl->family != family))
 			continue;
 		if (t > s_t)
@@ -2377,7 +2354,6 @@ static int neigh_dump_info(struct sk_buff *skb, struct netlink_callback *cb)
 		if (err < 0)
 			break;
 	}
-	read_unlock(&neigh_tbl_lock);
 
 	cb->args[0] = t;
 	return skb->len;
diff --git a/net/decnet/dn_neigh.c b/net/decnet/dn_neigh.c
index c8121ce..845957a 100644
--- a/net/decnet/dn_neigh.c
+++ b/net/decnet/dn_neigh.c
@@ -591,7 +591,7 @@ static const struct file_operations dn_neigh_seq_fops = {
 
 void __init dn_neigh_init(void)
 {
-	neigh_table_init(&dn_neigh_table);
+	neigh_table_init(NEIGH_DN_TABLE, &dn_neigh_table);
 	proc_create("decnet_neigh", S_IRUGO, init_net.proc_net,
 		    &dn_neigh_seq_fops);
 }
diff --git a/net/ipv4/arp.c b/net/ipv4/arp.c
index 16acb59..205e147 100644
--- a/net/ipv4/arp.c
+++ b/net/ipv4/arp.c
@@ -1292,7 +1292,7 @@ static int arp_proc_init(void);
 
 void __init arp_init(void)
 {
-	neigh_table_init(&arp_tbl);
+	neigh_table_init(NEIGH_ARP_TABLE, &arp_tbl);
 
 	dev_add_pack(&arp_packet_type);
 	arp_proc_init();
diff --git a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c
index 4cb45c1..c67f339 100644
--- a/net/ipv6/ndisc.c
+++ b/net/ipv6/ndisc.c
@@ -1763,7 +1763,7 @@ int __init ndisc_init(void)
 	/*
 	 * Initialize the neighbour table
 	 */
-	neigh_table_init(&nd_tbl);
+	neigh_table_init(NEIGH_ND_TABLE, &nd_tbl);
 
 #ifdef CONFIG_SYSCTL
 	err = neigh_sysctl_register(NULL, &nd_tbl.parms,

^ permalink raw reply related

* Re: [PATCH] stmmac: remove custom implementation of print_hex_dump()
From: Joe Perches @ 2014-11-03 18:11 UTC (permalink / raw)
  To: Andy Shevchenko
  Cc: Giuseppe Cavallaro, netdev, Kweh Hock Leong, David S . Miller,
	Vince Bridgers
In-Reply-To: <1415037237.472.1.camel@linux.intel.com>

On Mon, 2014-11-03 at 19:53 +0200, Andy Shevchenko wrote:
> On Mon, 2014-11-03 at 09:39 -0800, Joe Perches wrote:
> > On Mon, 2014-11-03 at 19:28 +0200, Andy Shevchenko wrote:
> > > There is a kernel helper to dump buffers in a hexdecimal format. This patch
> > > substitutes the open coded function by calling that helper.
> > []
> > > diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> > []
> > > @@ -191,14 +191,8 @@ static void stmmac_clk_csr_set(struct stmmac_priv *priv)
> > >  
> > >  static void print_pkt(unsigned char *buf, int len)
> > >  {
> > > -	int j;
> > > -	pr_debug("len = %d byte, buf addr: 0x%p", len, buf);
> > > -	for (j = 0; j < len; j++) {
> > > -		if ((j % 16) == 0)
> > > -			pr_debug("\n %03x:", j);
> > > -		pr_debug(" %02x", buf[j]);
> > > -	}
> > > -	pr_debug("\n");
> > > +	pr_debug("len = %d byte, buf addr: 0x%p\n", len, buf);
> > > +	print_hex_dump(KERN_DEBUG, " ", DUMP_PREFIX_OFFSET, 16, 1, buf, len, 0);
> > 
> > Prefix should be ""
> 
> Oh, initially there is an indentation in one space.
> Maybe Giuseppe would comment on this.

I think that's not particularly important.

This changes the output anyway as the the printed offset
is now 8 chars wide not 3.

> > Another (better?) option would be to use:
> > 
> > 	print_hex_dump_bytes("", DUMP_PREFIX_OFFSET, buf, len);
> 
> > so that it can be dynamically controlled like
> > the pr_debug statements.
> 
> Ah, yes, but unfortunately it will print ASCII part always. Giuseppe,
> what do you think?

I'm not bothered by logging message output changes.
It's not a guaranteed stable output.

> P.S. [off topic] Joe, just would like to know if you have you seen my
> last version of the patch series against hexdump.c which adds
> seq_hex_dump() call [1]. If so, could you comment on it?
> [1] https://lkml.org/lkml/2014/9/4/309

seq_<foo> output however is guaranteed.

So any conversion to the seq_hex_dump function
would need to be exactly the same.

New code could use seq_hex_dump.

Other than that, it seems sensible enough.

^ permalink raw reply

* Re: [PATCHv1 net-next] xen-netback: remove unconditional pull_skb_tail in guest Tx path
From: Ian Campbell @ 2014-11-03 17:55 UTC (permalink / raw)
  To: David Vrabel; +Cc: netdev, xen-devel, Wei Liu, Malcolm Crossley
In-Reply-To: <5457BF80.2000205@citrix.com>

On Mon, 2014-11-03 at 17:46 +0000, David Vrabel wrote:
> On 03/11/14 17:39, Ian Campbell wrote:
> > On Mon, 2014-11-03 at 17:23 +0000, David Vrabel wrote:
> >> From: Malcolm Crossley <malcolm.crossley@citrix.com>
> >>
> >> Unconditionally pulling 128 bytes into the linear buffer is not
> >> required. Netback has already grant copied up-to 128 bytes from the
> >> first slot of a packet into the linear buffer. The first slot normally
> >> contain all the IPv4/IPv6 and TCP/UDP headers.
> > 
> > What about when it doesn't? It sounds as if we now won't pull up, which
> > would be bad.
> 
> The network stack will always pull any headers it needs to inspect (the
> frag may be a userspace page which has the same security issues as a
> frag with a foreign page).

I don't believe it will, unless something changed since I last looked.
The kernel assumes that it has been sensible enough to put the headers
in the linear area, since it is the one which generates them in most
cases. In other cases its up to the relevant driver to make sure this is
true.

> e.g., see skb_checksum_setup() called slightly later on in netback.

This however is what will make things safe for us (note that this is
only used by xen-net* in practice), it is this which should be mentioned
in the commit message I think.

> > To avoid the pull up the code would need to grant copy up-to 128 bytes
> > from as many slots as needed, not only the first.
> > 
> > Also, if the grant copy has already placed 128 bytes in the linear area,
> > why is the pull up touching anything in the first place? Shouldn't it be
> > a nop in that case?
> 
> The grant copy only copies from the first frag which may be less than
> 128 bytes in length.
> 
> David

^ permalink raw reply

* Re: [PATCH] PPC: bpf_jit_comp: add SKF_AD_PKTTYPE instruction
From: Denis Kirjanov @ 2014-11-03 18:04 UTC (permalink / raw)
  To: Philippe Bergheaud; +Cc: linuxppc-dev, netdev, Matt Evans, mpe
In-Reply-To: <5457A306.4040302@linux.vnet.ibm.com>

On 11/3/14, Philippe Bergheaud <felix@linux.vnet.ibm.com> wrote:
> Denis Kirjanov wrote:
>> Any feedback from PPC folks?
>
> I have reviewed the patch and it looks fine to me.
> I have tested successfuly on ppc64le.
> I could not test it on ppc64.

Nice, I've tested it on PPC64be
>
> Philippe
>
>> On 10/26/14, Denis Kirjanov <kda@linux-powerpc.org> wrote:
>>
>>>Cc: Matt Evans <matt@ozlabs.org>
>>>Signed-off-by: Denis Kirjanov <kda@linux-powerpc.org>
>>>---
>>> arch/powerpc/include/asm/ppc-opcode.h | 1 +
>>> arch/powerpc/net/bpf_jit.h            | 7 +++++++
>>> arch/powerpc/net/bpf_jit_comp.c       | 5 +++++
>>> 3 files changed, 13 insertions(+)
>>>
>>>diff --git a/arch/powerpc/include/asm/ppc-opcode.h
>>>b/arch/powerpc/include/asm/ppc-opcode.h
>>>index 6f85362..1a52877 100644
>>>--- a/arch/powerpc/include/asm/ppc-opcode.h
>>>+++ b/arch/powerpc/include/asm/ppc-opcode.h
>>>@@ -204,6 +204,7 @@
>>> #define PPC_INST_ERATSX_DOT		0x7c000127
>>>
>>> /* Misc instructions for BPF compiler */
>>>+#define PPC_INST_LBZ			0x88000000
>>> #define PPC_INST_LD			0xe8000000
>>> #define PPC_INST_LHZ			0xa0000000
>>> #define PPC_INST_LHBRX			0x7c00062c
>>>diff --git a/arch/powerpc/net/bpf_jit.h b/arch/powerpc/net/bpf_jit.h
>>>index 9aee27c..c406aa9 100644
>>>--- a/arch/powerpc/net/bpf_jit.h
>>>+++ b/arch/powerpc/net/bpf_jit.h
>>>@@ -87,6 +87,9 @@ DECLARE_LOAD_FUNC(sk_load_byte_msh);
>>> #define PPC_STD(r, base, i)	EMIT(PPC_INST_STD | ___PPC_RS(r) |	      \
>>> 				     ___PPC_RA(base) | ((i) & 0xfffc))
>>>
>>>+
>>>+#define PPC_LBZ(r, base, i)	EMIT(PPC_INST_LBZ | ___PPC_RT(r) |	      \
>>>+				     ___PPC_RA(base) | IMM_L(i))
>>> #define PPC_LD(r, base, i)	EMIT(PPC_INST_LD | ___PPC_RT(r) |	      \
>>> 				     ___PPC_RA(base) | IMM_L(i))
>>> #define PPC_LWZ(r, base, i)	EMIT(PPC_INST_LWZ | ___PPC_RT(r) |	      \
>>>@@ -96,6 +99,10 @@ DECLARE_LOAD_FUNC(sk_load_byte_msh);
>>> #define PPC_LHBRX(r, base, b)	EMIT(PPC_INST_LHBRX | ___PPC_RT(r) |	
>>> \
>>> 				     ___PPC_RA(base) | ___PPC_RB(b))
>>> /* Convenience helpers for the above with 'far' offsets: */
>>>+#define PPC_LBZ_OFFS(r, base, i) do { if ((i) < 32768) PPC_LBZ(r, base,
>>> i);
>>>  \
>>>+		else {	PPC_ADDIS(r, base, IMM_HA(i));			      \
>>>+			PPC_LBZ(r, r, IMM_L(i)); } } while(0)
>>>+
>>> #define PPC_LD_OFFS(r, base, i) do { if ((i) < 32768) PPC_LD(r, base,
>>> i);
>>>  \
>>> 		else {	PPC_ADDIS(r, base, IMM_HA(i));			      \
>>> 			PPC_LD(r, r, IMM_L(i)); } } while(0)
>>>diff --git a/arch/powerpc/net/bpf_jit_comp.c
>>>b/arch/powerpc/net/bpf_jit_comp.c
>>>index cbae2df..d110e28 100644
>>>--- a/arch/powerpc/net/bpf_jit_comp.c
>>>+++ b/arch/powerpc/net/bpf_jit_comp.c
>>>@@ -407,6 +407,11 @@ static int bpf_jit_build_body(struct bpf_prog *fp,
>>> u32
>>>*image,
>>> 			PPC_LHZ_OFFS(r_A, r_skb, offsetof(struct sk_buff,
>>> 							  queue_mapping));
>>> 			break;
>>>+		case BPF_ANC | SKF_AD_PKTTYPE:
>>>+			PPC_LBZ_OFFS(r_A, r_skb, PKT_TYPE_OFFSET());
>>>+			PPC_ANDI(r_A, r_A, PKT_TYPE_MAX);
>>>+			PPC_SRWI(r_A, r_A, 5);
>>>+			break;
>>> 		case BPF_ANC | SKF_AD_CPU:
>>> #ifdef CONFIG_SMP
>>> 			/*
>>>--
>>>2.1.0
>>>
>>>
>>
>> _______________________________________________
>> Linuxppc-dev mailing list
>> Linuxppc-dev@lists.ozlabs.org
>> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
>

^ permalink raw reply

* Re: [PATCHv1 net-next] xen-netback: remove unconditional pull_skb_tail in guest Tx path
From: Ian Campbell @ 2014-11-03 17:39 UTC (permalink / raw)
  To: David Vrabel; +Cc: netdev, xen-devel, Wei Liu, Malcolm Crossley
In-Reply-To: <1415035431-27485-1-git-send-email-david.vrabel@citrix.com>

On Mon, 2014-11-03 at 17:23 +0000, David Vrabel wrote:
> From: Malcolm Crossley <malcolm.crossley@citrix.com>
> 
> Unconditionally pulling 128 bytes into the linear buffer is not
> required. Netback has already grant copied up-to 128 bytes from the
> first slot of a packet into the linear buffer. The first slot normally
> contain all the IPv4/IPv6 and TCP/UDP headers.

What about when it doesn't? It sounds as if we now won't pull up, which
would be bad.

To avoid the pull up the code would need to grant copy up-to 128 bytes
from as many slots as needed, not only the first.

Also, if the grant copy has already placed 128 bytes in the linear area,
why is the pull up touching anything in the first place? Shouldn't it be
a nop in that case?

> The unconditional pull would often copy frag data unnecessarily.  This
> is a performance problem when running on a version of Xen where grant
> unmap avoids TLB flushes for pages which are not accessed.  TLB
> flushes can now be avoided for > 99% of unmaps (it was 0% before).
> 
> Grant unmap TLB flush avoidance will be available in a future version
> of Xen (probably 4.6).
> 
> Signed-off-by: Malcolm Crossley <malcolm.crossley@citrix.com>
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> ---
>  drivers/net/xen-netback/netback.c |   26 ++++++++++++--------------
>  1 file changed, 12 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
> index 730252c..14e18bb 100644
> --- a/drivers/net/xen-netback/netback.c
> +++ b/drivers/net/xen-netback/netback.c
> @@ -82,6 +82,16 @@ MODULE_PARM_DESC(max_queues,
>  static unsigned int fatal_skb_slots = FATAL_SKB_SLOTS_DEFAULT;
>  module_param(fatal_skb_slots, uint, 0444);
>  
> +/* The amount to copy out of the first guest Tx slot into the skb's
> + * linear area.  If the first slot has more data, it will be mapped
> + * and put into the first frag.
> + *
> + * This is sized to avoid pulling headers from the frags for most
> + * TCP/IP packets.
> + */
> +#define XEN_NETBACK_TX_COPY_LEN 128

Was it strictly necessary to both move and rename this? I can see why
the comment needed to change.

>  static void xenvif_idx_release(struct xenvif_queue *queue, u16 pending_idx,
>  			       u8 status);
>  
> @@ -125,13 +135,6 @@ static inline struct xenvif_queue *ubuf_to_queue(const struct ubuf_info *ubuf)
>  			    pending_tx_info[0]);
>  }
>  
> -/* This is a miniumum size for the linear area to avoid lots of
> - * calls to __pskb_pull_tail() as we set up checksum offsets. The
> - * value 128 was chosen as it covers all IPv4 and most likely
> - * IPv6 headers.
> - */
> -#define PKT_PROT_LEN 128
> -
>  static u16 frag_get_pending_idx(skb_frag_t *frag)
>  {
>  	return (u16)frag->page_offset;
> @@ -1446,9 +1449,9 @@ static void xenvif_tx_build_gops(struct xenvif_queue *queue,
>  		index = pending_index(queue->pending_cons);
>  		pending_idx = queue->pending_ring[index];
>  
> -		data_len = (txreq.size > PKT_PROT_LEN &&
> +		data_len = (txreq.size > XEN_NETBACK_TX_COPY_LEN &&
>  			    ret < XEN_NETBK_LEGACY_SLOTS_MAX) ?
> -			PKT_PROT_LEN : txreq.size;
> +			XEN_NETBACK_TX_COPY_LEN : txreq.size;
>  
>  		skb = xenvif_alloc_skb(data_len);
>  		if (unlikely(skb == NULL)) {
> @@ -1653,11 +1656,6 @@ static int xenvif_tx_submit(struct xenvif_queue *queue)
>  			}
>  		}
>  
> -		if (skb_is_nonlinear(skb) && skb_headlen(skb) < PKT_PROT_LEN) {
> -			int target = min_t(int, skb->len, PKT_PROT_LEN);
> -			__pskb_pull_tail(skb, target - skb_headlen(skb));
> -		}
> -
>  		skb->dev      = queue->vif->dev;
>  		skb->protocol = eth_type_trans(skb, skb->dev);
>  		skb_reset_network_header(skb);

^ permalink raw reply

* Re: [PATCH] stmmac: remove custom implementation of print_hex_dump()
From: Andy Shevchenko @ 2014-11-03 17:53 UTC (permalink / raw)
  To: Joe Perches
  Cc: Giuseppe Cavallaro, netdev, Kweh Hock Leong, David S . Miller,
	Vince Bridgers
In-Reply-To: <1415036355.17743.22.camel@perches.com>

On Mon, 2014-11-03 at 09:39 -0800, Joe Perches wrote:
> On Mon, 2014-11-03 at 19:28 +0200, Andy Shevchenko wrote:
> > There is a kernel helper to dump buffers in a hexdecimal format. This patch
> > substitutes the open coded function by calling that helper.
> []
> > diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> []
> > @@ -191,14 +191,8 @@ static void stmmac_clk_csr_set(struct stmmac_priv *priv)
> >  
> >  static void print_pkt(unsigned char *buf, int len)
> >  {
> > -	int j;
> > -	pr_debug("len = %d byte, buf addr: 0x%p", len, buf);
> > -	for (j = 0; j < len; j++) {
> > -		if ((j % 16) == 0)
> > -			pr_debug("\n %03x:", j);
> > -		pr_debug(" %02x", buf[j]);
> > -	}
> > -	pr_debug("\n");
> > +	pr_debug("len = %d byte, buf addr: 0x%p\n", len, buf);
> > +	print_hex_dump(KERN_DEBUG, " ", DUMP_PREFIX_OFFSET, 16, 1, buf, len, 0);
> 
> Prefix should be ""

Oh, initially there is an indentation in one space.
Maybe Giuseppe would comment on this.

> Please use true/false for the last argument

Okay.

> 
> Another (better?) option would be to use:
> 
> 	print_hex_dump_bytes("", DUMP_PREFIX_OFFSET, buf, len);

> so that it can be dynamically controlled like
> the pr_debug statements.

Ah, yes, but unfortunately it will print ASCII part always. Giuseppe,
what do you think?

P.S. [off topic] Joe, just would like to know if you have you seen my
last version of the patch series against hexdump.c which adds
seq_hex_dump() call [1]. If so, could you comment on it?
[1] https://lkml.org/lkml/2014/9/4/309

-- 
Andy Shevchenko <andriy.shevchenko@intel.com>
Intel Finland Oy

^ permalink raw reply

* Re: [PATCHv1 net-next] xen-netback: remove unconditional pull_skb_tail in guest Tx path
From: David Vrabel @ 2014-11-03 17:46 UTC (permalink / raw)
  To: Ian Campbell; +Cc: netdev, xen-devel, Wei Liu, Malcolm Crossley
In-Reply-To: <1415036346.1411.3.camel@citrix.com>

On 03/11/14 17:39, Ian Campbell wrote:
> On Mon, 2014-11-03 at 17:23 +0000, David Vrabel wrote:
>> From: Malcolm Crossley <malcolm.crossley@citrix.com>
>>
>> Unconditionally pulling 128 bytes into the linear buffer is not
>> required. Netback has already grant copied up-to 128 bytes from the
>> first slot of a packet into the linear buffer. The first slot normally
>> contain all the IPv4/IPv6 and TCP/UDP headers.
> 
> What about when it doesn't? It sounds as if we now won't pull up, which
> would be bad.

The network stack will always pull any headers it needs to inspect (the
frag may be a userspace page which has the same security issues as a
frag with a foreign page).

e.g., see skb_checksum_setup() called slightly later on in netback.

> To avoid the pull up the code would need to grant copy up-to 128 bytes
> from as many slots as needed, not only the first.
> 
> Also, if the grant copy has already placed 128 bytes in the linear area,
> why is the pull up touching anything in the first place? Shouldn't it be
> a nop in that case?

The grant copy only copies from the first frag which may be less than
128 bytes in length.

David

^ permalink raw reply

* Re: [PATCH] stmmac: remove custom implementation of print_hex_dump()
From: Joe Perches @ 2014-11-03 17:39 UTC (permalink / raw)
  To: Andy Shevchenko
  Cc: Giuseppe Cavallaro, netdev, Kweh Hock Leong, David S . Miller,
	Vince Bridgers
In-Reply-To: <1415035734-24163-2-git-send-email-andriy.shevchenko@linux.intel.com>

On Mon, 2014-11-03 at 19:28 +0200, Andy Shevchenko wrote:
> There is a kernel helper to dump buffers in a hexdecimal format. This patch
> substitutes the open coded function by calling that helper.
[]
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
[]
> @@ -191,14 +191,8 @@ static void stmmac_clk_csr_set(struct stmmac_priv *priv)
>  
>  static void print_pkt(unsigned char *buf, int len)
>  {
> -	int j;
> -	pr_debug("len = %d byte, buf addr: 0x%p", len, buf);
> -	for (j = 0; j < len; j++) {
> -		if ((j % 16) == 0)
> -			pr_debug("\n %03x:", j);
> -		pr_debug(" %02x", buf[j]);
> -	}
> -	pr_debug("\n");
> +	pr_debug("len = %d byte, buf addr: 0x%p\n", len, buf);
> +	print_hex_dump(KERN_DEBUG, " ", DUMP_PREFIX_OFFSET, 16, 1, buf, len, 0);

Prefix should be ""
Please use true/false for the last argument

Another (better?) option would be to use:

	print_hex_dump_bytes("", DUMP_PREFIX_OFFSET, buf, len);

so that it can be dynamically controlled like
the pr_debug statements.

^ permalink raw reply

* Re: [PATCH net] uapi: add missing network related headers to kbuild
From: David Miller @ 2014-11-03 17:33 UTC (permalink / raw)
  To: stephen; +Cc: netdev
In-Reply-To: <20141102113141.7aa1065c@urahara>

From: Stephen Hemminger <stephen@networkplumber.org>
Date: Sun, 2 Nov 2014 11:31:41 -0800

> The makefile for sanitizing kernel headers uses the kbuild file
> to determine which files to do. Several networking related headers
> were missing. Without these headers iproute2 build would break.
> 
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>

Applied, thanks Stephen.

^ permalink raw reply

* [PATCH] stmmac: fix sparse warnings
From: Andy Shevchenko @ 2014-11-03 17:28 UTC (permalink / raw)
  To: Giuseppe Cavallaro, netdev, Kweh Hock Leong, David S . Miller,
	Vince Bridgers
  Cc: Andy Shevchenko

This patch fixes the following sparse warnings.

drivers/net/ethernet/stmicro/stmmac/enh_desc.c:381:30: warning: symbol 'enh_desc_ops' was not declared. Should it be static?
drivers/net/ethernet/stmicro/stmmac/norm_desc.c:253:30: warning: symbol 'ndesc_ops' was not declared. Should it be static?
drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c:141:33: warning: symbol 'stmmac_ptp' was not declared. Should it be static?

There is no functional change.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
 drivers/net/ethernet/stmicro/stmmac/enh_desc.c        | 2 ++
 drivers/net/ethernet/stmicro/stmmac/norm_desc.c       | 2 ++
 drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c | 2 ++
 3 files changed, 6 insertions(+)

diff --git a/drivers/net/ethernet/stmicro/stmmac/enh_desc.c b/drivers/net/ethernet/stmicro/stmmac/enh_desc.c
index 1e2bcf5..ddd4272 100644
--- a/drivers/net/ethernet/stmicro/stmmac/enh_desc.c
+++ b/drivers/net/ethernet/stmicro/stmmac/enh_desc.c
@@ -23,8 +23,10 @@
 *******************************************************************************/
 
 #include <linux/stmmac.h>
+
 #include "common.h"
 #include "descs_com.h"
+#include "stmmac.h"
 
 static int enh_desc_get_tx_status(void *data, struct stmmac_extra_stats *x,
 				  struct dma_desc *p, void __iomem *ioaddr)
diff --git a/drivers/net/ethernet/stmicro/stmmac/norm_desc.c b/drivers/net/ethernet/stmicro/stmmac/norm_desc.c
index 35ad4f4..46b882c 100644
--- a/drivers/net/ethernet/stmicro/stmmac/norm_desc.c
+++ b/drivers/net/ethernet/stmicro/stmmac/norm_desc.c
@@ -23,8 +23,10 @@
 *******************************************************************************/
 
 #include <linux/stmmac.h>
+
 #include "common.h"
 #include "descs_com.h"
+#include "stmmac.h"
 
 static int ndesc_get_tx_status(void *data, struct stmmac_extra_stats *x,
 			       struct dma_desc *p, void __iomem *ioaddr)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c
index 76ad214..88e0da3 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c
@@ -25,8 +25,10 @@
 
 #include <linux/io.h>
 #include <linux/delay.h>
+
 #include "common.h"
 #include "stmmac_ptp.h"
+#include "stmmac.h"
 
 static void stmmac_config_hw_tstamping(void __iomem *ioaddr, u32 data)
 {
-- 
2.1.1

^ permalink raw reply related

* Re: Connection with Smart Z hangs
From: David Miller @ 2014-11-03 17:32 UTC (permalink / raw)
  To: torvalds; +Cc: mlg.hessigheim, devel, netdev
In-Reply-To: <CA+55aFzB+d8+pjvuPo-n5G7X9MK9vh9ER5zYLCXZBzjMD4bseA@mail.gmail.com>

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Sun, 2 Nov 2014 10:20:22 -0800

> David, I'm just going to remove that whole bogus disconnect call. It
> won't make things *work* for Martin (because this is all in the
> "connect failed" path), but that call as-is is just wrong, wrong,
> wrong. And apparently nobody cares about irda any more.

I totally agree, just kill it.  For the record this got added in:

commit 5b40964eadea40509d353318d2c82e8b7bf5e8a5
Author: Samuel Ortiz <samuel@sortiz.org>
Date:   Mon Oct 11 00:46:51 2010 +0200

    irda: Remove BKL instances from af_irda.c

which claims to be just a locking change, but obviously added
this bogus ->disconnect() call as well.

> If anybody is at all interested in helping maintain irda code, holler
> to David and to the netdev mailing list. The position is up for grabs.

Seriously... :-)

^ permalink raw reply

* [PATCH] stmmac: remove custom implementation of print_hex_dump()
From: Andy Shevchenko @ 2014-11-03 17:28 UTC (permalink / raw)
  To: Giuseppe Cavallaro, netdev, Kweh Hock Leong, David S . Miller,
	Vince Bridgers
  Cc: Andy Shevchenko
In-Reply-To: <1415035734-24163-1-git-send-email-andriy.shevchenko@linux.intel.com>

There is a kernel helper to dump buffers in a hexdecimal format. This patch
substitutes the open coded function by calling that helper.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 10 ++--------
 1 file changed, 2 insertions(+), 8 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 6f77a46..5fb87f5 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -191,14 +191,8 @@ static void stmmac_clk_csr_set(struct stmmac_priv *priv)
 
 static void print_pkt(unsigned char *buf, int len)
 {
-	int j;
-	pr_debug("len = %d byte, buf addr: 0x%p", len, buf);
-	for (j = 0; j < len; j++) {
-		if ((j % 16) == 0)
-			pr_debug("\n %03x:", j);
-		pr_debug(" %02x", buf[j]);
-	}
-	pr_debug("\n");
+	pr_debug("len = %d byte, buf addr: 0x%p\n", len, buf);
+	print_hex_dump(KERN_DEBUG, " ", DUMP_PREFIX_OFFSET, 16, 1, buf, len, 0);
 }
 
 /* minimum number of free TX descriptors required to wake up TX process */
-- 
2.1.1

^ permalink raw reply related

* Re: [PATCH V1 net-next 0/5] Mellanox ethernet driver update Oct-30-2014
From: David Miller @ 2014-11-03 17:28 UTC (permalink / raw)
  To: ogerlitz; +Cc: netdev, matanb, amirv, saeedm, shanim, idos
In-Reply-To: <1414938377-421-1-git-send-email-ogerlitz@mellanox.com>

From: Or Gerlitz <ogerlitz@mellanox.com>
Date: Sun,  2 Nov 2014 16:26:12 +0200

> The 1st patch from Saeed fixes a bug in the last net-next batch where
> a VF could get access to set port configuration, the next patch from Amir
> fixes a race in the port VPI logic. Next are two performance patches from Ido.
> 
> The patch to add checksum complete status on GRE and such packets was 
> preceded with a patch that converted the driver to only use napi_gro_receive 
> vs. the current code which goes through napi_gro_frags on it's usual track.
> Eric D. has some thoughts and suggestions on that change for which we 
> want to take the time and consider, so for the time being dropped that
> patch and the ones that depend on it.
 ...
> Changes from V0:
>   - have the caller to provide the __GFP_COLD hint to the service function
>   - dropped the patch that changes the GRO logic and the subsequent dependent
>     patches. 

Series applied, thanks.

^ permalink raw reply

* Re: [PATCH] net: less interrupt masking in NAPI
From: David Miller @ 2014-11-03 17:25 UTC (permalink / raw)
  To: eric.dumazet; +Cc: netdev, willemb
In-Reply-To: <1414937973.31792.37.camel@edumazet-glaptop2.roam.corp.google.com>

From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sun, 02 Nov 2014 06:19:33 -0800

> From: Eric Dumazet <edumazet@google.com>
> 
> net_rx_action() can mask irqs a single time to transfert sd->poll_list
> into a private list, for a very short duration.
> 
> Then, napi_complete() can avoid masking irqs again,
> and net_rx_action() only needs to mask irq again in slow path.
> 
> This patch removes 2 couples of irq mask/unmask per typical NAPI run,
> more if multiple napi were triggered.
> 
> Note this also allows to give control back to caller (do_softirq())
> more often, so that other softirq handlers can be called a bit earlier,
> or ksoftirqd can be wakeup earlier under pressure.
> 
> This was developed while testing an alternative to RX interrupt
> mitigation to reduce latencies while keeping or improving GRO
> aggregation on fast NIC.
> 
> Idea is to test napi->gro_list at the end of a napi->poll() and
> reschedule one NAPI poll, but after servicing a full round of
> softirqs (timers, TX, rcu, ...). This will be allowed only if softirq
> is currently serviced by idle task or ksoftirqd, and resched not needed.
> 
> Signed-off-by: Eric Dumazet <edumazet@google.com>

Also applied, thanks Eric.

^ permalink raw reply

* Re: [PATCH] net: shrink struct softnet_data
From: David Miller @ 2014-11-03 17:25 UTC (permalink / raw)
  To: eric.dumazet; +Cc: netdev
In-Reply-To: <1414936812.31792.31.camel@edumazet-glaptop2.roam.corp.google.com>

From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sun, 02 Nov 2014 06:00:12 -0800

> From: Eric Dumazet <edumazet@google.com>
> 
> flow_limit in struct softnet_data is only read from local cpu
> and can be moved to fill a hole, reducing softnet_data size by
> 64 bytes on x86_64
> 
> While we are at it, move output_queue, output_queue_tailp and
> completion_queue, so that rx / tx paths touch a single cache line.
> 
> Signed-off-by: Eric Dumazet <edumazet@google.com>

Applied.

^ permalink raw reply

* [PATCHv1 net-next] xen-netback: remove unconditional pull_skb_tail in guest Tx path
From: David Vrabel @ 2014-11-03 17:23 UTC (permalink / raw)
  To: netdev; +Cc: David Vrabel, xen-devel, Ian Campbell, Wei Liu, Malcolm Crossley

From: Malcolm Crossley <malcolm.crossley@citrix.com>

Unconditionally pulling 128 bytes into the linear buffer is not
required. Netback has already grant copied up-to 128 bytes from the
first slot of a packet into the linear buffer. The first slot normally
contain all the IPv4/IPv6 and TCP/UDP headers.

The unconditional pull would often copy frag data unnecessarily.  This
is a performance problem when running on a version of Xen where grant
unmap avoids TLB flushes for pages which are not accessed.  TLB
flushes can now be avoided for > 99% of unmaps (it was 0% before).

Grant unmap TLB flush avoidance will be available in a future version
of Xen (probably 4.6).

Signed-off-by: Malcolm Crossley <malcolm.crossley@citrix.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 drivers/net/xen-netback/netback.c |   26 ++++++++++++--------------
 1 file changed, 12 insertions(+), 14 deletions(-)

diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 730252c..14e18bb 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -82,6 +82,16 @@ MODULE_PARM_DESC(max_queues,
 static unsigned int fatal_skb_slots = FATAL_SKB_SLOTS_DEFAULT;
 module_param(fatal_skb_slots, uint, 0444);
 
+/* The amount to copy out of the first guest Tx slot into the skb's
+ * linear area.  If the first slot has more data, it will be mapped
+ * and put into the first frag.
+ *
+ * This is sized to avoid pulling headers from the frags for most
+ * TCP/IP packets.
+ */
+#define XEN_NETBACK_TX_COPY_LEN 128
+
+
 static void xenvif_idx_release(struct xenvif_queue *queue, u16 pending_idx,
 			       u8 status);
 
@@ -125,13 +135,6 @@ static inline struct xenvif_queue *ubuf_to_queue(const struct ubuf_info *ubuf)
 			    pending_tx_info[0]);
 }
 
-/* This is a miniumum size for the linear area to avoid lots of
- * calls to __pskb_pull_tail() as we set up checksum offsets. The
- * value 128 was chosen as it covers all IPv4 and most likely
- * IPv6 headers.
- */
-#define PKT_PROT_LEN 128
-
 static u16 frag_get_pending_idx(skb_frag_t *frag)
 {
 	return (u16)frag->page_offset;
@@ -1446,9 +1449,9 @@ static void xenvif_tx_build_gops(struct xenvif_queue *queue,
 		index = pending_index(queue->pending_cons);
 		pending_idx = queue->pending_ring[index];
 
-		data_len = (txreq.size > PKT_PROT_LEN &&
+		data_len = (txreq.size > XEN_NETBACK_TX_COPY_LEN &&
 			    ret < XEN_NETBK_LEGACY_SLOTS_MAX) ?
-			PKT_PROT_LEN : txreq.size;
+			XEN_NETBACK_TX_COPY_LEN : txreq.size;
 
 		skb = xenvif_alloc_skb(data_len);
 		if (unlikely(skb == NULL)) {
@@ -1653,11 +1656,6 @@ static int xenvif_tx_submit(struct xenvif_queue *queue)
 			}
 		}
 
-		if (skb_is_nonlinear(skb) && skb_headlen(skb) < PKT_PROT_LEN) {
-			int target = min_t(int, skb->len, PKT_PROT_LEN);
-			__pskb_pull_tail(skb, target - skb_headlen(skb));
-		}
-
 		skb->dev      = queue->vif->dev;
 		skb->protocol = eth_type_trans(skb, skb->dev);
 		skb_reset_network_header(skb);
-- 
1.7.10.4

^ permalink raw reply related

* Re: [stable request <= 3.11] net/mlx4_en: Fix BlueFlame race
From: Cong Wang @ 2014-11-03 17:22 UTC (permalink / raw)
  To: David Miller
  Cc: Ben Hutchings, Vinson Lee, Amir Vadai, Or Gerlitz,
	Jack Morgenstein, Eugenia Emantayev, Matan Barak, netdev
In-Reply-To: <20141101.134142.888127846627939710.davem@davemloft.net>

On Sat, Nov 1, 2014 at 10:41 AM, David Miller <davem@davemloft.net> wrote:
>
> There is no documented way nor do I wish to state anything so strictly.
> I want maximum flexibility for such a time consuming task.
>
> I tend to go back 3 or 4 releases at most, and it really depends upon
> the difficulty of the backports and my own time constraints.

You should really offload to developers, otherwise too much work for you. :)

Thanks!

^ permalink raw reply

* Re: [PATCH v2] PPC: bpf_jit_comp: add SKF_AD_PKTTYPE instruction
From: Alexei Starovoitov @ 2014-11-03 17:21 UTC (permalink / raw)
  To: David Miller, felix
  Cc: Denis Kirjanov, netdev@vger.kernel.org, linuxppc-dev,
	Michael Ellerman, Matt Evans
In-Reply-To: <20141103.120633.183870310578884991.davem@davemloft.net>

On Mon, Nov 3, 2014 at 9:06 AM, David Miller <davem@davemloft.net> wrote:
> From: Denis Kirjanov <kda@linux-powerpc.org>
> Date: Thu, 30 Oct 2014 09:12:15 +0300
>
>> Add BPF extension SKF_AD_PKTTYPE to ppc JIT to load
>> skb->pkt_type field.
>>
>> Before:
>> [   88.262622] test_bpf: #11 LD_IND_NET 86 97 99 PASS
>> [   88.265740] test_bpf: #12 LD_PKTTYPE 109 107 PASS
>>
>> After:
>> [   80.605964] test_bpf: #11 LD_IND_NET 44 40 39 PASS
>> [   80.607370] test_bpf: #12 LD_PKTTYPE 9 9 PASS
>>
>> CC: Alexei Starovoitov<alexei.starovoitov@gmail.com>
>> CC: Michael Ellerman<mpe@ellerman.id.au>
>> Cc: Matt Evans <matt@ozlabs.org>
>> Signed-off-by: Denis Kirjanov <kda@linux-powerpc.org>
>>
>> v2: Added test rusults
>
> So, can I apply this now?

I think this question is more towards ppc folks,
since both Daniel and myself said before that it looks ok.
Philippe just tested the previous version of this patch on ppc64le...
I'm guessing that Matt (original author of bpf jit for ppc) is not replying,
because he has no objections.
Either way the addition is tiny and contained, so can go in now.

^ permalink raw reply

* Re: [PATCH bluetooth-next] netdevice: add ieee802154_ptr to net_device
From: David Miller @ 2014-11-03 17:20 UTC (permalink / raw)
  To: alex.aring-Re5JQEeQqe8AvxtiuMwx3w
  Cc: linux-wpan-u79uwXL29TY76Z2rM5mHXA, kernel-bIcnvbaLZ9MEGnE8C9+IrQ,
	netdev-u79uwXL29TY76Z2rM5mHXA,
	linux-wireless-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1414907094-9623-1-git-send-email-alex.aring-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

From: Alexander Aring <alex.aring-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date: Sun,  2 Nov 2014 06:44:54 +0100

> This patch adds an ieee802154_ptr to the net_device structure.
> Furthermore the 802.15.4 subsystem will introduce a nl802154 framework
> which is similar like the nl80211 framework and a wpan_dev structure.
> The wpan_dev structure will hold additional net_device attributes like
> address options which are 802.15.4 specific. In the upcoming nl802154
> implementation we will introduce a NL802154_FLAG_NEED_WPAN_DEV like
> NL80211_FLAG_NEED_WDEV. For this flag an ieee802154_ptr in net_device is
> needed. Additional we can access the wpan_dev attributes in upper layers
> like IEEE 802.15.4 6LoWPAN easily. Current solution is a complicated
> callback interface and getting these values over subif data structure
> in mac802154.
> 
> Signed-off-by: Alexander Aring <alex.aring-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

No objections, and you can merge this via the bluetooth tree:

Acked-by: David S. Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Re: [PATCH net-next 3/7] gue: Add infrastructure for flags and options
From: David Miller @ 2014-11-03 17:18 UTC (permalink / raw)
  To: therbert; +Cc: netdev
In-Reply-To: <1414882683-25484-4-git-send-email-therbert@google.com>

From: Tom Herbert <therbert@google.com>
Date: Sat,  1 Nov 2014 15:57:59 -0700

> @@ -20,7 +20,16 @@ static size_t fou_encap_hlen(struct ip_tunnel_encap *e)
>  
>  static size_t gue_encap_hlen(struct ip_tunnel_encap *e)
>  {
> -	return sizeof(struct udphdr) + sizeof(struct guehdr);
> +	size_t len;
> +	bool need_priv = false;
> +
> +	len = sizeof(struct udphdr) + sizeof(struct guehdr);
> +
> +	/* Add in lengths flags */
> +
> +	len += need_priv ? GUE_LEN_PRIV : 0;

Add this need_priv logic in patch #6, not here.

^ permalink raw reply

* Re: [PATCH v2] PPC: bpf_jit_comp: add SKF_AD_PKTTYPE instruction
From: David Miller @ 2014-11-03 17:06 UTC (permalink / raw)
  To: kda; +Cc: netdev, linuxppc-dev, alexei.starovoitov, mpe, matt
In-Reply-To: <1414649535-3956-1-git-send-email-kda@linux-powerpc.org>

From: Denis Kirjanov <kda@linux-powerpc.org>
Date: Thu, 30 Oct 2014 09:12:15 +0300

> Add BPF extension SKF_AD_PKTTYPE to ppc JIT to load
> skb->pkt_type field.
> 
> Before:
> [   88.262622] test_bpf: #11 LD_IND_NET 86 97 99 PASS
> [   88.265740] test_bpf: #12 LD_PKTTYPE 109 107 PASS
> 
> After:
> [   80.605964] test_bpf: #11 LD_IND_NET 44 40 39 PASS
> [   80.607370] test_bpf: #12 LD_PKTTYPE 9 9 PASS
> 
> CC: Alexei Starovoitov<alexei.starovoitov@gmail.com>
> CC: Michael Ellerman<mpe@ellerman.id.au>
> Cc: Matt Evans <matt@ozlabs.org>
> Signed-off-by: Denis Kirjanov <kda@linux-powerpc.org>
> 
> v2: Added test rusults

So, can I apply this now?

^ permalink raw reply

* Re: [PATCH 1/7] can: m_can: fix possible sleep in napi poll
From: Marc Kleine-Budde @ 2014-11-03 17:02 UTC (permalink / raw)
  To: Dong Aisheng, linux-can
  Cc: wg, varkabhadram, netdev, socketcan, linux-arm-kernel
In-Reply-To: <1414579527-31100-1-git-send-email-b29396@freescale.com>

[-- Attachment #1: Type: text/plain, Size: 529 bytes --]

Hey Dong Aisheng,

the state of the patches are:

1: can/master + stable
2: can/mster
3: can/mster
4: can/master + stable
5: waiting for Oliver's opinion due to the user space change
6: waiting for your input
7: waiting for your input

Marc
-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply

* Re: [PATCH 4/7] can: m_can: add a bit delay after setting CCCR_INIT bit
From: Marc Kleine-Budde @ 2014-11-03 16:52 UTC (permalink / raw)
  To: Dong Aisheng, linux-can
  Cc: wg, varkabhadram, netdev, socketcan, linux-arm-kernel
In-Reply-To: <1414579527-31100-4-git-send-email-b29396@freescale.com>

[-- Attachment #1: Type: text/plain, Size: 825 bytes --]

On 10/29/2014 11:45 AM, Dong Aisheng wrote:
> The spec mentions there may be a delay until the value written to
> INIT can be read back due to the synchronization mechanism between the
> two clock domains. But it does not indicate the exact clock cycles needed.
> The 5us delay is a test value and seems ok.
> 
> Without the delay, CCCR.CCE bit may fail to be set and then the
> initialization fail sometimes when do repeatly up and down.
> 
> Signed-off-by: Dong Aisheng <b29396@freescale.com>

Applied to can/master.

Thanks,
Marc

-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply

* Re: [PATCH 3/7] can: m_can: add .ndo_change_mtu function
From: Marc Kleine-Budde @ 2014-11-03 16:49 UTC (permalink / raw)
  To: Dong Aisheng, linux-can
  Cc: wg, varkabhadram, netdev, socketcan, linux-arm-kernel
In-Reply-To: <1414579527-31100-3-git-send-email-b29396@freescale.com>

[-- Attachment #1: Type: text/plain, Size: 462 bytes --]

On 10/29/2014 11:45 AM, Dong Aisheng wrote:
> Use common can_change_mtu function.
> 
> Signed-off-by: Dong Aisheng <b29396@freescale.com>

Applied to can/master.

Thanks,
Marc

-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox