* Re: [PATCH 1/2] net: Toeplitz library functions
From: Eric Dumazet @ 2013-09-24 16:10 UTC (permalink / raw)
To: Tom Herbert
Cc: David Miller, David Laight, Linux Netdev List, Brandeburg, Jesse
In-Reply-To: <CA+mtBx_AcmcNBDhRKVB8YDkSNdOwgJ3CXxBqpgxDw23X3m2rvQ@mail.gmail.com>
On Tue, 2013-09-24 at 08:54 -0700, Tom Herbert wrote:
> The Toeplitz function uses a secret key whose length is based on the
> input length. 96 bits in IPv4, 320 bits in IPv6. I don't see how an
> attacker can reproduce this if the key is random. If the problem is
> that devices are not being configured with a sufficiently random key
> (some actually are using a fixed key :-( ), that's a separate issue
> that should be addressed. It is possible to DoS attack through the
> steering mechanism.
Well, your patch would make sense [1] only if we could use hardware
assistance, but right now we have no idea of how safe are the existing
assistances.
[1] Computing Toeplitz in software is way more expensive than jhash.
Dos attack is quite simple right now, even without knowing if the target
uses or not steering.
^ permalink raw reply
* Re: [PATCH net v4 1/1] xen-netback: Handle backend state transitions in a more robust way
From: Wei Liu @ 2013-09-24 16:12 UTC (permalink / raw)
To: Paul Durrant; +Cc: xen-devel, netdev, Ian Campbell, Wei Liu, David Vrabel
In-Reply-To: <1380037500-12174-2-git-send-email-paul.durrant@citrix.com>
You forgot to fix those typos -- metback, transtions. :-)
On Tue, Sep 24, 2013 at 04:45:00PM +0100, Paul Durrant wrote:
> When the frontend state changes metback now specifies its desired state to
metback
[...]
> + * The backend state starts in InitWait and the following transtions are
transtions
Wei.
^ permalink raw reply
* Re: [PATCH 1/2] net: Toeplitz library functions
From: Eric Dumazet @ 2013-09-24 16:14 UTC (permalink / raw)
To: Hannes Frederic Sowa; +Cc: Tom Herbert, davem, netdev, jesse.brandeburg
In-Reply-To: <20130924160145.GB26769@order.stressinduktion.org>
On Tue, 2013-09-24 at 18:01 +0200, Hannes Frederic Sowa wrote:
> inet(6)_ehashfn does get used by udp btw. But I do not understand the code,
> yet. ;)
Oh well, thats the SO_REUSEPORT thing. We do not really care, thats only
used to try to steer udp flows on a given socket, but its a hint.
Presumably it should use a separate secret key.
^ permalink raw reply
* Re: [PATCH net v2] vxlan: Use RCU apis to access sk_user_data.
From: Eric Dumazet @ 2013-09-24 16:16 UTC (permalink / raw)
To: Pravin B Shelar; +Cc: netdev, Jesse Gross
In-Reply-To: <1380038979-24035-1-git-send-email-pshelar@nicira.com>
On Tue, 2013-09-24 at 09:09 -0700, Pravin B Shelar wrote:
> Use of RCU api makes vxlan code easier to understand. It also
> fixes bug due to missing ACCESS_ONCE() on sk_user_data dereference.
> In rare case without ACCESS_ONCE() compiler might omit vs on
> sk_user_data dereference. Compiler can use vs as alias for
> sk->sk_user_data, resulting in multiple sk_user_data dereference
> in rcu read context which could change.
>
> CC: Jesse Gross <jesse@nicira.com>
> Signed-off-by: Pravin B Shelar <pshelar@nicira.com>
> ---
> v2:
> Use RCU_INIT_POINTER
> ---
> drivers/net/vxlan.c | 11 ++++-------
> include/net/sock.h | 2 ++
> 2 files changed, 6 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
> index d1292fe..1fae0d6 100644
> --- a/drivers/net/vxlan.c
> +++ b/drivers/net/vxlan.c
> @@ -1,4 +1,4 @@
> -/*
> + /*
> * VXLAN: Virtual eXtensible Local Area Network
> *
extra space ?
^ permalink raw reply
* [PATCH 1/2] net: Add function to get SW rxhash
From: Tom Herbert @ 2013-09-24 16:20 UTC (permalink / raw)
To: davem; +Cc: netdev
Some uses of skb_get_rxhash expect that the function will return
a consistent value whether it is called on RX or TX paths. On RX
path, we will use the rxhash if provided by the NIC, so this
would not normally be the same result computed in TX path which is
a software calculation.
This patch adds skb_get_sw_rxhash to explicitly request a hash
calculated by the stack, disregarding the hash provided by NIC.
Signed-off-by: Tom Herbert <therbert@google.com>
---
include/linux/skbuff.h | 11 ++++++++++-
net/core/flow_dissector.c | 1 +
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 2ddb48d..917a590 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -488,6 +488,7 @@ struct sk_buff {
__u8 pfmemalloc:1;
__u8 ooo_okay:1;
__u8 l4_rxhash:1;
+ __u8 sw_rxhash:1;
__u8 wifi_acked_valid:1;
__u8 wifi_acked:1;
__u8 no_fcs:1;
@@ -498,7 +499,7 @@ struct sk_buff {
* headers if needed
*/
__u8 encapsulation:1;
- /* 7/9 bit hole (depending on ndisc_nodetype presence) */
+ /* 6/8 bit hole (depending on ndisc_nodetype presence) */
kmemcheck_bitfield_end(flags2);
#if defined CONFIG_NET_DMA || defined CONFIG_NET_RX_BUSY_POLL
@@ -726,6 +727,14 @@ static inline __u32 skb_get_rxhash(struct sk_buff *skb)
return skb->rxhash;
}
+static inline __u32 skb_get_sw_rxhash(struct sk_buff *skb)
+{
+ if (!skb->l4_rxhash && !skb->sw_rxhash)
+ __skb_get_rxhash(skb);
+
+ return skb->rxhash;
+}
+
#ifdef NET_SKBUFF_DATA_USES_OFFSET
static inline unsigned char *skb_end_pointer(const struct sk_buff *skb)
{
diff --git a/net/core/flow_dissector.c b/net/core/flow_dissector.c
index 1929af8..8979121 100644
--- a/net/core/flow_dissector.c
+++ b/net/core/flow_dissector.c
@@ -200,6 +200,7 @@ void __skb_get_rxhash(struct sk_buff *skb)
hash = 1;
skb->rxhash = hash;
+ skb->sw_rxhash = 1;
}
EXPORT_SYMBOL(__skb_get_rxhash);
--
1.8.4
^ permalink raw reply related
* Re: [PATCH net] vxlan: Use RCU apis to access sk_user_data.
From: Stephen Hemminger @ 2013-09-24 16:20 UTC (permalink / raw)
To: Pravin B Shelar; +Cc: netdev, Jesse Gross
In-Reply-To: <1380000501-13969-1-git-send-email-pshelar@nicira.com>
On Mon, 23 Sep 2013 22:28:21 -0700
Pravin B Shelar <pshelar@nicira.com> wrote:
>
> +#define sk_user_data_rcu(sk) ((*((void __rcu **)&(sk)->sk_user_data)))
I don't like the macro, is it just to keep sparse happy?
The name also implies that rcu_dereference() is built in.
^ permalink raw reply
* [PATCH net-next v2] dev: always advertise rx_flags changes
From: Nicolas Dichtel @ 2013-09-24 16:21 UTC (permalink / raw)
To: stephen; +Cc: netdev, davem, Nicolas Dichtel
In-Reply-To: <20130923122715.1d1b2005@nehalam.linuxnetplumber.net>
Depending on the code path, there is/isn't netlink message/call to notifier
chains when rx_flags are updated, let's send advertisement for all cases.
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
---
v2: rework the patch to avoid double notification
net/core/dev.c | 64 +++++++++++++++++++++++++++++++++++++---------------------
1 file changed, 41 insertions(+), 23 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index 5c713f2239cc..067bfbe70c4c 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -4822,7 +4822,7 @@ static void dev_change_rx_flags(struct net_device *dev, int flags)
ops->ndo_change_rx_flags(dev, flags);
}
-static int __dev_set_promiscuity(struct net_device *dev, int inc)
+static int __dev_set_promiscuity(struct net_device *dev, int inc, bool notif)
{
unsigned int old_flags = dev->flags;
kuid_t uid;
@@ -4865,6 +4865,10 @@ static int __dev_set_promiscuity(struct net_device *dev, int inc)
dev_change_rx_flags(dev, IFF_PROMISC);
}
+ if (notif) {
+ call_netdevice_notifiers(NETDEV_CHANGE, dev);
+ rtmsg_ifinfo(RTM_NEWLINK, dev, IFF_PROMISC);
+ }
return 0;
}
@@ -4884,7 +4888,7 @@ int dev_set_promiscuity(struct net_device *dev, int inc)
unsigned int old_flags = dev->flags;
int err;
- err = __dev_set_promiscuity(dev, inc);
+ err = __dev_set_promiscuity(dev, inc, true);
if (err < 0)
return err;
if (dev->flags != old_flags)
@@ -4893,22 +4897,9 @@ int dev_set_promiscuity(struct net_device *dev, int inc)
}
EXPORT_SYMBOL(dev_set_promiscuity);
-/**
- * dev_set_allmulti - update allmulti count on a device
- * @dev: device
- * @inc: modifier
- *
- * Add or remove reception of all multicast frames to a device. While the
- * count in the device remains above zero the interface remains listening
- * to all interfaces. Once it hits zero the device reverts back to normal
- * filtering operation. A negative @inc value is used to drop the counter
- * when releasing a resource needing all multicasts.
- * Return 0 if successful or a negative errno code on error.
- */
-
-int dev_set_allmulti(struct net_device *dev, int inc)
+static int __dev_set_allmulti(struct net_device *dev, int inc, bool notif)
{
- unsigned int old_flags = dev->flags;
+ unsigned int old_flags = dev->flags, old_gflags = dev->gflags;
ASSERT_RTNL();
@@ -4931,9 +4922,32 @@ int dev_set_allmulti(struct net_device *dev, int inc)
if (dev->flags ^ old_flags) {
dev_change_rx_flags(dev, IFF_ALLMULTI);
dev_set_rx_mode(dev);
+ if (notif) {
+ call_netdevice_notifiers(NETDEV_CHANGE, dev);
+ if (dev->gflags ^ old_gflags)
+ rtmsg_ifinfo(RTM_NEWLINK, dev, IFF_ALLMULTI);
+ }
}
return 0;
}
+
+/**
+ * dev_set_allmulti - update allmulti count on a device
+ * @dev: device
+ * @inc: modifier
+ *
+ * Add or remove reception of all multicast frames to a device. While the
+ * count in the device remains above zero the interface remains listening
+ * to all interfaces. Once it hits zero the device reverts back to normal
+ * filtering operation. A negative @inc value is used to drop the counter
+ * when releasing a resource needing all multicasts.
+ * Return 0 if successful or a negative errno code on error.
+ */
+
+int dev_set_allmulti(struct net_device *dev, int inc)
+{
+ return __dev_set_allmulti(dev, inc, true);
+}
EXPORT_SYMBOL(dev_set_allmulti);
/*
@@ -4958,10 +4972,10 @@ void __dev_set_rx_mode(struct net_device *dev)
* therefore calling __dev_set_promiscuity here is safe.
*/
if (!netdev_uc_empty(dev) && !dev->uc_promisc) {
- __dev_set_promiscuity(dev, 1);
+ __dev_set_promiscuity(dev, 1, false);
dev->uc_promisc = true;
} else if (netdev_uc_empty(dev) && dev->uc_promisc) {
- __dev_set_promiscuity(dev, -1);
+ __dev_set_promiscuity(dev, -1, false);
dev->uc_promisc = false;
}
}
@@ -5050,9 +5064,13 @@ int __dev_change_flags(struct net_device *dev, unsigned int flags)
if ((flags ^ dev->gflags) & IFF_PROMISC) {
int inc = (flags & IFF_PROMISC) ? 1 : -1;
+ unsigned int old_flags = dev->flags;
dev->gflags ^= IFF_PROMISC;
- dev_set_promiscuity(dev, inc);
+
+ if (__dev_set_promiscuity(dev, inc, false) >= 0)
+ if (dev->flags != old_flags)
+ dev_set_rx_mode(dev);
}
/* NOTE: order of synchronization of IFF_PROMISC and IFF_ALLMULTI
@@ -5063,7 +5081,7 @@ int __dev_change_flags(struct net_device *dev, unsigned int flags)
int inc = (flags & IFF_ALLMULTI) ? 1 : -1;
dev->gflags ^= IFF_ALLMULTI;
- dev_set_allmulti(dev, inc);
+ __dev_set_allmulti(dev, inc, false);
}
return ret;
@@ -5101,13 +5119,13 @@ void __dev_notify_flags(struct net_device *dev, unsigned int old_flags)
int dev_change_flags(struct net_device *dev, unsigned int flags)
{
int ret;
- unsigned int changes, old_flags = dev->flags;
+ unsigned int changes, old_flags = dev->flags, old_gflags = dev->gflags;
ret = __dev_change_flags(dev, flags);
if (ret < 0)
return ret;
- changes = old_flags ^ dev->flags;
+ changes = (old_flags ^ dev->flags) | (old_gflags ^ dev->gflags);
if (changes)
rtmsg_ifinfo(RTM_NEWLINK, dev, changes);
--
1.8.2.1
^ permalink raw reply related
* Re: [PATCH net v2] vxlan: Use RCU apis to access sk_user_data.
From: Pravin Shelar @ 2013-09-24 16:25 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, Jesse Gross
In-Reply-To: <1380039366.3165.92.camel@edumazet-glaptop>
On Tue, Sep 24, 2013 at 9:16 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Tue, 2013-09-24 at 09:09 -0700, Pravin B Shelar wrote:
>> Use of RCU api makes vxlan code easier to understand. It also
>> fixes bug due to missing ACCESS_ONCE() on sk_user_data dereference.
>> In rare case without ACCESS_ONCE() compiler might omit vs on
>> sk_user_data dereference. Compiler can use vs as alias for
>> sk->sk_user_data, resulting in multiple sk_user_data dereference
>> in rcu read context which could change.
>>
>> CC: Jesse Gross <jesse@nicira.com>
>> Signed-off-by: Pravin B Shelar <pshelar@nicira.com>
>> ---
>> v2:
>> Use RCU_INIT_POINTER
>> ---
>> drivers/net/vxlan.c | 11 ++++-------
>> include/net/sock.h | 2 ++
>> 2 files changed, 6 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
>> index d1292fe..1fae0d6 100644
>> --- a/drivers/net/vxlan.c
>> +++ b/drivers/net/vxlan.c
>> @@ -1,4 +1,4 @@
>> -/*
>> + /*
>> * VXLAN: Virtual eXtensible Local Area Network
>> *
>
>
> extra space ?
>
right, I missed that.
^ permalink raw reply
* [RFC PATCH 0/2] l2tp: add vlan pseudowire support
From: James Chapman @ 2013-09-24 16:27 UTC (permalink / raw)
To: netdev; +Cc: James Chapman
This RFC patch series adds L2TP vlan pseudowire support by creating a
vlan netdev in addition to the l2tpeth netdev when the user creates
vlan pseudowires. To do so, new symbols are exported in 8021q to allow
l2tp to create and destroy vlan netdevs. The existing L2TP netlink API
already contains attributes for vlan pseudowires but they have been
unused to date.
L2TP vlan pseudowires are similar to the existing L2TP ethernet
pseudowires except that vlan pseudowires always carry only one vlan
and never carry untagged frames, while ethernet pseudowires can carry
any ethernet frame (tagged or untagged). It is possible to create vlan
interfaces on top of l2tpeth interfaces (ethernet pseudowires) today
using standard tools. But for VLAN pseudowires, there must be one and
only one vlan.
The changes in this patch series create a pair of netdevs per vlan
pseudowire: a vlan netdev and an l2tpeth netdev; the l2tpeth netdev is
used as the master for the vlan netdev. The master netdev must not be
configured since untagged frames are not allowed in vlan pseudowires.
Some L2TP setups have thousands of L2TP pseudowires so creating two
netdevs per vlan pseudowire isn't ideal when one might suffice. Should I
investigate changing 8021q to allow for the case where there is no
master netdev?
James Chapman (2):
vlan: export functions to register/unregister vlan devices
l2tp: add vlan pseudowire support
include/linux/if_vlan.h | 11 ++++++
net/8021q/vlan.c | 82 ++++++++++++++++++++++++++++------------------
net/l2tp/l2tp_eth.c | 73 ++++++++++++++++++++++++++++++++++++++++-
3 files changed, 132 insertions(+), 34 deletions(-)
^ permalink raw reply
* [RFC PATCH 2/2] l2tp: add vlan pseudowire support
From: James Chapman @ 2013-09-24 16:27 UTC (permalink / raw)
To: netdev; +Cc: James Chapman
In-Reply-To: <1380040030-6648-1-git-send-email-jchapman@katalix.com>
Register the l2tp_eth driver for netlink ops using the vlan pseudowire
type. Add code to create/destroy a VLAN netdevice when the pseudowire
type is VLAN. This requires new exports in the vlan code.
This results in two netdevices per vlan pseudowire:
1. a master, which should never be used
2. a vlan device, which is enslaved to the master device
The session's ifname value is set to the VLAN netdevice name such
that it is the name returned in session_get netlink requests. For vlan
pseudowires, this should always be the interface that userspace
configures.
---
net/l2tp/l2tp_eth.c | 73 +++++++++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 71 insertions(+), 2 deletions(-)
diff --git a/net/l2tp/l2tp_eth.c b/net/l2tp/l2tp_eth.c
index 76125c5..aae38d9 100644
--- a/net/l2tp/l2tp_eth.c
+++ b/net/l2tp/l2tp_eth.c
@@ -17,6 +17,7 @@
#include <linux/hash.h>
#include <linux/l2tp.h>
#include <linux/in.h>
+#include <linux/if_vlan.h>
#include <linux/etherdevice.h>
#include <linux/spinlock.h>
#include <net/sock.h>
@@ -53,6 +54,7 @@ struct l2tp_eth {
/* via l2tp_session_priv() */
struct l2tp_eth_sess {
struct net_device *dev;
+ struct net_device *vlan_dev;
};
/* per-net private data for this module */
@@ -178,6 +180,50 @@ error:
kfree_skb(skb);
}
+static int l2tp_vlan_create(struct l2tp_session *session, u16 vlan_id)
+{
+ struct l2tp_eth_sess *spriv;
+ struct net_device *dev;
+ struct net_device *vlan_dev;
+ char name[IFNAMSIZ + 1];
+ int rc;
+
+ spriv = l2tp_session_priv(session);
+ dev = spriv->dev;
+
+ if (!vlan_id)
+ return -EINVAL;
+
+ snprintf(name, IFNAMSIZ, "%s.%i", dev->name, vlan_id);
+ rtnl_lock();
+ rc = vlan_register_device(dev, vlan_id, &vlan_dev, name);
+ rtnl_unlock();
+ if (rc < 0)
+ return rc;
+
+ spriv->vlan_dev = vlan_dev;
+ strlcpy(session->ifname, vlan_dev->name, IFNAMSIZ);
+
+ return 0;
+}
+
+static int l2tp_vlan_delete(struct l2tp_session *session)
+{
+ struct l2tp_eth_sess *spriv;
+ struct net_device *dev;
+
+ spriv = l2tp_session_priv(session);
+ dev = spriv->dev;
+
+ rtnl_lock();
+ unregister_vlan_dev(spriv->vlan_dev, NULL);
+ rtnl_unlock();
+ strlcpy(session->ifname, dev->name, IFNAMSIZ);
+ spriv->vlan_dev = NULL;
+
+ return 0;
+}
+
static void l2tp_eth_delete(struct l2tp_session *session)
{
struct l2tp_eth_sess *spriv;
@@ -186,6 +232,8 @@ static void l2tp_eth_delete(struct l2tp_session *session)
if (session) {
spriv = l2tp_session_priv(session);
dev = spriv->dev;
+ if (spriv->vlan_dev)
+ l2tp_vlan_delete(session);
if (dev) {
unregister_netdev(dev);
spriv->dev = NULL;
@@ -277,10 +325,18 @@ static int l2tp_eth_create(struct net *net, u32 tunnel_id, u32 session_id, u32 p
if (rc < 0)
goto out_del_dev;
- __module_get(THIS_MODULE);
/* Must be done after register_netdev() */
strlcpy(session->ifname, dev->name, IFNAMSIZ);
+ if (cfg->pw_type == L2TP_PWTYPE_ETH_VLAN) {
+ /* Create VLAN interface. Replaces session->ifname */
+ rc = l2tp_vlan_create(session, cfg->vlan_id);
+ if (rc < 0)
+ goto out_unreg;
+ }
+
+ __module_get(THIS_MODULE);
+
dev_hold(dev);
pn = l2tp_eth_pernet(dev_net(dev));
spin_lock(&pn->l2tp_eth_lock);
@@ -289,6 +345,8 @@ static int l2tp_eth_create(struct net *net, u32 tunnel_id, u32 session_id, u32 p
return 0;
+out_unreg:
+ unregister_netdev(dev);
out_del_dev:
free_netdev(dev);
spriv->dev = NULL;
@@ -328,6 +386,11 @@ static int __init l2tp_eth_init(void)
err = l2tp_nl_register_ops(L2TP_PWTYPE_ETH, &l2tp_eth_nl_cmd_ops);
if (err)
goto out;
+#if IS_ENABLED(CONFIG_VLAN_8021Q)
+ err = l2tp_nl_register_ops(L2TP_PWTYPE_ETH_VLAN, &l2tp_eth_nl_cmd_ops);
+ if (err)
+ goto out;
+#endif
err = register_pernet_device(&l2tp_eth_net_ops);
if (err)
@@ -338,6 +401,9 @@ static int __init l2tp_eth_init(void)
return 0;
out_unreg:
+#if IS_ENABLED(CONFIG_VLAN_8021Q)
+ l2tp_nl_unregister_ops(L2TP_PWTYPE_ETH_VLAN);
+#endif
l2tp_nl_unregister_ops(L2TP_PWTYPE_ETH);
out:
return err;
@@ -346,6 +412,9 @@ out:
static void __exit l2tp_eth_exit(void)
{
unregister_pernet_device(&l2tp_eth_net_ops);
+#if IS_ENABLED(CONFIG_VLAN_8021Q)
+ l2tp_nl_unregister_ops(L2TP_PWTYPE_ETH_VLAN);
+#endif
l2tp_nl_unregister_ops(L2TP_PWTYPE_ETH);
}
@@ -355,4 +424,4 @@ module_exit(l2tp_eth_exit);
MODULE_LICENSE("GPL");
MODULE_AUTHOR("James Chapman <jchapman@katalix.com>");
MODULE_DESCRIPTION("L2TP ethernet pseudowire driver");
-MODULE_VERSION("1.0");
+MODULE_VERSION("1.1");
--
1.7.0.4
^ permalink raw reply related
* [RFC PATCH 1/2] vlan: export functions to register/unregister vlan devices
From: James Chapman @ 2013-09-24 16:27 UTC (permalink / raw)
To: netdev; +Cc: James Chapman
In-Reply-To: <1380040030-6648-1-git-send-email-jchapman@katalix.com>
Export two new symbols to let external code register and unregister
vlan devices. Allow the caller to specify the name template for the
new netdev instance.
The new symbols are:
vlan_register_device
unregister_vlan_dev
---
include/linux/if_vlan.h | 11 ++++++
net/8021q/vlan.c | 82 ++++++++++++++++++++++++++++------------------
2 files changed, 61 insertions(+), 32 deletions(-)
diff --git a/include/linux/if_vlan.h b/include/linux/if_vlan.h
index 715c343..c6431d5 100644
--- a/include/linux/if_vlan.h
+++ b/include/linux/if_vlan.h
@@ -101,6 +101,8 @@ extern void vlan_vids_del_by_dev(struct net_device *dev,
const struct net_device *by_dev);
extern bool vlan_uses_dev(const struct net_device *dev);
+extern int vlan_register_device(struct net_device *real_dev, u16 vlan_id, struct net_device **dev, char *name);
+extern void unregister_vlan_dev(struct net_device *dev, struct list_head *head);
#else
static inline struct net_device *
__vlan_find_dev_deep(struct net_device *real_dev,
@@ -155,6 +157,15 @@ static inline bool vlan_uses_dev(const struct net_device *dev)
{
return false;
}
+
+static inline int vlan_register_device(struct net_device *real_dev, u16 vlan_id, struct net_device **dev, char *name)
+{
+ return -EPROTONOSUPPORT;
+}
+
+static inline void unregister_vlan_dev(struct net_device *dev, struct list_head *head)
+{
+}
#endif
static inline bool vlan_hw_offload_capable(netdev_features_t features,
diff --git a/net/8021q/vlan.c b/net/8021q/vlan.c
index 61fc573..272157c 100644
--- a/net/8021q/vlan.c
+++ b/net/8021q/vlan.c
@@ -121,6 +121,7 @@ void unregister_vlan_dev(struct net_device *dev, struct list_head *head)
/* Get rid of the vlan's reference to real_dev */
dev_put(real_dev);
}
+EXPORT_SYMBOL(unregister_vlan_dev);
int vlan_check_real_dev(struct net_device *real_dev,
__be16 protocol, u16 vlan_id)
@@ -204,18 +205,16 @@ out_vid_del:
return err;
}
-/* Attach a VLAN device to a mac address (ie Ethernet Card).
- * Returns 0 if the device was created or a negative error code otherwise.
- */
-static int register_vlan_device(struct net_device *real_dev, u16 vlan_id)
+int vlan_register_device(struct net_device *real_dev, u16 vlan_id, struct net_device **dev, char *name)
{
struct net_device *new_dev;
struct vlan_dev_priv *vlan;
struct net *net = dev_net(real_dev);
- struct vlan_net *vn = net_generic(net, vlan_net_id);
- char name[IFNAMSIZ];
int err;
+ if (!dev || !name)
+ return -EINVAL;
+
if (vlan_id >= VLAN_VID_MASK)
return -ERANGE;
@@ -223,32 +222,6 @@ static int register_vlan_device(struct net_device *real_dev, u16 vlan_id)
if (err < 0)
return err;
- /* Gotta set up the fields for the device. */
- switch (vn->name_type) {
- case VLAN_NAME_TYPE_RAW_PLUS_VID:
- /* name will look like: eth1.0005 */
- snprintf(name, IFNAMSIZ, "%s.%.4i", real_dev->name, vlan_id);
- break;
- case VLAN_NAME_TYPE_PLUS_VID_NO_PAD:
- /* Put our vlan.VID in the name.
- * Name will look like: vlan5
- */
- snprintf(name, IFNAMSIZ, "vlan%i", vlan_id);
- break;
- case VLAN_NAME_TYPE_RAW_PLUS_VID_NO_PAD:
- /* Put our vlan.VID in the name.
- * Name will look like: eth0.5
- */
- snprintf(name, IFNAMSIZ, "%s.%i", real_dev->name, vlan_id);
- break;
- case VLAN_NAME_TYPE_PLUS_VID:
- /* Put our vlan.VID in the name.
- * Name will look like: vlan0005
- */
- default:
- snprintf(name, IFNAMSIZ, "vlan%.4i", vlan_id);
- }
-
new_dev = alloc_netdev(sizeof(struct vlan_dev_priv), name, vlan_setup);
if (new_dev == NULL)
@@ -273,12 +246,57 @@ static int register_vlan_device(struct net_device *real_dev, u16 vlan_id)
if (err < 0)
goto out_free_newdev;
+ *dev = new_dev;
+
return 0;
out_free_newdev:
free_netdev(new_dev);
return err;
}
+EXPORT_SYMBOL(vlan_register_device);
+
+/* Attach a VLAN device to a mac address (ie Ethernet Card).
+ * Returns 0 if the device was created or a negative error code otherwise.
+ */
+static int register_vlan_device(struct net_device *real_dev, u16 vlan_id)
+{
+ struct net_device *new_dev;
+ struct net *net = dev_net(real_dev);
+ struct vlan_net *vn = net_generic(net, vlan_net_id);
+ char name[IFNAMSIZ];
+ int err;
+
+ /* Gotta set up the fields for the device. */
+ switch (vn->name_type) {
+ case VLAN_NAME_TYPE_RAW_PLUS_VID:
+ /* name will look like: eth1.0005 */
+ snprintf(name, IFNAMSIZ, "%s.%.4i", real_dev->name, vlan_id);
+ break;
+ case VLAN_NAME_TYPE_PLUS_VID_NO_PAD:
+ /* Put our vlan.VID in the name.
+ * Name will look like: vlan5
+ */
+ snprintf(name, IFNAMSIZ, "vlan%i", vlan_id);
+ break;
+ case VLAN_NAME_TYPE_RAW_PLUS_VID_NO_PAD:
+ /* Put our vlan.VID in the name.
+ * Name will look like: eth0.5
+ */
+ snprintf(name, IFNAMSIZ, "%s.%i", real_dev->name, vlan_id);
+ break;
+ case VLAN_NAME_TYPE_PLUS_VID:
+ /* Put our vlan.VID in the name.
+ * Name will look like: vlan0005
+ */
+ default:
+ snprintf(name, IFNAMSIZ, "vlan%.4i", vlan_id);
+ }
+
+ err = vlan_register_device(real_dev, vlan_id, &new_dev, name);
+
+ return err;
+}
static void vlan_sync_address(struct net_device *dev,
struct net_device *vlandev)
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH net] vxlan: Use RCU apis to access sk_user_data.
From: Pravin Shelar @ 2013-09-24 16:27 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, Jesse Gross
In-Reply-To: <20130924092050.2c80bc74@nehalam.linuxnetplumber.net>
On Tue, Sep 24, 2013 at 9:20 AM, Stephen Hemminger
<stephen@networkplumber.org> wrote:
> On Mon, 23 Sep 2013 22:28:21 -0700
> Pravin B Shelar <pshelar@nicira.com> wrote:
>
>>
>> +#define sk_user_data_rcu(sk) ((*((void __rcu **)&(sk)->sk_user_data)))
>
> I don't like the macro, is it just to keep sparse happy?
yes, it is for sparse.
> The name also implies that rcu_dereference() is built in.
ok, I can right separate API for rcu-set and rcu-deref.
^ permalink raw reply
* Re: [Xen-devel] [PATCH net-next] xen-netfront: convert to GRO API and advertise this feature
From: Konrad Rzeszutek Wilk @ 2013-09-24 16:30 UTC (permalink / raw)
To: Wei Liu; +Cc: netdev, Anirban Chakraborty, Ian Campbell, xen-devel
In-Reply-To: <1379779543-27122-1-git-send-email-wei.liu2@citrix.com>
On Sat, Sep 21, 2013 at 05:05:43PM +0100, Wei Liu wrote:
> Anirban was seeing netfront received MTU size packets, which downgraded
> throughput. The following patch makes netfront use GRO API which
> improves throughput for that case.
>
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> Signed-off-by: Anirban Chakraborty <abchak@juniper.net>
> Cc: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
> drivers/net/xen-netfront.c | 7 +++++--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
> index 36808bf..5664165 100644
> --- a/drivers/net/xen-netfront.c
> +++ b/drivers/net/xen-netfront.c
> @@ -952,7 +952,7 @@ static int handle_incoming_queue(struct net_device *dev,
> u64_stats_update_end(&stats->syncp);
>
> /* Pass it up. */
> - netif_receive_skb(skb);
> + napi_gro_receive(&np->napi, skb);
> }
>
> return packets_dropped;
> @@ -1051,6 +1051,8 @@ err:
> if (work_done < budget) {
> int more_to_do = 0;
>
> + napi_gro_flush(napi, false);
> +
> local_irq_save(flags);
>
> RING_FINAL_CHECK_FOR_RESPONSES(&np->rx, more_to_do);
> @@ -1371,7 +1373,8 @@ static struct net_device *xennet_create_dev(struct xenbus_device *dev)
> netif_napi_add(netdev, &np->napi, xennet_poll, 64);
> netdev->features = NETIF_F_IP_CSUM | NETIF_F_RXCSUM |
> NETIF_F_GSO_ROBUST;
> - netdev->hw_features = NETIF_F_IP_CSUM | NETIF_F_SG | NETIF_F_TSO;
> + netdev->hw_features = NETIF_F_IP_CSUM | NETIF_F_SG | NETIF_F_TSO |
> + NETIF_F_GRO;
>
> /*
> * Assume that all hw features are available for now. This set
> --
> 1.7.10.4
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
^ permalink raw reply
* Re: [PATCH 1/2] net: Toeplitz library functions
From: Ben Hutchings @ 2013-09-24 16:32 UTC (permalink / raw)
To: Tom Herbert; +Cc: davem, netdev, jesse.brandeburg
In-Reply-To: <alpine.DEB.2.02.1309231535030.23896@tomh.mtv.corp.google.com>
On Mon, 2013-09-23 at 15:41 -0700, Tom Herbert wrote:
> Introduce Toeplitz hash functions. Toeplitz is a hash used primarily in
> NICs to performan RSS flow steering. This is a software implemenation
> of that. In order to make the hash calculation efficient, we precompute
> the possible hash values for each inidividual byte of input. The input
> length is up to 40 bytes, so we make an array of cache[40][256].
The input length is up to 36 bytes, but we need an extra 31 bits in the
key so that each bit of input is multiplied by 32 bits of the key. The
first dimension should therefore be 36.
But this is still pretty big. :-/
> The implemenation was verified against MSDN "Verify RSS hash" sample
> values.
[...]
> --- /dev/null
> +++ b/lib/toeplitz.c
I'm not convinced that this is going to be useful outside of net.
> @@ -0,0 +1,66 @@
> +/*
> + * Toeplitz hash implemenation. See include/linux/toeplitz.h
> + *
> + * Copyright (c) 2011, Tom Herbert <therbert@google.com>
> + */
> +#include <linux/types.h>
> +#include <linux/kernel.h>
> +#include <linux/slab.h>
> +#include <linux/random.h>
> +#include <linux/toeplitz.h>
> +
> +struct toeplitz *toeplitz_alloc(void)
> +{
> + return kmalloc(sizeof(struct toeplitz), GFP_KERNEL);
> +}
> +
> +static u32 toeplitz_get_kval(unsigned char *key, int idx)
unsigned int idx
> +{
> + u32 v, r;
> + int off, rem;
> +
> + off = idx / 8;
> + rem = idx % 8;
Otherwise this requires a 'real' division if the compiler doesn't work
out that idx >= 0.
> + v = (((unsigned int)key[off]) << 24) +
> + (((unsigned int)key[off + 1]) << 16) +
> + (((unsigned int)key[off + 2]) << 8) +
> + (((unsigned int)key[off + 3]));
> +
> + r = v << rem | (unsigned int)key[off + 4] >> (8 - rem);
> + return r;
> +}
> +
> +static inline int idx8(int idx)
> +{
> +#ifdef __LITTLE_ENDIAN
> + idx = (idx / 8) * 8 + (8 - (idx % 8 + 1));
Or in short: idx ^= 7
> +#endif
> + return idx;
> +}
> +
> +void toeplitz_init(struct toeplitz *toeplitz, u8 *key_vals)
> +{
> + int i;
> + unsigned long a, j;
> + unsigned int result = 0;
> +
> + /* Set up key val table */
> + if (key_vals)
> + for (i = 0; i < TOEPLITZ_KEY_LEN; i++)
> + toeplitz->key_vals[i] = key_vals[i];
> + else
> + prandom_bytes(toeplitz->key_vals, TOEPLITZ_KEY_LEN);
Should have braces around the if and else bodies.
Is it worth sacrificing a little randomness here by avoiding long runs
of zeroes in the key?
> + /* Set up key cache table */
> + for (i = 0; i < TOEPLITZ_KEY_LEN; i++) {
[...]
As I said above, the outer dimension of key_cache should be 36. The
current loop causes toeplitz_get_kval() to over-run the bounds of the
key_vals array.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH 1/2] net: Toeplitz library functions
From: Tom Herbert @ 2013-09-24 16:35 UTC (permalink / raw)
To: Eric Dumazet
Cc: Hannes Frederic Sowa, David Miller, Linux Netdev List,
Brandeburg, Jesse
In-Reply-To: <1380039299.3165.91.camel@edumazet-glaptop>
On Tue, Sep 24, 2013 at 9:14 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Tue, 2013-09-24 at 18:01 +0200, Hannes Frederic Sowa wrote:
>
>> inet(6)_ehashfn does get used by udp btw. But I do not understand the code,
>> yet. ;)
>
> Oh well, thats the SO_REUSEPORT thing. We do not really care, thats only
> used to try to steer udp flows on a given socket, but its a hint.
>
> Presumably it should use a separate secret key.
>
>
We should really be using rxhash for that anyway, eliminate this
ehashfn. This would entail adding rxhash argument in the various
udp_lookup functions.
^ permalink raw reply
* Re: [PATCH 1/2] net: Toeplitz library functions
From: Ben Hutchings @ 2013-09-24 16:38 UTC (permalink / raw)
To: David Laight; +Cc: Tom Herbert, davem, netdev, jesse.brandeburg
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6026B7355@saturn3.aculab.com>
On Tue, 2013-09-24 at 09:32 +0100, David Laight wrote:
> > +static inline unsigned int
> > +toeplitz_hash(const unsigned char *bytes,
> > + struct toeplitz *toeplitz, int n)
> > +{
> > + int i;
> > + unsigned int result = 0;
> > +
> > + for (i = 0; i < n; i++)
> > + result ^= toeplitz->key_cache[i][bytes[i]];
> > +
> > + return result;
> > +};
>
> That is a horrid hash function to be calculating in software.
>
> The code looks very much like a simple 32bit CRC.
> It isn't entirely clears exactly where the 'key' gets included,
> but I suspect it is just xored with the data bytes.
Each input bit is multiplied by a 32-bit slice of the key and the
products are then bitwise-summed (i.e. xored).
[...]
> I also thought the hash was arranged so that tx and rx packets
> for a single connection hash to the same value?
Not in general. I think I saw that one of the BSDs (DragonflyBSD?)
generates Toeplitz keys with this property and has an efficient software
implementation that works for those keys. But that significantly
weakens the hash.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* [PATCH 2/2] tun: call skb_get_sw_rxhash
From: Tom Herbert @ 2013-09-24 16:21 UTC (permalink / raw)
To: davem; +Cc: netdev
tun calls skb_get_rxhash on both transmit and receive side with the
expectation that the calculation in symmetric. To ensure this
property call skb_get_sw_rxhash instead (ignores hash provided by NIC
on receive).
Signed-off-by: Tom Herbert <therbert@google.com>
---
drivers/net/tun.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 807815f..0619fdf 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -358,7 +358,7 @@ static u16 tun_select_queue(struct net_device *dev, struct sk_buff *skb)
rcu_read_lock();
numqueues = ACCESS_ONCE(tun->numqueues);
- txq = skb_get_rxhash(skb);
+ txq = skb_get_sw_rxhash(skb);
if (txq) {
e = tun_flow_find(&tun->flows[tun_hashfn(txq)], txq);
if (e)
@@ -1138,7 +1138,7 @@ static ssize_t tun_get_user(struct tun_struct *tun, struct tun_file *tfile,
skb_reset_network_header(skb);
skb_probe_transport_header(skb, 0);
- rxhash = skb_get_rxhash(skb);
+ rxhash = skb_get_sw_rxhash(skb);
netif_rx_ni(skb);
tun->dev->stats.rx_packets++;
--
1.8.4
^ permalink raw reply related
* Re: [PATCH 1/2] net: Toeplitz library functions
From: Eric Dumazet @ 2013-09-24 16:46 UTC (permalink / raw)
To: Tom Herbert
Cc: Hannes Frederic Sowa, David Miller, Linux Netdev List,
Brandeburg, Jesse
In-Reply-To: <CA+mtBx9u3-mnULxTwyWAZA4gZ6Dg-PeYYVGZibwQi7toinHJ-A@mail.gmail.com>
On Tue, 2013-09-24 at 09:35 -0700, Tom Herbert wrote:
> We should really be using rxhash for that anyway, eliminate this
> ehashfn. This would entail adding rxhash argument in the various
> udp_lookup functions.
Nope : Some NICs provide UDP rxhash only using L3 (source IP,
destination IP), not L4 (adding source & destination ports)
This is again a case where we want our own hashing.
^ permalink raw reply
* Re: [PATCH net-next v2] dev: always advertise rx_flags changes
From: Stephen Hemminger @ 2013-09-24 16:47 UTC (permalink / raw)
To: Nicolas Dichtel; +Cc: netdev, davem
In-Reply-To: <1380039692-8157-1-git-send-email-nicolas.dichtel@6wind.com>
On Tue, 24 Sep 2013 18:21:32 +0200
Nicolas Dichtel <nicolas.dichtel@6wind.com> wrote:
> diff --git a/net/core/dev.c b/net/core/dev.c
> index 5c713f2239cc..067bfbe70c4c 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -4822,7 +4822,7 @@ static void dev_change_rx_flags(struct net_device *dev, int flags)
> ops->ndo_change_rx_flags(dev, flags);
> }
>
> -static int __dev_set_promiscuity(struct net_device *dev, int inc)
> +static int __dev_set_promiscuity(struct net_device *dev, int inc, bool notif)
> {
> unsigned int old_flags = dev->flags;
> kuid_t uid;
> @@ -4865,6 +4865,10 @@ static int __dev_set_promiscuity(struct net_device *dev, int inc)
>
> dev_change_rx_flags(dev, IFF_PROMISC);
> }
> + if (notif) {
> + call_netdevice_notifiers(NETDEV_CHANGE, dev);
> + rtmsg_ifinfo(RTM_NEWLINK, dev, IFF_PROMISC);
> + }
> return 0;
> }
This is getting uglier as the conditional is added to each
function. Why not create a helper function and change callers.
static void __dev_notify_flag(dev, int flags)
{
call_netdevice_notifiers(NETDEV_CHANGE, dev);
rtmsg_ifinfo(RTM_NEWLINK, dev, flags);
}
^ permalink raw reply
* Re: SMSC 9303 support
From: Ben Hutchings @ 2013-09-24 16:51 UTC (permalink / raw)
To: Gary Thomas; +Cc: netdev
In-Reply-To: <524183D6.6040801@mlbassoc.com>
On Tue, 2013-09-24 at 06:21 -0600, Gary Thomas wrote:
> I need to support the SMSC9303 in an embedded system. I'm not
> finding any [explicit] support for this device in the latest
> mainline kernel. Did I miss something?
>
> To be clear, the SMSC9303 is a 3-port managed ethernet switch
> capable of supporting 802.1D/802.1Q directly. This switch is
> driven by a single MAC via MII/RMII and exposes the other two
> ports via physical PHYs. What I need it to do is behave like
> two external, separate devices. I was thinking that what I need
> to do is treat these as VLAN devices since the switch can manage
> the routing.
>
> Does this seem like a reasonable approach?
Linux has 'DSA' (Distributed Switch Architecture) which supports tagging
of packets to indicate which switch port they are sent or received
through. This was originally added to support some Marvell switch chips
and I don't know whether it would be suitable or extensible for this
one.
Ben.
> How do I "hook up" my normal ethernet driver to it? To the hardware
> it just looks like any other MII/RMII PHY. The device is managed
> separately via I2C. I can have that set up separately if necessary.
>
> Thanks for any pointers/ideas
>
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH 04/10] amd/7990: Remove extern from function prototypes
From: Joe Perches @ 2013-09-24 16:55 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, linux-kernel
In-Reply-To: <65ef2eba58fddc268ba0afb4de7757f073d3bb49.1379974101.git.joe@perches.com>
Hey David.
This ended up in your tree as
commit 44da5c2f523876a02336c18dbcce93449fdbf0ca
without your signoff.
Is there something I need to do differently so
your scripts add your sign-off properly or did
this manage to just slip through via some manual
git am without the -s?
^ permalink raw reply
* Re: SMSC 9303 support
From: Gary Thomas @ 2013-09-24 16:59 UTC (permalink / raw)
To: Ben Hutchings; +Cc: netdev
In-Reply-To: <1380041488.2736.41.camel@bwh-desktop.uk.level5networks.com>
On 2013-09-24 10:51, Ben Hutchings wrote:
> On Tue, 2013-09-24 at 06:21 -0600, Gary Thomas wrote:
>> I need to support the SMSC9303 in an embedded system. I'm not
>> finding any [explicit] support for this device in the latest
>> mainline kernel. Did I miss something?
>>
>> To be clear, the SMSC9303 is a 3-port managed ethernet switch
>> capable of supporting 802.1D/802.1Q directly. This switch is
>> driven by a single MAC via MII/RMII and exposes the other two
>> ports via physical PHYs. What I need it to do is behave like
>> two external, separate devices. I was thinking that what I need
>> to do is treat these as VLAN devices since the switch can manage
>> the routing.
>>
>> Does this seem like a reasonable approach?
>
> Linux has 'DSA' (Distributed Switch Architecture) which supports tagging
> of packets to indicate which switch port they are sent or received
> through. This was originally added to support some Marvell switch chips
> and I don't know whether it would be suitable or extensible for this
> one.
I've used the DSA stuff for years (worked directly with the Marvell folks
when it was being developed). It might work for this device, I'll think
some more about using it although I was hoping for a lighter weight solution.
>> How do I "hook up" my normal ethernet driver to it? To the hardware
>> it just looks like any other MII/RMII PHY. The device is managed
>> separately via I2C. I can have that set up separately if necessary.
>>
>> Thanks for any pointers/ideas
>>
>
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply
* Re: [PATCH 1/2] net: Toeplitz library functions
From: Ben Hutchings @ 2013-09-24 17:02 UTC (permalink / raw)
To: Eric Dumazet
Cc: Tom Herbert, Hannes Frederic Sowa, David Miller,
Linux Netdev List, Brandeburg, Jesse
In-Reply-To: <1380041185.3165.97.camel@edumazet-glaptop>
On Tue, 2013-09-24 at 09:46 -0700, Eric Dumazet wrote:
> On Tue, 2013-09-24 at 09:35 -0700, Tom Herbert wrote:
>
> > We should really be using rxhash for that anyway, eliminate this
> > ehashfn. This would entail adding rxhash argument in the various
> > udp_lookup functions.
>
> Nope : Some NICs provide UDP rxhash only using L3 (source IP,
> destination IP), not L4 (adding source & destination ports)
Indeed the Microsoft RSS spec doesn't define an L4 hash for UDP/IP,
since it can't work with fragmented datagrams (which TCP avoids). Using
the TCP/IP hash function for UDP is a non-standard option - presumably
useful where no fragmentation is expected.
Ben.
> This is again a case where we want our own hashing.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH 1/2] net: Add function to get SW rxhash
From: Eric Dumazet @ 2013-09-24 17:03 UTC (permalink / raw)
To: Tom Herbert; +Cc: davem, netdev
In-Reply-To: <alpine.DEB.2.02.1309240915001.24581@tomh.mtv.corp.google.com>
On Tue, 2013-09-24 at 09:20 -0700, Tom Herbert wrote:
> Some uses of skb_get_rxhash expect that the function will return
> a consistent value whether it is called on RX or TX paths. On RX
> path, we will use the rxhash if provided by the NIC, so this
> would not normally be the same result computed in TX path which is
> a software calculation.
>
> This patch adds skb_get_sw_rxhash to explicitly request a hash
> calculated by the stack, disregarding the hash provided by NIC.
>
> Signed-off-by: Tom Herbert <therbert@google.com>
> ---
1) Adding another skb field for this corner case, is it worth it ?
Computing rxhash in software should be real fast for the
cases where we really care of symmetry.
ie ignore skb->rxhash and use __skb_get_rxhash()
2) Not copying sw_rxhash in __copy_skb_header()
-> value will be undefined after a clone()
^ permalink raw reply
* Re: [PATCH 1/2] net: Toeplitz library functions
From: Tom Herbert @ 2013-09-24 17:03 UTC (permalink / raw)
To: Eric Dumazet
Cc: Hannes Frederic Sowa, David Miller, Linux Netdev List,
Brandeburg, Jesse
In-Reply-To: <1380041185.3165.97.camel@edumazet-glaptop>
On Tue, Sep 24, 2013 at 9:46 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Tue, 2013-09-24 at 09:35 -0700, Tom Herbert wrote:
>
>> We should really be using rxhash for that anyway, eliminate this
>> ehashfn. This would entail adding rxhash argument in the various
>> udp_lookup functions.
>
> Nope : Some NICs provide UDP rxhash only using L3 (source IP,
> destination IP), not L4 (adding source & destination ports)
>
Then the NIC won't set l4_rxhash and we'll rehash over 4-tuple when
skb_get_rxhash is called.
> This is again a case where we want our own hashing.
>
>
>
^ 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