* Re: [net-next-2.6 PATCH v7 2/7 RFC] TCPCT part 1b: generate Responder Cookie secret
From: David Miller @ 2009-11-20 20:51 UTC (permalink / raw)
To: andi; +Cc: william.allen.simpson, netdev
In-Reply-To: <87eins53fu.fsf@basil.nowhere.org>
From: Andi Kleen <andi@firstfloor.org>
Date: Fri, 20 Nov 2009 21:47:17 +0100
> David Miller <davem@davemloft.net> writes:
>
>> From: William Allen Simpson <william.allen.simpson@gmail.com>
>> Date: Fri, 20 Nov 2009 09:23:21 -0500
>>
>>> +static DEFINE_SPINLOCK(tcp_secret_locker);
>>
>> So connection creation scalability will be limited now because
>> we'll always have to go through this centralized spinlock even
>> for independent listening sockets, right?
>
> I was about to complain about the same thing in a earlier version
> of this patch kit, but then I noticed the spin lock aquiring
> is guarded by
>
> if (unlikely(time_after_eq(jiffy, tcp_secret_generating->expires))) {
>
> which presumably makes it rare enough?
Works for me.
^ permalink raw reply
* Re: A generic kernel compatibilty code
From: Luis R. Rodriguez @ 2009-11-20 20:51 UTC (permalink / raw)
To: linux-kernel; +Cc: linux-wireless, netdev
In-Reply-To: <43e72e890911201245r4de5b039hb2dd5011dabf2399@mail.gmail.com>
On Fri, Nov 20, 2009 at 12:45 PM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
> Everyone and their mother reinvents the wheel when it comes to
> backporting kernel modules. It a painful job and it seems to me an
> alternative is possible. If we can write generic compatibilty code for
> a new routine introduced on the next kernel how about just merging it
> to the kernel under some generic compat module. This would be
> completey ignored by everyone using the stable kernel but can be
> copied by anyone doing backport work.
>
> So I'm thinking something as simple as a generic compat/comat.ko with
> compat-2.6.32.[ch] files.
FWIW, I meant a compat-2.6.32.[ch] and compat-2.6.31.[ch] and so on.
All these would link to the compat.ko
Luis
^ permalink raw reply
* Re: [PATCH net-next-2.6] net: Xmit Packet Steering (XPS)
From: David Miller @ 2009-11-20 20:53 UTC (permalink / raw)
To: andi; +Cc: eric.dumazet, therbert, netdev
In-Reply-To: <87aayg539l.fsf@basil.nowhere.org>
From: Andi Kleen <andi@firstfloor.org>
Date: Fri, 20 Nov 2009 21:51:02 +0100
> -Andi (who is a bit sceptical and would rather see generic work for
> -this in slab)
SLAB does this to an extent, but it's the other things about
SKB freeing that are expensive and hits lots of cache misses
in these cases.
^ permalink raw reply
* Re: A generic kernel compatibilty code
From: Luis R. Rodriguez @ 2009-11-20 20:53 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: linux-wireless, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <43e72e890911201251t6210ee19n177eaf003a4fffc-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Fri, Nov 20, 2009 at 12:51 PM, Luis R. Rodriguez <mcgrof-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Fri, Nov 20, 2009 at 12:45 PM, Luis R. Rodriguez <mcgrof-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> Everyone and their mother reinvents the wheel when it comes to
>> backporting kernel modules. It a painful job and it seems to me an
>> alternative is possible. If we can write generic compatibilty code for
>> a new routine introduced on the next kernel how about just merging it
>> to the kernel under some generic compat module. This would be
>> completey ignored by everyone using the stable kernel but can be
>> copied by anyone doing backport work.
>>
>> So I'm thinking something as simple as a generic compat/comat.ko with
>> compat-2.6.32.[ch] files.
>
> FWIW, I meant a compat-2.6.32.[ch] and compat-2.6.31.[ch] and so on.
> All these would link to the compat.ko
I supose this could juse be a separate tree with some generic
compat.ko module. That might work better.
Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net-next-2.6] net: Xmit Packet Steering (XPS)
From: Jarek Poplawski @ 2009-11-20 20:53 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David S. Miller, Tom Herbert, Linux Netdev List
In-Reply-To: <4B05D8DC.7020907@gmail.com>
Eric Dumazet wrote, On 11/20/2009 12:46 AM:
> Here is first version of XPS.
>
> Goal of XPS is to free TX completed skbs by the cpu that submitted the transmit.
>
> Because I chose to union skb->iif with skb->sending_cpu, I chose
> to introduce a new xps_consume_skb(skb), and not generalize consume_skb() itself.
...
> diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
> index 63f4742..e8e4795 100644
> --- a/include/linux/skbuff.h
> +++ b/include/linux/skbuff.h
> @@ -366,7 +366,10 @@ struct sk_buff {
> struct nf_bridge_info *nf_bridge;
> #endif
>
> - int iif;
> + union {
> + int iif;
> + int sending_cpu;
> + };
...
> diff --git a/net/core/dev.c b/net/core/dev.c
> index 9977288..9e134f6 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -1965,6 +1965,7 @@ int dev_queue_xmit(struct sk_buff *skb)
> struct netdev_queue *txq;
> struct Qdisc *q;
> int rc = -ENOMEM;
> + int cpu;
>
> /* GSO will handle the following emulations directly. */
> if (netif_needs_gso(dev, skb))
> @@ -2000,6 +2001,7 @@ gso:
> */
> rcu_read_lock_bh();
>
> + skb->sending_cpu = cpu = smp_processor_id();
There is one more problem: this will break things like act_mirred + ifb,
and other cases using skb->iif e.g. for filtering on virtual devices at
the xmit path.
Jarek P.
^ permalink raw reply
* Re: [net-next-2.6 PATCH v7 5/7 RFC] TCPCT part 1e: implement socket option TCP_COOKIE_TRANSACTIONS
From: Joe Perches @ 2009-11-20 20:54 UTC (permalink / raw)
To: David Miller; +Cc: william.allen.simpson, netdev
In-Reply-To: <20091120.092651.254794724.davem@davemloft.net>
On Fri, 2009-11-20 at 09:26 -0800, David Miller wrote:
> From: William Allen Simpson <william.allen.simpson@gmail.com>
> > + ctd.tcpct_flags = (tp->rx_opt.cookie_in_always
> > + ? TCP_COOKIE_IN_ALWAYS : 0)
> > + | (tp->rx_opt.cookie_out_never
> > + ? TCP_COOKIE_OUT_NEVER : 0);
>
> "?" should be at end of previous line not at beginning of
> next one, please fix this up.
Perhaps the ? position is taster's choice.
(false positives exist)
$ grep -rP --include=*.[ch] "^\s*\?" * | wc -l
884
$ grep -rP --include=*.[ch] -h "\?\s*$" * | \
grep -vP "^\s*\*" | grep -vP "(//|/\*)" | wc -l
2968
^ permalink raw reply
* Re: A generic kernel compatibilty code
From: Ben Hutchings @ 2009-11-20 21:00 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-kernel, linux-wireless, netdev
In-Reply-To: <43e72e890911201245r4de5b039hb2dd5011dabf2399@mail.gmail.com>
On Fri, 2009-11-20 at 12:45 -0800, Luis R. Rodriguez wrote:
> Everyone and their mother reinvents the wheel when it comes to
> backporting kernel modules. It a painful job and it seems to me an
> alternative is possible. If we can write generic compatibilty code for
> a new routine introduced on the next kernel how about just merging it
> to the kernel under some generic compat module. This would be
> completey ignored by everyone using the stable kernel but can be
> copied by anyone doing backport work.
>
> So I'm thinking something as simple as a generic compat/comat.ko with
> compat-2.6.32.[ch] files.
>
> We've already backported everything needed for wireless drivers under
> compat-wireless under this format down to even 2.6.25.
[...]
If you think 2.6.25 is old then I don't think you understand the scale
of the problem.
OEMs still expect us to support RHEL 4 (2.6.9) and SLES 9 (2.6.5) though
the latter will probably be dropped soon. Some other vendors apparently
still need to support even 2.4 kernels!
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
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: A generic kernel compatibilty code
From: Luis R. Rodriguez @ 2009-11-20 21:07 UTC (permalink / raw)
To: Ben Hutchings; +Cc: linux-kernel, linux-wireless, netdev
In-Reply-To: <1258750858.2877.58.camel@achroite.uk.solarflarecom.com>
On Fri, Nov 20, 2009 at 1:00 PM, Ben Hutchings
<bhutchings@solarflare.com> wrote:
> On Fri, 2009-11-20 at 12:45 -0800, Luis R. Rodriguez wrote:
>> Everyone and their mother reinvents the wheel when it comes to
>> backporting kernel modules. It a painful job and it seems to me an
>> alternative is possible. If we can write generic compatibilty code for
>> a new routine introduced on the next kernel how about just merging it
>> to the kernel under some generic compat module. This would be
>> completey ignored by everyone using the stable kernel but can be
>> copied by anyone doing backport work.
>>
>> So I'm thinking something as simple as a generic compat/comat.ko with
>> compat-2.6.32.[ch] files.
>>
>> We've already backported everything needed for wireless drivers under
>> compat-wireless under this format down to even 2.6.25.
> [...]
>
> If you think 2.6.25 is old then I don't think you understand the scale
> of the problem.
>
> OEMs still expect us to support RHEL 4 (2.6.9) and SLES 9 (2.6.5) though
> the latter will probably be dropped soon. Some other vendors apparently
> still need to support even 2.4 kernels!
Heh understood. Well shouldn't this help with that then? Sure I'd love
to see the Enteprise Linux releases on 2.6.31 but that's not going to
happen right? Shouldn't this help then?
Luis
^ permalink raw reply
* Re: A generic kernel compatibilty code
From: Mauro Carvalho Chehab @ 2009-11-20 21:16 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-kernel, linux-wireless, netdev
In-Reply-To: <43e72e890911201245r4de5b039hb2dd5011dabf2399@mail.gmail.com>
Hi Luis,
Em Fri, 20 Nov 2009 12:45:51 -0800
"Luis R. Rodriguez" <mcgrof@gmail.com> escreveu:
> Everyone and their mother reinvents the wheel when it comes to
> backporting kernel modules. It a painful job and it seems to me an
> alternative is possible. If we can write generic compatibilty code for
> a new routine introduced on the next kernel how about just merging it
> to the kernel under some generic compat module. This would be
> completey ignored by everyone using the stable kernel but can be
> copied by anyone doing backport work.
>
> So I'm thinking something as simple as a generic compat/comat.ko with
> compat-2.6.32.[ch] files.
>
> We've already backported everything needed for wireless drivers under
> compat-wireless under this format down to even 2.6.25. I volunteer to
> be the sucker for this if this is reasonable and given the shot to try
> it.
>
We have several backport stuff at our development tree, that works for
V4L/DVB up to kernel 2.6.16 (so, up to RHEL5).
It is based on a compat.h file, plus some extra tests inside the drivers.
They are at:
http://linuxtv.org/hg/v4l-dvb
I also started working on a different approach of dynamically patching the
drivers based on some semantic rules, parsed in perl, but I hadn't enough
time to finish.
If you want to take a look, it is at:
http://linuxtv.org/hg/~mchehab/backport/
Cheers,
Mauro
^ permalink raw reply
* Re: A generic kernel compatibilty code
From: John W. Linville @ 2009-11-20 21:18 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-kernel, linux-wireless, netdev
In-Reply-To: <43e72e890911201253obc466c8k2102e04457c48c92@mail.gmail.com>
On Fri, Nov 20, 2009 at 12:53:51PM -0800, Luis R. Rodriguez wrote:
> On Fri, Nov 20, 2009 at 12:51 PM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
> > On Fri, Nov 20, 2009 at 12:45 PM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
> >> Everyone and their mother reinvents the wheel when it comes to
> >> backporting kernel modules. It a painful job and it seems to me an
> >> alternative is possible. If we can write generic compatibilty code for
> >> a new routine introduced on the next kernel how about just merging it
> >> to the kernel under some generic compat module. This would be
> >> completey ignored by everyone using the stable kernel but can be
> >> copied by anyone doing backport work.
> >>
> >> So I'm thinking something as simple as a generic compat/comat.ko with
> >> compat-2.6.32.[ch] files.
> >
> > FWIW, I meant a compat-2.6.32.[ch] and compat-2.6.31.[ch] and so on.
> > All these would link to the compat.ko
>
> I supose this could juse be a separate tree with some generic
> compat.ko module. That might work better.
This is what I would suggest for pursuing this idea. Perhaps you
could split-off from compat-wireless, then make that tree depend on
the new tree (compat-core?)...
Hth...
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [PATCH net-next-2.6] net: Xmit Packet Steering (XPS)
From: Eric Dumazet @ 2009-11-20 21:35 UTC (permalink / raw)
To: Jarek Poplawski; +Cc: David S. Miller, Tom Herbert, Linux Netdev List
In-Reply-To: <4B0701E2.1070806@gmail.com>
Jarek Poplawski a écrit :
>
> There is one more problem: this will break things like act_mirred + ifb,
> and other cases using skb->iif e.g. for filtering on virtual devices at
> the xmit path.
>
Following patch might help us to locate real uses of this obscure field :)
[PATCH net-next-2.6] net: rename skb->iif to skb->skb_iif
To help grep games, rename iif to skb_iif
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
drivers/net/ifb.c | 6 +++---
include/linux/skbuff.h | 4 ++--
include/net/pkt_cls.h | 4 ++--
net/core/dev.c | 6 +++---
net/core/skbuff.c | 2 +-
net/netlabel/netlabel_unlabeled.c | 2 +-
net/sched/act_mirred.c | 2 +-
net/sched/cls_flow.c | 2 +-
security/selinux/hooks.c | 6 +++---
security/smack/smack_lsm.c | 4 ++--
10 files changed, 19 insertions(+), 19 deletions(-)
diff --git a/drivers/net/ifb.c b/drivers/net/ifb.c
index 69c2566..f4081c0 100644
--- a/drivers/net/ifb.c
+++ b/drivers/net/ifb.c
@@ -99,7 +99,7 @@ static void ri_tasklet(unsigned long dev)
stats->tx_bytes +=skb->len;
rcu_read_lock();
- skb->dev = dev_get_by_index_rcu(&init_net, skb->iif);
+ skb->dev = dev_get_by_index_rcu(&init_net, skb->skb_iif);
if (!skb->dev) {
rcu_read_unlock();
dev_kfree_skb(skb);
@@ -107,7 +107,7 @@ static void ri_tasklet(unsigned long dev)
break;
}
rcu_read_unlock();
- skb->iif = _dev->ifindex;
+ skb->skb_iif = _dev->ifindex;
if (from & AT_EGRESS) {
dp->st_rx_frm_egr++;
@@ -172,7 +172,7 @@ static netdev_tx_t ifb_xmit(struct sk_buff *skb, struct net_device *dev)
stats->rx_packets++;
stats->rx_bytes+=skb->len;
- if (!(from & (AT_INGRESS|AT_EGRESS)) || !skb->iif) {
+ if (!(from & (AT_INGRESS|AT_EGRESS)) || !skb->skb_iif) {
dev_kfree_skb(skb);
stats->rx_dropped++;
return NETDEV_TX_OK;
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 63f4742..89eed8c 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -299,7 +299,7 @@ typedef unsigned char *sk_buff_data_t;
* @nfctinfo: Relationship of this skb to the connection
* @nfct_reasm: netfilter conntrack re-assembly pointer
* @nf_bridge: Saved data about a bridged frame - see br_netfilter.c
- * @iif: ifindex of device we arrived on
+ * @skb_iif: ifindex of device we arrived on
* @queue_mapping: Queue mapping for multiqueue devices
* @tc_index: Traffic control index
* @tc_verd: traffic control verdict
@@ -366,7 +366,7 @@ struct sk_buff {
struct nf_bridge_info *nf_bridge;
#endif
- int iif;
+ int skb_iif;
#ifdef CONFIG_NET_SCHED
__u16 tc_index; /* traffic control index */
#ifdef CONFIG_NET_CLS_ACT
diff --git a/include/net/pkt_cls.h b/include/net/pkt_cls.h
index 3dd210d..dd3031a 100644
--- a/include/net/pkt_cls.h
+++ b/include/net/pkt_cls.h
@@ -343,9 +343,9 @@ tcf_match_indev(struct sk_buff *skb, char *indev)
struct net_device *dev;
if (indev[0]) {
- if (!skb->iif)
+ if (!skb->skb_iif)
return 0;
- dev = __dev_get_by_index(dev_net(skb->dev), skb->iif);
+ dev = __dev_get_by_index(dev_net(skb->dev), skb->skb_iif);
if (!dev || strcmp(indev, dev->name))
return 0;
}
diff --git a/net/core/dev.c b/net/core/dev.c
index 9977288..09f3d6b 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2287,7 +2287,7 @@ static int ing_filter(struct sk_buff *skb)
if (MAX_RED_LOOP < ttl++) {
printk(KERN_WARNING
"Redir loop detected Dropping packet (%d->%d)\n",
- skb->iif, dev->ifindex);
+ skb->skb_iif, dev->ifindex);
return TC_ACT_SHOT;
}
@@ -2395,8 +2395,8 @@ int netif_receive_skb(struct sk_buff *skb)
if (netpoll_receive_skb(skb))
return NET_RX_DROP;
- if (!skb->iif)
- skb->iif = skb->dev->ifindex;
+ if (!skb->skb_iif)
+ skb->skb_iif = skb->dev->ifindex;
null_or_orig = NULL;
orig_dev = skb->dev;
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 739b8f4..bfa3e78 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -549,7 +549,7 @@ static void __copy_skb_header(struct sk_buff *new, const struct sk_buff *old)
#endif
new->protocol = old->protocol;
new->mark = old->mark;
- new->iif = old->iif;
+ new->skb_iif = old->skb_iif;
__nf_copy(new, old);
#if defined(CONFIG_NETFILTER_XT_TARGET_TRACE) || \
defined(CONFIG_NETFILTER_XT_TARGET_TRACE_MODULE)
diff --git a/net/netlabel/netlabel_unlabeled.c b/net/netlabel/netlabel_unlabeled.c
index 3dfe2ba..98ed22e 100644
--- a/net/netlabel/netlabel_unlabeled.c
+++ b/net/netlabel/netlabel_unlabeled.c
@@ -1550,7 +1550,7 @@ int netlbl_unlabel_getattr(const struct sk_buff *skb,
struct netlbl_unlhsh_iface *iface;
rcu_read_lock();
- iface = netlbl_unlhsh_search_iface_def(skb->iif);
+ iface = netlbl_unlhsh_search_iface_def(skb->skb_iif);
if (iface == NULL)
goto unlabel_getattr_nolabel;
switch (family) {
diff --git a/net/sched/act_mirred.c b/net/sched/act_mirred.c
index 7974793..d329170 100644
--- a/net/sched/act_mirred.c
+++ b/net/sched/act_mirred.c
@@ -185,7 +185,7 @@ static int tcf_mirred(struct sk_buff *skb, struct tc_action *a,
skb2->tc_verd = SET_TC_FROM(skb2->tc_verd, at);
skb2->dev = dev;
- skb2->iif = skb->dev->ifindex;
+ skb2->skb_iif = skb->dev->ifindex;
dev_queue_xmit(skb2);
err = 0;
diff --git a/net/sched/cls_flow.c b/net/sched/cls_flow.c
index 9402a7f..e054c62 100644
--- a/net/sched/cls_flow.c
+++ b/net/sched/cls_flow.c
@@ -171,7 +171,7 @@ static u32 flow_get_proto_dst(const struct sk_buff *skb)
static u32 flow_get_iif(const struct sk_buff *skb)
{
- return skb->iif;
+ return skb->skb_iif;
}
static u32 flow_get_priority(const struct sk_buff *skb)
diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index bb230d5..83a4aad 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -4085,7 +4085,7 @@ static int selinux_sock_rcv_skb_compat(struct sock *sk, struct sk_buff *skb,
char *addrp;
COMMON_AUDIT_DATA_INIT(&ad, NET);
- ad.u.net.netif = skb->iif;
+ ad.u.net.netif = skb->skb_iif;
ad.u.net.family = family;
err = selinux_parse_skb(skb, &ad, &addrp, 1, NULL);
if (err)
@@ -4147,7 +4147,7 @@ static int selinux_socket_sock_rcv_skb(struct sock *sk, struct sk_buff *skb)
return 0;
COMMON_AUDIT_DATA_INIT(&ad, NET);
- ad.u.net.netif = skb->iif;
+ ad.u.net.netif = skb->skb_iif;
ad.u.net.family = family;
err = selinux_parse_skb(skb, &ad, &addrp, 1, NULL);
if (err)
@@ -4159,7 +4159,7 @@ static int selinux_socket_sock_rcv_skb(struct sock *sk, struct sk_buff *skb)
err = selinux_skb_peerlbl_sid(skb, family, &peer_sid);
if (err)
return err;
- err = selinux_inet_sys_rcv_skb(skb->iif, addrp, family,
+ err = selinux_inet_sys_rcv_skb(skb->skb_iif, addrp, family,
peer_sid, &ad);
if (err) {
selinux_netlbl_err(skb, err, 0);
diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c
index c33b6bb..529c9ca 100644
--- a/security/smack/smack_lsm.c
+++ b/security/smack/smack_lsm.c
@@ -2602,7 +2602,7 @@ static int smack_socket_sock_rcv_skb(struct sock *sk, struct sk_buff *skb)
#ifdef CONFIG_AUDIT
smk_ad_init(&ad, __func__, LSM_AUDIT_DATA_NET);
ad.a.u.net.family = sk->sk_family;
- ad.a.u.net.netif = skb->iif;
+ ad.a.u.net.netif = skb->skb_iif;
ipv4_skb_to_auditdata(skb, &ad.a, NULL);
#endif
/*
@@ -2757,7 +2757,7 @@ static int smack_inet_conn_request(struct sock *sk, struct sk_buff *skb,
#ifdef CONFIG_AUDIT
smk_ad_init(&ad, __func__, LSM_AUDIT_DATA_NET);
ad.a.u.net.family = family;
- ad.a.u.net.netif = skb->iif;
+ ad.a.u.net.netif = skb->skb_iif;
ipv4_skb_to_auditdata(skb, &ad.a, NULL);
#endif
/*
^ permalink raw reply related
* Re: A generic kernel compatibilty code
From: Luis R. Rodriguez @ 2009-11-20 21:38 UTC (permalink / raw)
To: John W. Linville
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-wireless,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20091120211837.GA22815-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
On Fri, Nov 20, 2009 at 1:18 PM, John W. Linville
<linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org> wrote:
> On Fri, Nov 20, 2009 at 12:53:51PM -0800, Luis R. Rodriguez wrote:
>> On Fri, Nov 20, 2009 at 12:51 PM, Luis R. Rodriguez <mcgrof-Re5JQEeQqe8@public.gmane.orgm> wrote:
>> > On Fri, Nov 20, 2009 at 12:45 PM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
>> >> Everyone and their mother reinvents the wheel when it comes to
>> >> backporting kernel modules. It a painful job and it seems to me an
>> >> alternative is possible. If we can write generic compatibilty code for
>> >> a new routine introduced on the next kernel how about just merging it
>> >> to the kernel under some generic compat module. This would be
>> >> completey ignored by everyone using the stable kernel but can be
>> >> copied by anyone doing backport work.
>> >>
>> >> So I'm thinking something as simple as a generic compat/comat.ko with
>> >> compat-2.6.32.[ch] files.
>> >
>> > FWIW, I meant a compat-2.6.32.[ch] and compat-2.6.31.[ch] and so on.
>> > All these would link to the compat.ko
>>
>> I supose this could juse be a separate tree with some generic
>> compat.ko module. That might work better.
>
> This is what I would suggest for pursuing this idea. Perhaps you
> could split-off from compat-wireless, then make that tree depend on
> the new tree (compat-core?)...
OK thanks, will try that for the next kernel.
Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net-next-2.6] net: Xmit Packet Steering (XPS)
From: Joe Perches @ 2009-11-20 21:43 UTC (permalink / raw)
To: Eric Dumazet
Cc: Jarek Poplawski, David S. Miller, Tom Herbert, Linux Netdev List
In-Reply-To: <4B070BAC.1090406@gmail.com>
On Fri, 2009-11-20 at 22:35 +0100, Eric Dumazet wrote:
> Jarek Poplawski a écrit :
> > There is one more problem: this will break things like act_mirred + ifb,
> > and other cases using skb->iif e.g. for filtering on virtual devices at
> > the xmit path.
> Following patch might help us to locate real uses of this obscure field :)
> [PATCH net-next-2.6] net: rename skb->iif to skb->skb_iif
Prefixing member names generally doesn't end well.
Prefixing selected member names? ick.
^ permalink raw reply
* Re: [PATCH net-next-2.6] net: Xmit Packet Steering (XPS)
From: Eric Dumazet @ 2009-11-20 21:43 UTC (permalink / raw)
To: Jarek Poplawski; +Cc: David S. Miller, Tom Herbert, Linux Netdev List
In-Reply-To: <20091120200434.GB2688@ami.dom.local>
Jarek Poplawski a écrit :
> On Fri, Nov 20, 2009 at 03:45:42PM +0100, Eric Dumazet wrote:
>> Jarek Poplawski a écrit :
>>> On 20-11-2009 00:46, Eric Dumazet wrote:
>>> scheduled) IPIs?
>> Repeat after me :
>>
>> lockdep is my friend, lockdep is my friend, lockdep is my friend... :)
>
> Hmm... Actually, why did I have to do lockdep's job...
In fact I could not find why irq masking is necessary, and lockdep is
fine with my code and my testings. Care to explain what problem you spotted ?
In fact, I originally used cmpxchg() and xchg() (no spinlock),
but had to find the end of skb list in the IPI handler, so I chose
to use a skb_head instead to let the IPI handler be as short as possible.
^ permalink raw reply
* Re: [PATCH] ixgbe: move tc variable to CONFIG_IXGBE_DCB
From: David Miller @ 2009-11-20 21:47 UTC (permalink / raw)
To: jeffrey.t.kirsher
Cc: jaswinder, yi.zou, peter.p.waskiewicz.jr, netdev, linux-kernel
In-Reply-To: <9929d2390911201116l562291cbh8e6a557b64fa7ef0@mail.gmail.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Fri, 20 Nov 2009 11:16:54 -0800
> :) That is fine. The end result is the same.
>
> Acked-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Great, applied.
^ permalink raw reply
* Re: [PATCH net-next-2.6] net: Xmit Packet Steering (XPS)
From: David Miller @ 2009-11-20 21:49 UTC (permalink / raw)
To: joe; +Cc: eric.dumazet, jarkao2, therbert, netdev
In-Reply-To: <1258753414.28239.66.camel@Joe-Laptop.home>
From: Joe Perches <joe@perches.com>
Date: Fri, 20 Nov 2009 13:43:34 -0800
> On Fri, 2009-11-20 at 22:35 +0100, Eric Dumazet wrote:
>> Jarek Poplawski a écrit :
>> > There is one more problem: this will break things like act_mirred + ifb,
>> > and other cases using skb->iif e.g. for filtering on virtual devices at
>> > the xmit path.
>> Following patch might help us to locate real uses of this obscure field :)
>> [PATCH net-next-2.6] net: rename skb->iif to skb->skb_iif
>
> Prefixing member names generally doesn't end well.
> Prefixing selected member names? ick.
But I highly encourage what Eric is doing, I hate having to grep the
tree very carefully just to find uses of a certain SKB struct member.
And since SKB usage covers so many thousands of files in the tree,
doing one at a time like Eric is here really can make sense.
^ permalink raw reply
* Re: [net-2.6 PATCH 1/6] e1000e: partial revert of 3ec2a2b8 plus FC workraround for 82577/8
From: David Miller @ 2009-11-20 21:54 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, bruce.w.allan
In-Reply-To: <20091119223406.29164.22513.stgit@localhost.localdomain>
All 6 patches applied, but this is way too much to change this
late in the -rcX series. I know you were not feeling well last
week and therefore you have some things to catch up with, but
that doesn't change the situation.
You've been warned :-)
^ permalink raw reply
* Re: [net-2.6 PATCH] e1000e: do not initiate autonegotiation during OEM configuration
From: David Miller @ 2009-11-20 21:54 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, bruce.w.allan
In-Reply-To: <20091120001722.29775.22407.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Thu, 19 Nov 2009 16:17:30 -0800
> From: Bruce Allan <bruce.w.allan@intel.com>
>
> When configuring the OEM bits in the PHY on 82577/82578, do not restart
> autonegotiation if the firmware is blocking it (e.g. when an IDE-R session
> is active) because the link must not go down.
>
> Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [PATCH 2.6.32-rc6] drivers/net: ks8851_mll ethernet network driver -resubmit
From: David Miller @ 2009-11-20 21:55 UTC (permalink / raw)
To: David.Choi; +Cc: netdev, linux-kernel, shemminger, greg
In-Reply-To: <C43529A246480145B0A6D0234BDB0F0D02129B@MELANITE.micrel.com>
From: "Choi, David" <David.Choi@Micrel.Com>
Date: Thu, 19 Nov 2009 17:34:30 -0800
> This patch is for ks8851 16bit MLL Ethernet network device driver in order to
> fix bugs and to enhance functions. This resubmit removes a printk statement causing
> the compile warning in 64bit processors.
Applied.
>>From : David J. Choi <david.choi@micrel.com>
Please fix how this is emiited in your emails. GIT won't pick
it up to use this as the author information unless it is
formatted correctly. That leading '>' character and the
TAB between "From" and ":" need to go away.
I edited it out by hand this time.
Thanks.
^ permalink raw reply
* Re: [PATCH] net: ETHOC should depend on HAS_DMA
From: David Miller @ 2009-11-20 21:56 UTC (permalink / raw)
To: geert
Cc: heiko.carstens, thierry.reding, schwidefsky, netdev, linux-kernel,
linux-s390
In-Reply-To: <10f740e80911201119h6db1e2e1t2c6d40ef1e614094@mail.gmail.com>
From: Geert Uytterhoeven <geert@linux-m68k.org>
Date: Fri, 20 Nov 2009 20:19:10 +0100
> Subject: [PATCH] net: ETHOC should depend on HAS_DMA
>
> When building for Sun 3:
>
> drivers/net/ethoc.c:1091: undefined reference to `dma_free_coherent'
> drivers/built-in.o: In function `ethoc_probe':
> drivers/net/ethoc.c:965: undefined reference to `dma_alloc_coherent'
> drivers/net/ethoc.c:1063: undefined reference to `dma_free_coherent'
>
> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next-2.6] net: Xmit Packet Steering (XPS)
From: Eric Dumazet @ 2009-11-20 22:01 UTC (permalink / raw)
To: Joe Perches
Cc: Jarek Poplawski, David S. Miller, Tom Herbert, Linux Netdev List
In-Reply-To: <1258753414.28239.66.camel@Joe-Laptop.home>
Joe Perches a écrit :
>
> Prefixing member names generally doesn't end well.
> Prefixing selected member names? ick.
Yes, but Rome was not built in one day my friend :)
This patch makes Jarek point more obvious : Dont reuse iif or risk
new bugs.
^ permalink raw reply
* Re: [PATCH net-next-2.6] net: Xmit Packet Steering (XPS)
From: Jarek Poplawski @ 2009-11-20 22:08 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David S. Miller, Tom Herbert, Linux Netdev List
In-Reply-To: <4B070D9B.60409@gmail.com>
On Fri, Nov 20, 2009 at 10:43:55PM +0100, Eric Dumazet wrote:
> Jarek Poplawski a écrit :
> > On Fri, Nov 20, 2009 at 03:45:42PM +0100, Eric Dumazet wrote:
> >> Jarek Poplawski a écrit :
> >>> On 20-11-2009 00:46, Eric Dumazet wrote:
> >>> scheduled) IPIs?
> >> Repeat after me :
> >>
> >> lockdep is my friend, lockdep is my friend, lockdep is my friend... :)
> >
> > Hmm... Actually, why did I have to do lockdep's job...
>
> In fact I could not find why irq masking is necessary, and lockdep is
> fine with my code and my testings. Care to explain what problem you spotted ?
>
CPU1 CPU2
net_rx_action() net_rx_action()
xps_flush() xps_flush()
q = &per_cpu(xps_pcpu_queue, cpu2) q = &per_cpu(xps_pcpu_queue, cpu1)
spin_lock(&q->list.lock of cpu2) spin_lock(&q->list.lock of cpu1)
<IPI> <IPI>
remote_free_skb_list() remote_free_skb_list()
waiting on spin_lock(&q->list.lock of cpu1) waiting on spin_lock(&q->list.lock of cpu2)
IPIs triggerered e.g. by CPU3 (or/and CPU4...) doing net_rx_action as well.
Jarek P.
^ permalink raw reply
* Re: [PATCH net-next-2.6] net: Xmit Packet Steering (XPS)
From: Eric Dumazet @ 2009-11-20 22:21 UTC (permalink / raw)
To: Jarek Poplawski; +Cc: David S. Miller, Tom Herbert, Linux Netdev List
In-Reply-To: <20091120220851.GA4717@ami.dom.local>
Jarek Poplawski a écrit :
> On Fri, Nov 20, 2009 at 10:43:55PM +0100, Eric Dumazet wrote:
>>> Hmm... Actually, why did I have to do lockdep's job...
>> In fact I could not find why irq masking is necessary, and lockdep is
>> fine with my code and my testings. Care to explain what problem you spotted ?
>>
>
> CPU1 CPU2
> net_rx_action() net_rx_action()
> xps_flush() xps_flush()
> q = &per_cpu(xps_pcpu_queue, cpu2) q = &per_cpu(xps_pcpu_queue, cpu1)
> spin_lock(&q->list.lock of cpu2) spin_lock(&q->list.lock of cpu1)
>
> <IPI> <IPI>
> remote_free_skb_list() remote_free_skb_list()
> waiting on spin_lock(&q->list.lock of cpu1) waiting on spin_lock(&q->list.lock of cpu2)
>
>
> IPIs triggerered e.g. by CPU3 (or/and CPU4...) doing net_rx_action as well.
>
:) Now I am convinced :)
Thanks jarek
^ permalink raw reply
* Re: [net-next-2.6 PATCH] be2net:Patch to flash redboot section while firmware update.
From: David Miller @ 2009-11-20 22:24 UTC (permalink / raw)
To: sarveshwarb; +Cc: netdev
In-Reply-To: <20091120095617.GA29364@serverengines.com>
From: Sarveshwar Bandi <sarveshwarb@serverengines.com>
Date: Fri, 20 Nov 2009 15:26:18 +0530
> This is the primary boot loader program for the firmware. It is a
> separate section in the firmware image.
Thanks for the explanation, patch applied.
^ permalink raw reply
* Re: [PATCH net-next-2.6] net: Xmit Packet Steering (XPS)
From: Eric Dumazet @ 2009-11-20 22:30 UTC (permalink / raw)
To: Andi Kleen; +Cc: David S. Miller, Tom Herbert, Linux Netdev List
In-Reply-To: <87aayg539l.fsf@basil.nowhere.org>
Andi Kleen a écrit :
>
> Do you have numbers on this? It seems like a lot of effort to avoid transfering
> a few cache lines.
Lot of efforts ? hmm...
>
> -Andi (who is a bit sceptical and would rather see generic work for this in slab)
>
Yes, I know, but slab/slub is already quite optimized :)
Coding XPS was more a way to try to help push RPS in, I did not benchmarked it BTW.
My new dev machine is up, with two E5530 cpus and a 82599EB 10-Gigabit dual port card :
Pretty amazing :=)
^ 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