* [PATCH net-next-2.6 v2 1/2] dcbnl: add support for retrieving peer configuration - ieee
From: Shmulik Ravid @ 2011-02-27 15:04 UTC (permalink / raw)
To: davem; +Cc: John Fastabend, Eilon Greenstein, netdev
These 2 patches add the support for retrieving the remote or peer DCBX
configuration via dcbnl for embedded DCBX stacks. The peer configuration
is part of the DCBX MIB and is useful for debugging and diagnostics of
the overall DCB configuration. The first patch add this support for IEEE
802.1Qaz standard the second patch add the same support for the older
CEE standard. Diff for v2 - the peer-app-info is CEE specific.
Signed-off-by: Shmulik Ravid <shmulikr@broadcom.com>
---
include/linux/dcbnl.h | 28 ++++++++++++++++++++
include/net/dcbnl.h | 6 ++++
net/dcb/dcbnl.c | 69 +++++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 103 insertions(+), 0 deletions(-)
diff --git a/include/linux/dcbnl.h b/include/linux/dcbnl.h
index 4c5b26e..2542685 100644
--- a/include/linux/dcbnl.h
+++ b/include/linux/dcbnl.h
@@ -110,6 +110,20 @@ struct dcb_app {
__u16 protocol;
};
+/**
+ * struct dcb_peer_app_info - APP feature information sent by the peer
+ *
+ * @willing: willing bit in the peer APP tlv
+ * @error: error bit in the peer APP tlv
+ *
+ * In addition to this information the full peer APP tlv also contains
+ * a table of 'app_count' APP objects defined above.
+ */
+struct dcb_peer_app_info {
+ __u8 willing;
+ __u8 error;
+};
+
struct dcbmsg {
__u8 dcb_family;
__u8 cmd;
@@ -235,11 +249,25 @@ enum dcbnl_attrs {
DCB_ATTR_MAX = __DCB_ATTR_ENUM_MAX - 1,
};
+/**
+ * enum ieee_attrs - IEEE 802.1Qaz get/set attributes
+ *
+ * @DCB_ATTR_IEEE_UNSPEC: unspecified
+ * @DCB_ATTR_IEEE_ETS: negotiated ETS configuration
+ * @DCB_ATTR_IEEE_PFC: negotiated PFC configuration
+ * @DCB_ATTR_IEEE_APP_TABLE: negotiated APP configuration
+ * @DCB_ATTR_IEEE_PEER_ETS: peer ETS configuration - get only
+ * @DCB_ATTR_IEEE_PEER_PFC: peer PFC configuration - get only
+ * @DCB_ATTR_IEEE_PEER_APP: peer APP tlv - get only
+ */
enum ieee_attrs {
DCB_ATTR_IEEE_UNSPEC,
DCB_ATTR_IEEE_ETS,
DCB_ATTR_IEEE_PFC,
DCB_ATTR_IEEE_APP_TABLE,
+ DCB_ATTR_IEEE_PEER_ETS,
+ DCB_ATTR_IEEE_PEER_PFC,
+ DCB_ATTR_IEEE_PEER_APP,
__DCB_ATTR_IEEE_MAX
};
#define DCB_ATTR_IEEE_MAX (__DCB_ATTR_IEEE_MAX - 1)
diff --git a/include/net/dcbnl.h b/include/net/dcbnl.h
index a8e7852..7b7180e 100644
--- a/include/net/dcbnl.h
+++ b/include/net/dcbnl.h
@@ -43,6 +43,8 @@ struct dcbnl_rtnl_ops {
int (*ieee_setpfc) (struct net_device *, struct ieee_pfc *);
int (*ieee_getapp) (struct net_device *, struct dcb_app *);
int (*ieee_setapp) (struct net_device *, struct dcb_app *);
+ int (*ieee_peer_getets) (struct net_device *, struct ieee_ets *);
+ int (*ieee_peer_getpfc) (struct net_device *, struct ieee_pfc *);
/* CEE std */
u8 (*getstate)(struct net_device *);
@@ -77,6 +79,10 @@ struct dcbnl_rtnl_ops {
u8 (*getdcbx)(struct net_device *);
u8 (*setdcbx)(struct net_device *, u8);
+ /* peer apps */
+ int (*peer_getappinfo)(struct net_device *, struct dcb_peer_app_info *,
+ u16 *);
+ int (*peer_getapptable)(struct net_device *, struct dcb_app *);
};
diff --git a/net/dcb/dcbnl.c b/net/dcb/dcbnl.c
index d5074a5..2e6dcf2 100644
--- a/net/dcb/dcbnl.c
+++ b/net/dcb/dcbnl.c
@@ -1224,6 +1224,54 @@ err:
return err;
}
+static int dcbnl_build_peer_app(struct net_device *netdev, struct sk_buff* skb)
+{
+ struct dcb_peer_app_info info;
+ struct dcb_app *table = NULL;
+ const struct dcbnl_rtnl_ops *ops = netdev->dcbnl_ops;
+ u16 app_count;
+ int err;
+
+
+ /**
+ * retrieve the peer app configuration form the driver. If the driver
+ * handlers fail exit without doing anything
+ */
+ err = ops->peer_getappinfo(netdev, &info, &app_count);
+ if (!err && app_count) {
+ table = kmalloc(sizeof(struct dcb_app) * app_count, GFP_KERNEL);
+ if (!table)
+ return -ENOMEM;
+
+ err = ops->peer_getapptable(netdev, table);
+ }
+
+ if (!err) {
+ u16 i;
+ struct nlattr *app;
+
+ /**
+ * build the message, from here on the only possible failure
+ * is due to the skb size
+ */
+ err = -EMSGSIZE;
+
+ app = nla_nest_start(skb, DCB_ATTR_IEEE_PEER_APP);
+ if (!app)
+ goto nla_put_failure;
+
+ for (i = 0; i < app_count; i++)
+ NLA_PUT(skb, DCB_ATTR_IEEE_APP, sizeof(struct dcb_app),
+ &table[i]);
+
+ nla_nest_end(skb, app);
+ }
+ err = 0;
+
+nla_put_failure:
+ kfree(table);
+ return err;
+}
/* Handle IEEE 802.1Qaz GET commands. */
static int dcbnl_ieee_get(struct net_device *netdev, struct nlattr **tb,
@@ -1288,6 +1336,27 @@ static int dcbnl_ieee_get(struct net_device *netdev, struct nlattr **tb,
spin_unlock(&dcb_lock);
nla_nest_end(skb, app);
+ /* get peer info if available */
+ if (ops->ieee_peer_getets) {
+ struct ieee_ets ets;
+ err = ops->ieee_peer_getets(netdev, &ets);
+ if (!err)
+ NLA_PUT(skb, DCB_ATTR_IEEE_PEER_ETS, sizeof(ets), &ets);
+ }
+
+ if (ops->ieee_peer_getpfc) {
+ struct ieee_pfc pfc;
+ err = ops->ieee_peer_getpfc(netdev, &pfc);
+ if (!err)
+ NLA_PUT(skb, DCB_ATTR_IEEE_PEER_PFC, sizeof(pfc), &pfc);
+ }
+
+ if (ops->peer_getappinfo && ops->peer_getapptable) {
+ err = dcbnl_build_peer_app(netdev, skb);
+ if (err)
+ goto nla_put_failure;
+ }
+
nla_nest_end(skb, ieee);
nlmsg_end(skb, nlh);
--
1.7.3.5
^ permalink raw reply related
* Re: [patch net-next-2.6 V3] net: convert bonding to use rx_handler
From: Jiri Pirko @ 2011-02-27 12:58 UTC (permalink / raw)
To: Jay Vosburgh
Cc: nicolas.2p.debian, David Miller, kaber, eric.dumazet, netdev,
shemminger, andy, Fischer, Anna
In-Reply-To: <27369.1298749377@death>
Sat, Feb 26, 2011 at 08:42:57PM CET, fubar@us.ibm.com wrote:
>Nicolas de Pesloüan <nicolas.2p.debian@gmail.com> wrote:
>
>>Le 22/02/2011 00:20, Nicolas de Pesloüan a écrit :
>>
>>> After checking every protocol handlers installed by dev_add_pack(), it
>>> appears that only 4 of them really use the orig_dev parameter given by
>>> __netif_receive_skb():
>>>
>>> - bond_3ad_lacpdu_recv() @ drivers/net/bonding/bond_3ad.c
>>> - bond_arp_recv() @ drivers/net/bonding/bond_main.c
>>> - packet_rcv() @ net/packet/af_packet.c
>>> - tpacket_rcv() @ net/packet/af_packet.c
>>>
>>> From the bonding point of view, the meaning of orig_dev is obviously
>>> "the device one layer below the bonding device, through which the packet
>>> reached the bonding device". It is used by bond_3ad_lacpdu_recv() and
>>> bond_arp_recv(), to find the underlying slave device through which the
>>> LACPDU or ARP was received. (The protocol handler is registered at the
>>> bonding device level).
>>>
>>> From the af_packet point of view, the meaning is documented (in commit
>>> "[AF_PACKET]: Add option to return orig_dev to userspace") as the
>>> "physical device [that] actually received the traffic, instead of having
>>> the encapsulating device hide that information."
>>>
>>> When the bonding device is just one level above the physical device, the
>>> two meanings happen to match the same device, by chance.
>>>
>>> So, currently, a bonding device cannot stack properly on top of anything
>>> but physical devices. It might not be a problem today, but may change in
>>> the future...
>>
>>Hi Jay,
>>
>>Still thinking about this orig_dev stuff, I wonder why the protocol
>>handlers used in bonding (bond_3ad_lacpdu_recv() and bond_arp_rcv()) are
>>registered at the master level instead of at the slave level ?
>>
>>If they were registered at the slave level, they would simply receive
>>skb->dev as the ingress interface and use this value instead of needing
>>the orig_dev value given to them when they are registered at the master
>>level.
>>
>>As orig_dev is only used by bonding and by af_packet, but they disagree on
>>the exact meaning of orig_dev, one way to fix this discrepancy would be to
>>remove one of the usage. As the af_packet usage is exposed to user space,
>>bonding seems the right place to stop using orig_dev, even if orig_dev was
>>introduced for bonding :-)
>>
>>I understand that this would add one entry per slave device to the
>>ptype_base list, but this seems to be the only bad effect of registering
>>at the slave level. Can you confirm that this was the reason to register
>>at the master level instead?
>
> My recollection is that it was done the way it is because there
>was no "orig_dev" delivery logic at the time. A handler registered to a
>slave dev would receive no packets at all because assignment of skb->dev
>to the master happened first, and the "orig_dev" knowledge was lost.
>
> When 802.3ad was added, a skb->real_dev field was created, but
>it wasn't used for delivery. 802.3ad used real_dev to figure out which
>slave a LACPDU arrived on. The skb->real_dev was eventually replaced
>with the orig_dev business that's there now.
>
> Later, I did the arp_validate stuff the same way as 802.3ad
>because it worked and was easier than registering a handler per slave.
>
>>If you think registering at the slave level would cause too much impact on
>>ptype_base, then we might have another way to stop using orig_dev for
>>bonding:
>>
>>In __skb_bond_should_drop(), we already test for the two interesting protocols:
>>
>>if ((dev->priv_flags & IFF_SLAVE_NEEDARP) && skb->protocol == __cpu_to_be16(ETH_P_ARP))
>> return 0;
>>
>>if (master->priv_flags & IFF_MASTER_8023AD && skb->protocol == __cpu_to_be16(ETH_P_SLOW))
>> return 0;
>>
>>Would it be possible to call the right handlers directly from inside
>>__skb_bond_should_drop() then let __skb_bond_should_drop() return 1
>>("should drop") after processing the frames that are only of interest for
>>bonding?
>
> Isn't one purpose of switching to rx_handler that there won't
>need to be any skb_bond_should_drop logic in __netif_receive_skb at all?
Yes, that (hopefully most) would be eventually removed.
>
> Still, if you're just trying to simplify __netif_receive_skb
>first, I don't see any reason not to register the packet handlers at the
>slave level. Looking at the ptype_base hash, I don't think that the
>protocols bonding is registering (ARP and SLOW) will hash collide with
>IP or IPv6, so I suspect there won't be much impact.
>
> Once an rx_handler is used, then I suspect there's no need for
>the packet handlers at all, since the rx_handler is within bonding and
>can just deal with the ARP or LACPDU directly.
That is very true. And given that af_packet uses orig_dev to obtain
ifindex, it can be replaced by skb->skb_iif. That way we can get rid of
orig_dev parameter for good.
So I suggest to take V3 of my patch now and do multiple follow-on
patches to get us where we want to get.
Thanks
>
> -J
>
>---
> -Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
^ permalink raw reply
* Re: [PATCH] don't allow CAP_NET_ADMIN to load non-netdev kernel modules
From: Vasiliy Kulikov @ 2011-02-27 11:44 UTC (permalink / raw)
To: David Miller
Cc: bhutchings, netdev, linux-kernel, kuznet, pekkas, jmorris,
yoshfuji, kaber, eric.dumazet, therbert, xiaosuo, jesse,
kees.cook, eugene, dan.j.rosenberg, akpm
In-Reply-To: <20110225.111606.115927805.davem@davemloft.net>
David,
On Fri, Feb 25, 2011 at 11:16 -0800, David Miller wrote:
> From: Ben Hutchings <bhutchings@solarflare.com>
> Date: Fri, 25 Feb 2011 19:07:59 +0000
>
> > You realise that module loading doesn't actually run in the context of
> > request_module(), right?
>
> Why is that a barrier? We could simply pass a capability mask into
> request_module if necessary.
>
> It's an implementation detail, and not a deterrant to my suggested
> scheme.
Let's discuss your scheme. AFAIU, you suggest to change:
1. a) request_module("%s", devname) =>
request_module_with_caps(CAP_NET_ADMIN, "%s", devname)
b) call_usermodehelper() => call_usermodehelper_with_caps()
c) add some bits/sections into kernel module image indicating that
this module is safe to be loaded via CAP_NET_ADMIN
d) run modprobe with CAP_NET_ADMIN only
e) in load_module() check whether (the process has CAP_SYS_MODULE) or
(the process has CAP_NET_ADMIN and bit SAFE_NET_MODULE is raised in
the module image)
This obviously doesn't work - the kernel is not able to verify whether
the bit/section is not malformed by user with CAP_NET_ADMIN.
-OR-
1. a) request_module("%s", devname) => request_module_with_argument("--netdev", "%s", devname)
b) patch modprobe to add "--netmodule-only" argument (or bitmask,
whatever), this would indicate that only net/** modules may be loaded.
Then the things are still broken - a user has to update modprobe
together with the kernel, otherwise the updated kernel would call
"modprobe" with unsupported argument and even "sit0" wouldn't work.
Additionally this touches module loading process, which is not buggy.
Or you propose something else besides these 2 ways? Please clarify.
Thanks,
--
Vasiliy Kulikov
http://www.openwall.com - bringing security into open computing environments
^ permalink raw reply
* Re: SO_REUSEPORT - can it be done in kernel?
From: Herbert Xu @ 2011-02-27 11:06 UTC (permalink / raw)
To: David Miller, rick.jones2, therbert, wsommerfeld, daniel.baluta,
netdev
In-Reply-To: <20110227110205.GE9763@canuck.infradead.org>
On Sun, Feb 27, 2011 at 06:02:05AM -0500, Thomas Graf wrote:
>
> I still suggest to merge this patch as a immediate workaround fix
> until we scale properly on a single socket and also as a workaround
> for applications which can't get rid of their per socket mutex quickly.
I disagree completely.
This patch adds a user-space API that we will have to carry
with us for perpetuity. I would only support this if we had
no other way around the problem.
If this does turn out to be mostly due to sendmsg contention
then fixing it is going to be much simpler than making the UDP
stack multiqueue capable.
I'm working on this right now.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: txqueuelen has wrong units; should be time
From: Jussi Kivilinna @ 2011-02-27 10:55 UTC (permalink / raw)
To: Albert Cahalan; +Cc: Eric Dumazet, Mikael Abrahamsson, linux-kernel, netdev
In-Reply-To: <AANLkTinyE10wtM_xJsufT_3s3hvti7CN+9nyqScWa6SA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1423 bytes --]
Quoting Albert Cahalan <acahalan@gmail.com>:
> On Sun, Feb 27, 2011 at 2:54 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>> Le dimanche 27 février 2011 à 08:02 +0100, Mikael Abrahamsson a écrit :
>>> On Sun, 27 Feb 2011, Albert Cahalan wrote:
>>>
>>> > Nanoseconds seems fine; it's unlikely you'd ever want
>>> > more than 4.2 seconds (32-bit unsigned) of queue.
> ...
>> Problem is some machines have slow High Resolution timing services.
>>
>> _If_ we have a time limit, it will probably use the low resolution (aka
>> jiffies), unless high resolution services are cheap.
>
> As long as that is totally internal to the kernel and never
> getting exposed by some API for setting the amount, sure.
>
>> I was thinking not having an absolute hard limit, but an EWMA based one.
>
> The whole point is to prevent stale packets, especially to prevent
> them from messing with TCP, so I really don't think so. I suppose
> you do get this to some extent via early drop.
I made simple hack on sch_fifo with per packet time limits
(attachment) this weekend and have been doing limited testing on
wireless link. I think hardlimit is fine, it's simple and does
somewhat same as what packet(-hard)limited buffer does, drops packets
when buffer is 'full'. My hack checks for timed out packets on
enqueue, might be wrong approach (on other hand might allow some more
burstiness).
-Jussi
[-- Attachment #2: sch_fifo_to.c --]
[-- Type: text/x-csrc, Size: 6138 bytes --]
/*
* sch_fifo_timeout.c Simple FIFO queue with per packet timeout.
*
* This program is free software; you can redistribute it and/or modify it under
* the terms of the GNU General Public License as published by the Free Software
* Foundation; either version 2 of the License, or (at your option) any later
* version.
*
*/
#include <linux/module.h>
#include <linux/slab.h>
#include <linux/types.h>
#include <linux/kernel.h>
#include <linux/errno.h>
#include <linux/skbuff.h>
#include <net/pkt_sched.h>
#include <net/inet_ecn.h>
#define DEFAULT_TIMEOUT_PKT_MS 10
#define DEFAULT_TIMEOUT_PKT PSCHED_NS2TICKS((u64)NSEC_PER_SEC * \
DEFAULT_TIMEOUT_PKT_MS / 1000)
struct tc_fifo_timeout_qopt {
__u64 timeout; /* Max time packet may stay in buffer */
__u32 limit; /* Queue length: bytes for bfifo, packets for pfifo */
};
struct fifo_timeout_skb_cb {
psched_time_t time_queued;
};
struct fifo_timeout_sched_data {
psched_tdiff_t timeout;
u32 limit;
};
static inline
struct fifo_timeout_skb_cb *fifo_timeout_skb_cb(struct sk_buff *skb)
{
BUILD_BUG_ON(sizeof(skb->cb) <
sizeof(struct qdisc_skb_cb) +
sizeof(struct fifo_timeout_skb_cb));
return (struct fifo_timeout_skb_cb *)qdisc_skb_cb(skb)->data;
}
static void pfifo_timeout_drop_timedout_packets(struct Qdisc *sch,
psched_time_t now)
{
struct fifo_timeout_sched_data *q = qdisc_priv(sch);
struct sk_buff *skb;
check_next:
skb = qdisc_peek_head(sch);
if (likely(!skb))
return;
if (likely(fifo_timeout_skb_cb(skb)->time_queued + q->timeout > now))
return;
__qdisc_queue_drop_head(sch, &sch->q);
sch->qstats.drops++;
goto check_next;
}
static int pfifo_tail_enqueue(struct sk_buff *skb, struct Qdisc* sch)
{
struct fifo_timeout_sched_data *q = qdisc_priv(sch);
if (likely(skb_queue_len(&sch->q) < q->limit))
return qdisc_enqueue_tail(skb, sch);
/* queue full, remove one skb to fulfill the limit */
__qdisc_queue_drop_head(sch, &sch->q);
sch->qstats.drops++;
qdisc_enqueue_tail(skb, sch);
return NET_XMIT_CN;
}
static int bfifo_enqueue(struct sk_buff *skb, struct Qdisc* sch)
{
struct fifo_timeout_sched_data *q = qdisc_priv(sch);
if (likely(sch->qstats.backlog + qdisc_pkt_len(skb) <= q->limit))
return qdisc_enqueue_tail(skb, sch);
return qdisc_reshape_fail(skb, sch);
}
static int pfifo_enqueue(struct sk_buff *skb, struct Qdisc* sch)
{
struct fifo_timeout_sched_data *q = qdisc_priv(sch);
if (likely(skb_queue_len(&sch->q) < q->limit))
return qdisc_enqueue_tail(skb, sch);
return qdisc_reshape_fail(skb, sch);
}
static int pfifo_timeout_tail_enqueue(struct sk_buff *skb, struct Qdisc* sch)
{
psched_time_t now = psched_get_time();
fifo_timeout_skb_cb(skb)->time_queued = now;
pfifo_timeout_drop_timedout_packets(sch, now);
return pfifo_tail_enqueue(skb, sch);
}
static int bfifo_timeout_enqueue(struct sk_buff *skb, struct Qdisc* sch)
{
psched_time_t now = psched_get_time();
fifo_timeout_skb_cb(skb)->time_queued = now;
pfifo_timeout_drop_timedout_packets(sch, now);
return bfifo_enqueue(skb, sch);
}
static int pfifo_timeout_enqueue(struct sk_buff *skb, struct Qdisc* sch)
{
psched_time_t now = psched_get_time();
fifo_timeout_skb_cb(skb)->time_queued = now;
pfifo_timeout_drop_timedout_packets(sch, now);
return pfifo_enqueue(skb, sch);
}
static int fifo_timeout_init(struct Qdisc *sch, struct nlattr *opt)
{
struct fifo_timeout_sched_data *q = qdisc_priv(sch);
if (opt == NULL) {
u32 limit = qdisc_dev(sch)->tx_queue_len ? : 1;
q->limit = limit;
q->timeout = DEFAULT_TIMEOUT_PKT;
} else {
struct tc_fifo_timeout_qopt *ctl = nla_data(opt);
if (nla_len(opt) < sizeof(*ctl))
return -EINVAL;
q->limit = ctl->limit;
q->timeout = ctl->timeout ? : DEFAULT_TIMEOUT_PKT;
}
return 0;
}
static int fifo_timeout_dump(struct Qdisc *sch, struct sk_buff *skb)
{
struct fifo_timeout_sched_data *q = qdisc_priv(sch);
struct tc_fifo_timeout_qopt opt = {
.limit = q->limit,
.timeout = q->timeout
};
NLA_PUT(skb, TCA_OPTIONS, sizeof(opt), &opt);
return skb->len;
nla_put_failure:
return -1;
}
static struct Qdisc_ops pfifo_timeout_qdisc_ops __read_mostly = {
.id = "pfifo_timeout",
.priv_size = sizeof(struct fifo_timeout_sched_data),
.enqueue = pfifo_timeout_enqueue,
.dequeue = qdisc_dequeue_head,
.peek = qdisc_peek_head,
.drop = qdisc_queue_drop,
.init = fifo_timeout_init,
.reset = qdisc_reset_queue,
.change = fifo_timeout_init,
.dump = fifo_timeout_dump,
.owner = THIS_MODULE,
};
static struct Qdisc_ops bfifo_timeout_qdisc_ops __read_mostly = {
.id = "bfifo_timeout",
.priv_size = sizeof(struct fifo_timeout_sched_data),
.enqueue = bfifo_timeout_enqueue,
.dequeue = qdisc_dequeue_head,
.peek = qdisc_peek_head,
.drop = qdisc_queue_drop,
.init = fifo_timeout_init,
.reset = qdisc_reset_queue,
.change = fifo_timeout_init,
.dump = fifo_timeout_dump,
.owner = THIS_MODULE,
};
static struct Qdisc_ops pfifo_head_drop_timeout_qdisc_ops __read_mostly = {
.id = "pfifo_hd_tout",
.priv_size = sizeof(struct fifo_timeout_sched_data),
.enqueue = pfifo_timeout_tail_enqueue,
.dequeue = qdisc_dequeue_head,
.peek = qdisc_peek_head,
.drop = qdisc_queue_drop_head,
.init = fifo_timeout_init,
.reset = qdisc_reset_queue,
.change = fifo_timeout_init,
.dump = fifo_timeout_dump,
.owner = THIS_MODULE,
};
static int __init fifo_timeout_module_init(void)
{
int retval;
retval = register_qdisc(&pfifo_timeout_qdisc_ops);
if (retval)
goto cleanup;
retval = register_qdisc(&bfifo_timeout_qdisc_ops);
if (retval)
goto cleanup;
retval = register_qdisc(&pfifo_head_drop_timeout_qdisc_ops);
if (retval)
goto cleanup;
return 0;
cleanup:
unregister_qdisc(&pfifo_timeout_qdisc_ops);
unregister_qdisc(&bfifo_timeout_qdisc_ops);
unregister_qdisc(&pfifo_head_drop_timeout_qdisc_ops);
return retval;
}
static void __exit fifo_timeout_module_exit(void)
{
unregister_qdisc(&pfifo_timeout_qdisc_ops);
unregister_qdisc(&bfifo_timeout_qdisc_ops);
unregister_qdisc(&pfifo_head_drop_timeout_qdisc_ops);
}
module_init(fifo_timeout_module_init)
module_exit(fifo_timeout_module_exit)
MODULE_LICENSE("GPL");
^ permalink raw reply
* Re: SO_REUSEPORT - can it be done in kernel?
From: Thomas Graf @ 2011-02-27 11:02 UTC (permalink / raw)
To: Herbert Xu
Cc: David Miller, rick.jones2, therbert, wsommerfeld, daniel.baluta,
netdev
In-Reply-To: <20110226005718.GA19889@gondor.apana.org.au>
On Sat, Feb 26, 2011 at 08:57:18AM +0800, Herbert Xu wrote:
> I'm fairly certain the bottleneck is indeed in the kernel, and
> in the UDP stack in particular.
>
> This is born out by a test where I used two named worker threads,
> both working on the same socket. Stracing shows that they're
> working flat out only doing sendmsg/recvmsg.
>
> The result was that they obtained (in aggregate) half the throughput
> of a single worker thread.
I agree. This is the bottleneck that I described were the kernel is
not able to deliver enough queries for BIND to show the lock
contention issues.
But there is also the situation where netperf RR performance numbers
indicate a mugh higher kernel capability but BIND is not able to
deliver more even though the CPU utilization is very low. This is
the situation where we see the large number of futex calls indicating
the lock contention due to too many queries on a single socket.
> Which is why I'm quite skeptical about this REUSEPORT patch as
> IMHO the only reason it produces a great result is solely because
> it is allowing parallel sends going out.
>
> Rather than modifying all UDP applications out there to fix what
> is fundamentally a kernel problem, I think what we should do is
> fix the UDP stack so that it actually scales.
I am not suggesting that this is the ultimate and final fix for this
problem. It is fixing a symptom rather than fixing the cause but
sometimes being able to fix the symptom becomes really handy :-)
Adding SO_REUSEPORT does not prevent us from fixing the UDP stack
in the long run.
> It isn't all that hard since the easy way would be to only take
> the lock if we're already corked or about to cork.
>
> For the receive side we also don't need REUSEPORT as we can simply
> make our UDP stack multiqueue.
OK, it is not required and there is definitely a better way to fix
the kernel bottleneck in the long term. Even better.
I still suggest to merge this patch as a immediate workaround fix
until we scale properly on a single socket and also as a workaround
for applications which can't get rid of their per socket mutex quickly.
^ permalink raw reply
* Re: EPT: Misconfiguration
From: Avi Kivity @ 2011-02-27 10:46 UTC (permalink / raw)
To: Ruben Kerkhof; +Cc: Marcelo Tosatti, kvm, netdev
In-Reply-To: <AANLkTiknMneQtYqgmX7gvXsMoSO-yiLXr-dwbEej80Uy@mail.gmail.com>
Copying netdev: looks like memory corruption in the networking stack.
Archive link: http://www.spinics.net/lists/kvm/msg50651.html (for the
attachment).
On 02/24/2011 11:15 PM, Ruben Kerkhof wrote:
> >
> > On Tue, Feb 15, 2011 at 18:16, Marcelo Tosatti<mtosatti@redhat.com> wrote:
>
> >> This and the others reported. So yes, it looks something is corrupting
> >> memory. Ruben, you can try to boot with slub_debug=ZFPU kernel option.
>
> Ok, there are now only 6 vms left on this host, and I've booted it
> with the slub_debug=ZFPU option.
> After a few hours, I got the following result:
>
> 2011-02-24T21:41:30.818496+01:00 phy005 kernel:
> =============================================================================
> 2011-02-24T21:41:30.818517+01:00 phy005 kernel: BUG kmalloc-2048 (Not
> tainted): Object padding overwritten
> 2011-02-24T21:41:30.818523+01:00 phy005 kernel:
> -----------------------------------------------------------------------------
> 2011-02-24T21:41:30.818526+01:00 phy005 kernel:
> 2011-02-24T21:41:30.818530+01:00 phy005 kernel: INFO:
> 0xffff8806230752ca-0xffff8806230752cf. First byte 0x0 instead of 0x5a
> 2011-02-24T21:41:30.818534+01:00 phy005 kernel: INFO: Allocated in
> __netdev_alloc_skb+0x34/0x51 age=2231 cpu=8 pid=0
> 2011-02-24T21:41:30.818537+01:00 phy005 kernel: INFO: Freed in
> skb_release_data+0xc9/0xce age=2368 cpu=8 pid=2159
> 2011-02-24T21:41:30.818541+01:00 phy005 kernel: INFO: Slab
> 0xffffea00157a9880 objects=15 used=13 fp=0xffff8806230752d0
> flags=0x40000000004083
> 2011-02-24T21:41:30.818545+01:00 phy005 kernel: INFO: Object
> 0xffff880623074a88 @offset=19080 fp=0xffff8806230752d0
>
> The rest of the output is attached since it's quite large.
>
> Kind regards,
>
> Ruben
--
error compiling committee.c: too many arguments to function
^ permalink raw reply
* [PATCH nex-next] netdevice: make initial group visible to userspace
From: Vlad Dogaru @ 2011-02-27 8:39 UTC (permalink / raw)
To: NetDev; +Cc: Stephen Hemminger, David Miller, Patrick McHardy
In-Reply-To: <20110225124345.0d691789@nehalam>
On Fri, Feb 25, 2011 at 12:43:45PM -0800, Stephen Hemminger wrote:
> On Wed, 2 Feb 2011 20:23:40 +0200
> Vlad Dogaru <ddvlad@rosedu.org> wrote:
>
> > User can specify device group to list by using the group keyword:
> >
> > ip link show group test
> >
> > If no group is specified, 0 (default) is implied.
> >
> > Signed-off-by: Vlad Dogaru <ddvlad@rosedu.org>
>
> I applied this to net-next for iproute2
> but INIT_NETDEV_GROUP is in a part of netdevice.h that is not exported
> (ie inside #ifdef KERNEL).
Sorry, here is a patch for net-next that fixes the issue:
[PATCH net-next] netdevice: make initial group visible to userspace
INIT_NETDEV_GROUP is needed by userspace, move it outside __KERNEL__
guards.
Signed-off-by: Vlad Dogaru <ddvlad@rosedu.org>
---
include/linux/netdevice.h | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index ffe56c1..8be4056 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -75,9 +75,6 @@ struct wireless_dev;
#define NET_RX_SUCCESS 0 /* keep 'em coming, baby */
#define NET_RX_DROP 1 /* packet dropped */
-/* Initial net device group. All devices belong to group 0 by default. */
-#define INIT_NETDEV_GROUP 0
-
/*
* Transmit return codes: transmit return codes originate from three different
* namespaces:
@@ -141,6 +138,9 @@ static inline bool dev_xmit_complete(int rc)
#define MAX_ADDR_LEN 32 /* Largest hardware address length */
+/* Initial net device group. All devices belong to group 0 by default. */
+#define INIT_NETDEV_GROUP 0
+
#ifdef __KERNEL__
/*
* Compute the worst case header length according to the protocols
--
1.7.1
^ permalink raw reply related
* Re: txqueuelen has wrong units; should be time
From: Albert Cahalan @ 2011-02-27 8:27 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Mikael Abrahamsson, linux-kernel, netdev
In-Reply-To: <1298793252.8726.45.camel@edumazet-laptop>
On Sun, Feb 27, 2011 at 2:54 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le dimanche 27 février 2011 à 08:02 +0100, Mikael Abrahamsson a écrit :
>> On Sun, 27 Feb 2011, Albert Cahalan wrote:
>>
>> > Nanoseconds seems fine; it's unlikely you'd ever want
>> > more than 4.2 seconds (32-bit unsigned) of queue.
...
> Problem is some machines have slow High Resolution timing services.
>
> _If_ we have a time limit, it will probably use the low resolution (aka
> jiffies), unless high resolution services are cheap.
As long as that is totally internal to the kernel and never
getting exposed by some API for setting the amount, sure.
> I was thinking not having an absolute hard limit, but an EWMA based one.
The whole point is to prevent stale packets, especially to prevent
them from messing with TCP, so I really don't think so. I suppose
you do get this to some extent via early drop.
^ permalink raw reply
* Re: txqueuelen has wrong units; should be time
From: Eric Dumazet @ 2011-02-27 7:54 UTC (permalink / raw)
To: Mikael Abrahamsson; +Cc: Albert Cahalan, linux-kernel, netdev
In-Reply-To: <alpine.DEB.1.10.1102270758580.11974@uplift.swm.pp.se>
Le dimanche 27 février 2011 à 08:02 +0100, Mikael Abrahamsson a écrit :
> On Sun, 27 Feb 2011, Albert Cahalan wrote:
>
> > Nanoseconds seems fine; it's unlikely you'd ever want
> > more than 4.2 seconds (32-bit unsigned) of queue.
>
> I think this is shortsighted and I'm sure someone will come up with a case
> where 4.2 seconds isn't enough. Let's not build in those kinds of
> limitations from start.
>
> Why not make it 64bit and go to picoseconds from start?
>
> If you need to make it 32bit unsigned, I'd suggest to start from
> microseconds instead. It's less likely someone would want less than a
> microsecond of queue, than someone wanting more than 4.2 seconds of queue.
>
32 or 64 bits doesnt matter a lot. At Qdisc stage we have up to 40 bytes
available in skb->sb[] for our usage.
Problem is some machines have slow High Resolution timing services.
_If_ we have a time limit, it will probably use the low resolution (aka
jiffies), unless high resolution services are cheap.
I was thinking not having an absolute hard limit, but an EWMA based one.
^ permalink raw reply
* Re: txqueuelen has wrong units; should be time
From: Mikael Abrahamsson @ 2011-02-27 7:02 UTC (permalink / raw)
To: Albert Cahalan; +Cc: linux-kernel, netdev
In-Reply-To: <AANLkTimd5GQwtUFP2fD_An=M8ajBD8DJpzxQJezv8fB8@mail.gmail.com>
On Sun, 27 Feb 2011, Albert Cahalan wrote:
> Nanoseconds seems fine; it's unlikely you'd ever want
> more than 4.2 seconds (32-bit unsigned) of queue.
I think this is shortsighted and I'm sure someone will come up with a case
where 4.2 seconds isn't enough. Let's not build in those kinds of
limitations from start.
Why not make it 64bit and go to picoseconds from start?
If you need to make it 32bit unsigned, I'd suggest to start from
microseconds instead. It's less likely someone would want less than a
microsecond of queue, than someone wanting more than 4.2 seconds of queue.
--
Mikael Abrahamsson email: swmike@swm.pp.se
^ permalink raw reply
* Re: [patch 1/1] [PATCH] qeth: remove needless IPA-commands in offline
From: David Miller @ 2011-02-27 6:41 UTC (permalink / raw)
To: frank.blaschka; +Cc: netdev, linux-s390, ursula.braun
In-Reply-To: <20110218142343.763210392@de.ibm.com>
From: frank.blaschka@de.ibm.com
Date: Fri, 18 Feb 2011 15:22:59 +0100
> From: Ursula Braun <ursula.braun@de.ibm.com>
>
> If a qeth device is set offline, data and control subchannels are
> cleared, which means removal of all IP Assist Primitive settings
> implicitly. There is no need to delete those settings explicitly.
> This patch removes all IP Assist invocations from offline.
>
> Signed-off-by: Ursula Braun <ursula.braun@de.ibm.com>
> Signed-off-by: Frank Blaschka <frank.blaschka@de.ibm.com>
Applied.
^ permalink raw reply
* Re: net-next: warnings from sysctl_net_exit
From: David Miller @ 2011-02-27 6:23 UTC (permalink / raw)
To: shemminger; +Cc: adobriyan, netdev
In-Reply-To: <20110226165601.48858003@nehalam>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Sat, 26 Feb 2011 16:56:01 -0800
> Seeing lots of these messages in dmesg. Something is broken
> recently in net-next.
Did you by change pull plain net-2.6 into that tree? Because one
commit which is in net-2.6 but not in net-next-2.6 catches my eye:
commit c486da34390846b430896a407b47f0cea3a4189c
Author: Lucian Adrian Grijincu <lucian.grijincu@gmail.com>
Date: Thu Feb 24 19:48:03 2011 +0000
sysctl: ipv6: use correct net in ipv6_sysctl_rtcache_flush
Before this patch issuing these commands:
fd = open("/proc/sys/net/ipv6/route/flush")
unshare(CLONE_NEWNET)
write(fd, "stuff")
would flush the newly created net, not the original one.
The equivalent ipv4 code is correct (stores the net inside ->extra1).
Acked-by: Daniel Lezcano <daniel.lezcano@free.fr>
Signed-off-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* Re: dccp: Change maintainer
From: David Miller @ 2011-02-27 5:47 UTC (permalink / raw)
To: acme; +Cc: netdev
In-Reply-To: <20110227022854.GB19108@ghostprotocols.net>
From: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
Date: Sat, 26 Feb 2011 23:28:54 -0300
> Today was as good as any other day, but I felt I had to do things I love
> to when paying hommage to somebody I love, so please apply this one,
> something he would be proud of, even if so geekly.
I think you're trying to say "I wish people would sending me DCCP bug
reports, damn..." :-)
> Way past it was/is deserved.
>
> Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Applied, thanks.
^ permalink raw reply
* txqueuelen has wrong units; should be time
From: Albert Cahalan @ 2011-02-27 5:44 UTC (permalink / raw)
To: linux-kernel, netdev
(thinking about the bufferbloat problem here)
Setting txqueuelen to some fixed number of packets
seems pretty broken if:
1. a link can vary in speed (802.11 especially)
2. a packet can vary in size (9 KiB jumbograms, etc.)
3. there is other weirdness (PPP compression, etc.)
It really needs to be set to some amount of time,
with the OS accounting for packets in terms of the
time it will take to transmit them. This would need
to account for physical-layer packet headers and
minimum spacing requirements.
I think it could also account for estimated congestion
on the local link, because that effects the rate at which
the queue can empty. An OS can directly observe this
on some types of hardware.
Nanoseconds seems fine; it's unlikely you'd ever want
more than 4.2 seconds (32-bit unsigned) of queue.
I guess there are at least 2 queues of interest, with the
second one being under control of the hardware driver.
Having the kernel split the max time as appropriate for
the hardware seems nicest.
^ permalink raw reply
* dccp: Change maintainer
From: Arnaldo Carvalho de Melo @ 2011-02-27 2:28 UTC (permalink / raw)
To: David S. Miller; +Cc: Linux Networking Development Mailing List
Today was as good as any other day, but I felt I had to do things I love
to when paying hommage to somebody I love, so please apply this one,
something he would be proud of, even if so geekly.
Way past it was/is deserved.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
diff --git a/MAINTAINERS b/MAINTAINERS
index 5dd6c75..1752436 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2026,7 +2026,7 @@ F: Documentation/scsi/dc395x.txt
F: drivers/scsi/dc395x.*
DCCP PROTOCOL
-M: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
+M: Gerrit Renker <gerrit@erg.abdn.ac.uk>
L: dccp@vger.kernel.org
W: http://www.linuxfoundation.org/collaborate/workgroups/networking/dccp
S: Maintained
^ permalink raw reply related
* Re: [net-next-2.6 PATCH 01/10] ethtool: prevent null pointer dereference with NTUPLE set but no set_rx_ntuple
From: Alexander Duyck @ 2011-02-27 2:16 UTC (permalink / raw)
To: David Miller; +Cc: alexander.h.duyck, bhutchings, jeffrey.t.kirsher, netdev
In-Reply-To: <20110226.160747.226765885.davem@davemloft.net>
On Sat, Feb 26, 2011 at 4:07 PM, David Miller <davem@davemloft.net> wrote:
> From: Alexander Duyck <alexander.h.duyck@intel.com>
> Date: Fri, 25 Feb 2011 16:40:13 -0800
>
>> It cannot occur with any of the in-kernel drivers since they all set
>> the NETIF_F_NTUPLE flag and have the function defined. However going
>> forward I would like to have the option of using the network flow
>> classifier interface instead of the set_rx_ntuple interface due to the
>> fact that it supports many of the features I needed.
>
> This still doesn't explain to me why a driver would set the feature
> flag, but not actually implement the feature.
Actually the reason I ran into this is because of the patches in the
RFC set. Basically I was looking at moving the ntuple support in
ixgbe over to network flow classifier rules. As such I was leaving
the ntuple flag set, but using set_rxnfc via the filter rules instead.
If you recommend adding a new flag to do that I am fine with that.
> I'm not applying this patch.
>
> When you create the situation that causes the potentially NULL
> dereference, then you can use that patch to show why this seemingly
> illogical situation can indeed occur.
>
> Until then no driver causes this issue, therefore the problem does
> not exist.
I'll do some digging late next week to see if there are any other
means of encountering the issue and will get back to you if I find
anything.
Thanks,
Alex
^ permalink raw reply
* net-next: warnings from sysctl_net_exit
From: Stephen Hemminger @ 2011-02-27 0:56 UTC (permalink / raw)
To: Alexey Dobriyan, David Miller; +Cc: netdev
Seeing lots of these messages in dmesg. Something is broken
recently in net-next.
[26207.669668] ------------[ cut here ]------------
[26207.669673] WARNING: at net/sysctl_net.c:84 sysctl_net_exit+0x2a/0x2c()
[26207.669675] Hardware name: System Product Name
[26207.669676] Modules linked in: ip6table_filter ip6_tables nfs lockd fscache nfs_acl auth_rpcgss sunrpc binfmt_misc ebtable_nat ebtables ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack ipt_REJECT xt_tcpudp iptable_filter ip_tables x_tables bridge stp llc kvm_intel kvm snd_hda_codec_analog lm63 snd_hda_intel snd_hda_codec snd_hwdep radeon pl2303 snd_pcm snd_seq_midi snd_rawmidi snd_seq_midi_event ttm drm_kms_helper snd_seq drm usbserial i7core_edac snd_timer snd_seq_device snd sky2 e1000e edac_core psmouse igb serio_raw soundcore snd_page_alloc i2c_algo_bit asus_atk0110 hid_belkin usbhid hid pata_marvell ahci libahci dca floppy btrfs lzo_compress zlib_deflate crc32c libcrc32c
[26207.669725] Pid: 67, comm: kworker/u:5 Tainted: G W 2.6.38-rc5-net-next+ #38
[26207.669726] Call Trace:
[26207.669731] [<ffffffff81040dd2>] ? warn_slowpath_common+0x85/0x9d
[26207.669735] [<ffffffff813617f6>] ? cleanup_net+0x0/0x19a
[26207.669738] [<ffffffff81040e04>] ? warn_slowpath_null+0x1a/0x1c
[26207.669740] [<ffffffff814154ad>] ? sysctl_net_exit+0x2a/0x2c
[26207.669742] [<ffffffff8136144e>] ? ops_exit_list+0x2a/0x5b
[26207.669745] [<ffffffff813618f0>] ? cleanup_net+0xfa/0x19a
[26207.669749] [<ffffffff810575c1>] ? process_one_work+0x233/0x3aa
[26207.669752] [<ffffffff81057528>] ? process_one_work+0x19a/0x3aa
[26207.669755] [<ffffffff810599c2>] ? worker_thread+0x13b/0x25a
[26207.669757] [<ffffffff81059887>] ? worker_thread+0x0/0x25a
[26207.669760] [<ffffffff8105d0f5>] ? kthread+0x9d/0xa5
[26207.669763] [<ffffffff8106d618>] ? trace_hardirqs_on_caller+0x10c/0x130
[26207.669766] [<ffffffff810030d4>] ? kernel_thread_helper+0x4/0x10
[26207.669770] [<ffffffff8142f300>] ? restore_args+0x0/0x30
[26207.669772] [<ffffffff8105d058>] ? kthread+0x0/0xa5
[26207.669774] [<ffffffff810030d0>] ? kernel_thread_helper+0x0/0x10
[26207.669776] ---[ end trace 0cd6e119ada0eab1 ]---
^ permalink raw reply
* Re: [net-next-2.6 PATCH 01/10] ethtool: prevent null pointer dereference with NTUPLE set but no set_rx_ntuple
From: David Miller @ 2011-02-27 0:07 UTC (permalink / raw)
To: alexander.h.duyck; +Cc: bhutchings, jeffrey.t.kirsher, netdev
In-Reply-To: <4D684BED.20805@intel.com>
From: Alexander Duyck <alexander.h.duyck@intel.com>
Date: Fri, 25 Feb 2011 16:40:13 -0800
> It cannot occur with any of the in-kernel drivers since they all set
> the NETIF_F_NTUPLE flag and have the function defined. However going
> forward I would like to have the option of using the network flow
> classifier interface instead of the set_rx_ntuple interface due to the
> fact that it supports many of the features I needed.
This still doesn't explain to me why a driver would set the feature
flag, but not actually implement the feature.
I'm not applying this patch.
When you create the situation that causes the potentially NULL
dereference, then you can use that patch to show why this seemingly
illogical situation can indeed occur.
Until then no driver causes this issue, therefore the problem does
not exist.
^ permalink raw reply
* Re: [net-next-2.6 PATCH 02/10] ethtool: add ntuple flow specifier to network flow classifier
From: David Miller @ 2011-02-27 0:05 UTC (permalink / raw)
To: alexander.h.duyck; +Cc: jeffrey.t.kirsher, bhutchings, netdev
In-Reply-To: <20110225233249.7920.70334.stgit@gitlad.jf.intel.com>
From: Alexander Duyck <alexander.h.duyck@intel.com>
Date: Fri, 25 Feb 2011 15:32:49 -0800
> @@ -396,8 +411,10 @@ struct ethtool_rx_flow_spec {
> struct ethtool_ah_espip4_spec esp_ip4_spec;
> struct ethtool_usrip4_spec usr_ip4_spec;
> struct ethhdr ether_spec;
> + struct ethtool_ntuple_spec_ext ntuple_spec;
> __u8 hdata[72];
> } h_u, m_u;
> + __u32 flow_type_ext;
> __u64 ring_cookie;
> __u32 location;
> };
How can you add this flow_type_ext member to this user visible structure
without utterly breaking userspace? It changes the offsets of the
ring_cookie and location members.
^ permalink raw reply
* IPv6 source address selection and privacy extensions
From: Bruno Prémont @ 2011-02-26 22:16 UTC (permalink / raw)
To: netdev
>From Documentation/networking/ip-sysctl.txt:
use_tempaddr - INTEGER
Preference for Privacy Extensions (RFC3041).
<= 0 : disable Privacy Extensions
== 1 : enable Privacy Extensions, but prefer public
addresses over temporary addresses.
> 1 : enable Privacy Extensions and prefer temporary
addresses over public addresses.
Default: 0 (for most devices)
-1 (for point-to-point devices and loopback devices)
Is it possible with current kernel to have >1 make temporary addresses
used by default but have manual or dynamic (e.g. MAC based) address used
for some destination addresses/subnets?
If it's possible, how can this be done (adding a hint to ip-sysctl.txt
would then make it easy for others to find)
With IPv4 this can be done via `ip route add $subnet/$prefix src $addr`
though the same does not work for IPv6.
Thanks,
Bruno
^ permalink raw reply
* Re: [RFC] be2net: add rxhash support
From: Ajit Khaparde @ 2011-02-26 21:11 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
> From: Eric Dumazet [mailto:eric.dumazet@gmail.com]
> Sent: Saturday, February 26, 2011 4:31 AM
> To: Khaparde, Ajit
> Cc: netdev@vger.kernel.org
> Subject: Re: [RFC] be2net: add rxhash support
>
> Le vendredi 25 février 2011 à 15:35 -0600, Ajit Khaparde a écrit :
>
> > I asked that because, if a switch is part a of the configuration,
> > the ASIC can receive packets other than the tcp flow.
> >
> > And if hashing is enabled for IP packets, we can see this behavior.
> > The other values indicate that hashing has been enabled for IPv4
> packets.
>
> To make sure RSS (and rxhash) was OK, I added following debugging aid :
>
> diff --git a/include/net/sock.h b/include/net/sock.h
> index da0534d..e9b1180 100644
> --- a/include/net/sock.h
> +++ b/include/net/sock.h
> @@ -688,6 +688,7 @@ static inline void sock_rps_save_rxhash(struct sock
> *sk, u32 rxhash)
> {
> #ifdef CONFIG_RPS
> if (unlikely(sk->sk_rxhash != rxhash)) {
> + pr_err("rxhash change from %x to %x\n", sk->sk_rxhash,
> rxhash);
> sock_rps_reset_flow(sk);
> sk->sk_rxhash = rxhash;
> }
>
>
> And got following traces :
>
> [ 201.170297] change rxhash from 0 to be0b5a87
> [ 232.607474] bonding: bond1: Setting eth3 as active slave.
> [ 232.607478] bonding: bond1: making interface eth3 the new active
> one.
> [ 232.710848] change rxhash from be0b5a87 to e56a3c1e
> [ 300.047500] bonding: bond1: Setting eth1 as active slave.
> [ 300.047504] bonding: bond1: making interface eth1 the new active
> one.
> [ 300.159162] change rxhash from e56a3c1e to be0b5a87
>
> The flip occured when I changed my active slave (bonding mode=1).
>
> eth1 is a bnx2 NIC, while eth3 a be2net one, so its OK to change the
> rxhash in this case
> (different firmware/algo)
>
> So as far as be2net is concerned, everything seems OK : all packets for
> a given flow get an unique RSS hash and can feed skb->rxhash
>
Fair enough. Thanks.
I guess a fresh patch with the ethtool support included will be ideal,
instead of the previous patch?
-Ajit
^ permalink raw reply
* Re: [Lxc-users] Bad checksums and lost packets with macvlan on dummy
From: Andrian Nord @ 2011-02-26 20:38 UTC (permalink / raw)
To: Daniel Lezcano; +Cc: lxc-users, Patrick McHardy, Linux Netdev List
In-Reply-To: <4D6630D9.2050400@free.fr>
[-- Attachment #1: Type: text/plain, Size: 323 bytes --]
On Thu, Feb 24, 2011 at 11:20:09AM +0100, Daniel Lezcano wrote:
> I saw you were using the command 'nc6', do you use netcat with ipv6 ?
Well, yes and no. I've tried both ipv4 and ipv6 and my notebook has no
ipv6 address assigned, so most terrible connection was though ipv4 =).
At another server there is no ipv6 at all.
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [patch net-next-2.6 V3] net: convert bonding to use rx_handler
From: Jay Vosburgh @ 2011-02-26 19:42 UTC (permalink / raw)
To: =?ISO-8859-1?Q?Nicolas_de_Peslo=FCan?=
Cc: Jiri Pirko, David Miller, kaber, eric.dumazet, netdev, shemminger,
andy, Fischer, Anna
In-Reply-To: <4D690D16.8020503@gmail.com>
Nicolas de Pesloüan <nicolas.2p.debian@gmail.com> wrote:
>Le 22/02/2011 00:20, Nicolas de Pesloüan a écrit :
>
>> After checking every protocol handlers installed by dev_add_pack(), it
>> appears that only 4 of them really use the orig_dev parameter given by
>> __netif_receive_skb():
>>
>> - bond_3ad_lacpdu_recv() @ drivers/net/bonding/bond_3ad.c
>> - bond_arp_recv() @ drivers/net/bonding/bond_main.c
>> - packet_rcv() @ net/packet/af_packet.c
>> - tpacket_rcv() @ net/packet/af_packet.c
>>
>> From the bonding point of view, the meaning of orig_dev is obviously
>> "the device one layer below the bonding device, through which the packet
>> reached the bonding device". It is used by bond_3ad_lacpdu_recv() and
>> bond_arp_recv(), to find the underlying slave device through which the
>> LACPDU or ARP was received. (The protocol handler is registered at the
>> bonding device level).
>>
>> From the af_packet point of view, the meaning is documented (in commit
>> "[AF_PACKET]: Add option to return orig_dev to userspace") as the
>> "physical device [that] actually received the traffic, instead of having
>> the encapsulating device hide that information."
>>
>> When the bonding device is just one level above the physical device, the
>> two meanings happen to match the same device, by chance.
>>
>> So, currently, a bonding device cannot stack properly on top of anything
>> but physical devices. It might not be a problem today, but may change in
>> the future...
>
>Hi Jay,
>
>Still thinking about this orig_dev stuff, I wonder why the protocol
>handlers used in bonding (bond_3ad_lacpdu_recv() and bond_arp_rcv()) are
>registered at the master level instead of at the slave level ?
>
>If they were registered at the slave level, they would simply receive
>skb->dev as the ingress interface and use this value instead of needing
>the orig_dev value given to them when they are registered at the master
>level.
>
>As orig_dev is only used by bonding and by af_packet, but they disagree on
>the exact meaning of orig_dev, one way to fix this discrepancy would be to
>remove one of the usage. As the af_packet usage is exposed to user space,
>bonding seems the right place to stop using orig_dev, even if orig_dev was
>introduced for bonding :-)
>
>I understand that this would add one entry per slave device to the
>ptype_base list, but this seems to be the only bad effect of registering
>at the slave level. Can you confirm that this was the reason to register
>at the master level instead?
My recollection is that it was done the way it is because there
was no "orig_dev" delivery logic at the time. A handler registered to a
slave dev would receive no packets at all because assignment of skb->dev
to the master happened first, and the "orig_dev" knowledge was lost.
When 802.3ad was added, a skb->real_dev field was created, but
it wasn't used for delivery. 802.3ad used real_dev to figure out which
slave a LACPDU arrived on. The skb->real_dev was eventually replaced
with the orig_dev business that's there now.
Later, I did the arp_validate stuff the same way as 802.3ad
because it worked and was easier than registering a handler per slave.
>If you think registering at the slave level would cause too much impact on
>ptype_base, then we might have another way to stop using orig_dev for
>bonding:
>
>In __skb_bond_should_drop(), we already test for the two interesting protocols:
>
>if ((dev->priv_flags & IFF_SLAVE_NEEDARP) && skb->protocol == __cpu_to_be16(ETH_P_ARP))
> return 0;
>
>if (master->priv_flags & IFF_MASTER_8023AD && skb->protocol == __cpu_to_be16(ETH_P_SLOW))
> return 0;
>
>Would it be possible to call the right handlers directly from inside
>__skb_bond_should_drop() then let __skb_bond_should_drop() return 1
>("should drop") after processing the frames that are only of interest for
>bonding?
Isn't one purpose of switching to rx_handler that there won't
need to be any skb_bond_should_drop logic in __netif_receive_skb at all?
Still, if you're just trying to simplify __netif_receive_skb
first, I don't see any reason not to register the packet handlers at the
slave level. Looking at the ptype_base hash, I don't think that the
protocols bonding is registering (ARP and SLOW) will hash collide with
IP or IPv6, so I suspect there won't be much impact.
Once an rx_handler is used, then I suspect there's no need for
the packet handlers at all, since the rx_handler is within bonding and
can just deal with the ARP or LACPDU directly.
-J
---
-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
^ permalink raw reply
* Re: [PATCH] Bluetooth: Fix BT_L2CAP and BT_SCO in Kconfig
From: Vitaly Wool @ 2011-02-26 17:52 UTC (permalink / raw)
To: Gustavo F. Padovan; +Cc: davem, linville, linux-bluetooth, netdev
In-Reply-To: <1298684485-3081-1-git-send-email-padovan@profusion.mobi>
Hi Gustavo,
On Sat, Feb 26, 2011 at 2:41 AM, Gustavo F. Padovan
<padovan@profusion.mobi> wrote:
> If we want something "bool" built-in in something "tristate" it can't
> "depend on" the tristate config option.
>
> Report by DaveM:
>
> I give it 'y' just to make it happen, for both, and afterways no
> matter how many times I rerun "make oldconfig" I keep seeing things
> like this in my build:
>
> scripts/kconfig/conf --silentoldconfig Kconfig
> include/config/auto.conf:986:warning: symbol value 'm' invalid for BT_SCO
> include/config/auto.conf:3156:warning: symbol value 'm' invalid for BT_L2CAP
>
> Reported-by: David S. Miller <davem@davemloft.net>
> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
> ---
> net/bluetooth/Kconfig | 6 ++++--
> 1 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/net/bluetooth/Kconfig b/net/bluetooth/Kconfig
> index c6f9c2f..6ae5ec5 100644
> --- a/net/bluetooth/Kconfig
> +++ b/net/bluetooth/Kconfig
> @@ -31,9 +31,10 @@ menuconfig BT
> to Bluetooth kernel modules are provided in the BlueZ packages. For
> more information, see <http://www.bluez.org/>.
>
> +if BT != n
> +
> config BT_L2CAP
> bool "L2CAP protocol support"
> - depends on BT
> select CRC16
> help
> L2CAP (Logical Link Control and Adaptation Protocol) provides
> @@ -42,11 +43,12 @@ config BT_L2CAP
>
> config BT_SCO
> bool "SCO links support"
> - depends on BT
> help
> SCO link provides voice transport over Bluetooth. SCO support is
> required for voice applications like Headset and Audio.
>
> +endif
> +
Ugh, isn't it far cleaner to change initial dependencies to "depends
on BT != n" ?
Thanks,
Vitaly
^ 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