* Re: [PATCH v3] ipconfig wait for carrier
From: Micha Nelissen @ 2011-05-19 18:52 UTC (permalink / raw)
To: Dan Williams; +Cc: David Miller, netdev
In-Reply-To: <1305819120.3271.3.camel@dcbw.foobar.com>
Dan Williams wrote:
> On Wed, 2011-05-18 at 18:14 -0400, David Miller wrote:
>> Please fix ic_is_init_dev() to return a proper boolean "false" instead
>> of "0" when IFF_LOOPBACK is set.
Ok. Had an int before, but boolean is better.
> Shouldn't the code still wait at *least* one second? Not all drivers
> support carrier detect, and those that don't set the carrier always-on.
> Thus older devices that used to have 1s to get carrier in line (even if
> they don't report it) now have only 10ms.
>
> I think it should wait at least one second like the code currently does,
> and then if the carrier still isn't up, wait longer.
What is the 1 second based on?
If a driver does not support carrier detect, then this code will wait
for the timeout period. Or do those older drivers set carrier detect
immediately when device is probed?
Micha
^ permalink raw reply
* Re: net: add seq_before/seq_after functions
From: David Miller @ 2011-05-19 18:52 UTC (permalink / raw)
To: sven; +Cc: ordex, linux-kernel, netdev, paulus, linux-ppp
In-Reply-To: <201105191121.23888.sven@narfation.org>
From: Sven Eckelmann <sven@narfation.org>
Date: Thu, 19 May 2011 11:21:21 +0200
> This is currently used by vis.c in net/batman-adv and could also be used by
> ppp-generic.c (with my changes of course). And it is planned to be used by
> transtable.c in net/batman-adv. The idea was to propose this to linux-
> kernel/netdev before we move it to a place were only batman-adv can use it
> (the current situation is that vis.c in batman-adv can only use it).
>
> It is ok that you say that it should be batman-adv specific - we only wanted
> to ask first.
Well, this is a purely networking change, the header you're touching is
networking specific, so really in this case linux-kernel didn't need to
get involved :-)
^ permalink raw reply
* Re: [RFC 2/3] RDMA/cma: Add support for netlink statistics export
From: Roland Dreier @ 2011-05-19 18:49 UTC (permalink / raw)
To: Hefty, Sean
Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <1828884A29C6694DAF28B7E6B8A82373FF9E-P5GAC/sN6hmkrb+BlOpmy7fspsVTdybXVpNB7YpNyf8@public.gmane.org>
On Thu, May 19, 2011 at 11:35 AM, Hefty, Sean <sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> wrote:
> One of the patches in the af_ib patch set adds the qp_type to struct rdma_cm_id. I'm guessing that patch will also be needed for xrc.
Would it make sense to pull that patch at least in?
Sorry I haven't had time to really think about AF_IB in general but
maybe I can at least merge the netlink stuff this cycle?
- R.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" 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: [RFC 2/3] RDMA/cma: Add support for netlink statistics export
From: Hefty, Sean @ 2011-05-19 18:35 UTC (permalink / raw)
To: Roland Dreier; +Cc: netdev@vger.kernel.org, linux-rdma@vger.kernel.org
In-Reply-To: <BANLkTin1uVyrzdn_030bGmC=QHtfkvOTNA@mail.gmail.com>
> Is there an easy way to get the qp_type from a struct rdma_cm_id?
>
> ie what code needs to go into cma_get_id_stats() to handle this?
With the current code, you'd need to map from the port space:
static inline enum ib_qp_type cma_get_qp_type(struct rdma_cm_id *id)
{
if (id->ps == RDMA_PS_IPOIB || id->ps == RDMA_PS_UDP)
return IB_QPT_RC;
else
return IB_QPT_RC;
}
..
id_stats->qp_type = cma_get_qp_type(id);
..
One of the patches in the af_ib patch set adds the qp_type to struct rdma_cm_id. I'm guessing that patch will also be needed for xrc.
- Sean
^ permalink raw reply
* Re: [RFC 2/3] RDMA/cma: Add support for netlink statistics export
From: Roland Dreier @ 2011-05-19 18:10 UTC (permalink / raw)
To: Hefty, Sean
Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <1828884A29C6694DAF28B7E6B8A82373F428-P5GAC/sN6hmkrb+BlOpmy7fspsVTdybXVpNB7YpNyf8@public.gmane.org>
On Fri, May 13, 2011 at 10:21 AM, Hefty, Sean <sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> wrote:
>> +struct rdma_cm_id_stats {
>> + __u32 qp_num;
>> + __u32 bound_dev_if;
>> + __u32 port_space;
>> + __s32 pid;
>> + __u8 cm_state;
>> + __u8 node_type;
>> + __u8 port_num;
>> + __u8 reserved;
>> +};
>
> We may also want to add qp_type
Is there an easy way to get the qp_type from a struct rdma_cm_id?
ie what code needs to go into cma_get_id_stats() to handle this?
Thanks,
Roland
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" 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] tcp: Lower the initial RTO to 1s as per draft RFC 2988bis-02.
From: Yuchung Cheng @ 2011-05-19 17:42 UTC (permalink / raw)
To: Benoit Sigoure; +Cc: netdev, linux-kernel, Benoit Sigoure, Hsiao-keng Jerry Chu
In-Reply-To: <1305786976-84532-1-git-send-email-tsunanet@gmail.com>
Hi Benoit,
AFAICT, the passive open side would not fall back the
RTO to 3sec in this change because SYNACK timeouts are not
recorded in icsk_retransmits but reqsk->retrans?
Yuchung
On Wed, May 18, 2011 at 11:36 PM, Benoit Sigoure <tsunanet@gmail.com> wrote:
>
> From: Benoit Sigoure <tsuna@stumbleupon.com>
>
> Draft RFC 2988bis-02 recommends that the initial RTO be lowered
> from 3 seconds down to 1 second, and that in case of a timeout
> during the TCP 3WHS, the RTO should fallback to 3 seconds when
> data transmission begins.
> ---
>
> On Wed, May 18, 2011 at 10:46 PM, David Miller <davem@davemloft.net> wrote:
> > From: tsuna <tsunanet@gmail.com>
> > Date: Wed, 18 May 2011 21:33:21 -0700
> >
> >> On Wed, May 18, 2011 at 9:14 PM, David Miller <davem@davemloft.net> wrote:
> >>> I really would rather see the initial RTO be static and be set to 1
> >>> with fallback RTO of 3.
> >>
> >> I can also provide a simple patch for this if you want to start from
> >> there. And then maybe we can discuss having a runtime knob some more
> >> :-)
> >
> > Yeah why don't we do that :-)
>
> Alright, here we go.
>
>
> include/net/tcp.h | 5 ++++-
> net/ipv4/tcp_input.c | 13 +++++++++----
> 2 files changed, 13 insertions(+), 5 deletions(-)
>
> diff --git a/include/net/tcp.h b/include/net/tcp.h
> index cda30ea..274d761 100644
> --- a/include/net/tcp.h
> +++ b/include/net/tcp.h
> @@ -122,7 +122,10 @@ extern void tcp_time_wait(struct sock *sk, int state, int timeo);
> #endif
> #define TCP_RTO_MAX ((unsigned)(120*HZ))
> #define TCP_RTO_MIN ((unsigned)(HZ/5))
> -#define TCP_TIMEOUT_INIT ((unsigned)(3*HZ)) /* RFC 1122 initial RTO value */
> +/* The next 2 values come from Draft RFC 2988bis-02. */
> +#define TCP_TIMEOUT_INIT ((unsigned)(1*HZ)) /* initial RTO value */
> +#define TCP_TIMEOUT_INIT_FALLBACK ((unsigned)(3*HZ)) /* initial RTO to fallback to when
> + * a timeout happens during the 3WHS. */
>
> #define TCP_RESOURCE_PROBE_INTERVAL ((unsigned)(HZ/2U)) /* Maximal interval between probes
> * for local resources.
> diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
> index bef9f04..a36bc35 100644
> --- a/net/ipv4/tcp_input.c
> +++ b/net/ipv4/tcp_input.c
> @@ -868,6 +868,11 @@ static void tcp_init_metrics(struct sock *sk)
> {
> struct tcp_sock *tp = tcp_sk(sk);
> struct dst_entry *dst = __sk_dst_get(sk);
> + /* If we had to retransmit anything during the 3WHS, use
> + * the initial fallback RTO as per draft RFC 2988bis-02.
> + */
> + int init_rto = inet_csk(sk)->icsk_retransmits ?
> + TCP_TIMEOUT_INIT_FALLBACK : TCP_TIMEOUT_INIT;
>
> if (dst == NULL)
> goto reset;
> @@ -890,7 +895,7 @@ static void tcp_init_metrics(struct sock *sk)
> if (dst_metric(dst, RTAX_RTT) == 0)
> goto reset;
>
> - if (!tp->srtt && dst_metric_rtt(dst, RTAX_RTT) < (TCP_TIMEOUT_INIT << 3))
> + if (!tp->srtt && dst_metric_rtt(dst, RTAX_RTT) < (init_rto << 3))
> goto reset;
>
> /* Initial rtt is determined from SYN,SYN-ACK.
> @@ -916,7 +921,7 @@ static void tcp_init_metrics(struct sock *sk)
> tp->mdev_max = tp->rttvar = max(tp->mdev, tcp_rto_min(sk));
> }
> tcp_set_rto(sk);
> - if (inet_csk(sk)->icsk_rto < TCP_TIMEOUT_INIT && !tp->rx_opt.saw_tstamp) {
> + if (inet_csk(sk)->icsk_rto < init_rto && !tp->rx_opt.saw_tstamp) {
> reset:
> /* Play conservative. If timestamps are not
> * supported, TCP will fail to recalculate correct
> @@ -924,8 +929,8 @@ reset:
> */
> if (!tp->rx_opt.saw_tstamp && tp->srtt) {
> tp->srtt = 0;
> - tp->mdev = tp->mdev_max = tp->rttvar = TCP_TIMEOUT_INIT;
> - inet_csk(sk)->icsk_rto = TCP_TIMEOUT_INIT;
> + tp->mdev = tp->mdev_max = tp->rttvar = init_rto;
> + inet_csk(sk)->icsk_rto = init_rto;
> }
> }
> tp->snd_cwnd = tcp_init_cwnd(tp, dst);
> --
> 1.7.0.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] Add libertas_disablemesh module parameter to disable mesh interface
From: Dan Williams @ 2011-05-19 17:16 UTC (permalink / raw)
To: Sascha Silbe
Cc: linux-wireless, devel, John, W.Linville, linville, libertas-dev,
netdev, linux-kernel
In-Reply-To: <1305290935-sup-4547@xo15-sascha.sascha.silbe.org>
On Fri, 2011-05-13 at 15:16 +0200, Sascha Silbe wrote:
> Excerpts from Dan Williams's message of Thu May 12 05:11:36 +0200 2011:
> > On Wed, 2011-05-11 at 14:52 +0200, Sascha Silbe wrote:
> > > This allows individual users and deployments to disable mesh support at
> > > runtime, i.e. without having to build and maintain a custom kernel.
>
> > Does the mesh interface somehow cause problems, even when nothing is
> > using it?
>
> Some people suspect it does, but there's no hard data showing that. But
> then the problems are often hard to reproduce in the first place, so
> proving a correlation with mesh is even harder.
That's not an excuse for not finding and fixing the problem though.
What problems are we actually talking about here?
> The hardware based mesh support is based on an outdated draft of
> 802.11s and not interoperable with any other device AFAIK. For most
> users Ad-hoc networks are the better option. Disabling mesh support as
> low-level as possible makes it less likely that any remains are causing
> trouble. With at least four layers (firmware, kernel, NM, Sugar)
> involved in managing connectivity and one of the (firmware) being closed
> source, I prefer to simplify things by eliminating three layers for
> functionality we don't intend to use. It makes debugging (and
> blaming ;) ) a lot easier.
>
> In the field, mesh support is currently disabled using
> /sys/class/net/eth0/lbs_mesh. However, it comes back after resume
> (possibly only if powercycled) and needs to be disabled again by
> post-resume hacks. Race conditions with NM are possible.
That's a parameter handled by the driver; so shouldn't we make sure it's
respected again on resume?
> A user space option would be to teach NM to disable mesh support (at
> runtime - we don't want to ship a custom NM package). I'd expect the
> patch to be much more invasive than the one posted for libertas.
Not really, but we already have on/off for a bunch of other stuff, I
don't see why we can't add one for OLPC mesh.
Dan
^ permalink raw reply
* [PATCH RFC] virtio_ring: fix delayed enable cb implementation
From: Michael S. Tsirkin @ 2011-05-19 17:12 UTC (permalink / raw)
To: rusty, habanero, Shirley Ma, Krishna Kumar2, kvm, steved,
Tom Lendacky <tahm@
Cc: virtualization, netdev, linux-kernel
Fix some signed/assigned mistakes in virtqueue_enable_cb_delayed
by using u16 math all over.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
I'll put this on my v1 branch as well
@@ -398,7 +397,7 @@ EXPORT_SYMBOL_GPL(virtqueue_enable_cb);
bool virtqueue_enable_cb_delayed(struct virtqueue *_vq)
{
struct vring_virtqueue *vq = to_vvq(_vq);
- int bufs;
+ u16 bufs;
START_USE(vq);
@@ -412,7 +411,7 @@ bool virtqueue_enable_cb_delayed(struct virtqueue *_vq)
bufs = (vq->vring.avail->idx - vq->last_used_idx) * 3 / 4;
vring_used_event(&vq->vring) = vq->last_used_idx + bufs;
virtio_mb();
- if (unlikely(vq->vring.used->idx - vq->last_used_idx > bufs)) {
+ if (unlikely((u16)(vq->vring.used->idx - vq->last_used_idx) > bufs)) {
END_USE(vq);
return false;
}
--
1.7.5.53.gc233e
^ permalink raw reply
* Re: [PATCH] tcp: Implement a two-level initial RTO as per draft RFC 2988bis-02.
From: tsuna @ 2011-05-19 17:11 UTC (permalink / raw)
To: Alexander Zimmermann
Cc: Hagen Paul Pfeifer, David Miller, kuznet, pekkas, jmorris,
yoshfuji, kaber, eric.dumazet, netdev, linux-kernel
In-Reply-To: <1456193D-84D1-46E2-B930-8FD0A5B8C409@comsys.rwth-aachen.de>
On Thu, May 19, 2011 at 9:55 AM, Alexander Zimmermann
<alexander.zimmermann@comsys.rwth-aachen.de> wrote:
> Exactly. This is the point. It's *your* environment. However, TCP is
> general purpose. And for the wider internet 1s is know to be save. See the
> measurements in the draft that Mark Allman run.
That's right, there's no one-size-fits-all solution. That's why I'm
in favor of keeping a reasonably conservative default (say 1s to 3s,
so we don't break the Internets) and giving people a knob to adjust it
to whatever makes sense for them.
Looking through the kernel, I see that SCTP already has knobs for
this: sctp_rto_initial, sctp_rto_min, sctp_rto_max. You can even
control the constants used to update rttvar and srtt: sctp_rto_alpha,
sctp_rto_beta
--
Benoit "tsuna" Sigoure
Software Engineer @ www.StumbleUpon.com
^ permalink raw reply
* Re: kernel BUG at net/ipv4/tcp_output.c:1006!
From: Eric Dumazet @ 2011-05-19 17:11 UTC (permalink / raw)
To: TB; +Cc: David Miller, linux-kernel, netdev
In-Reply-To: <4DD54E89.7050707@techboom.com>
Le jeudi 19 mai 2011 à 13:08 -0400, TB a écrit :
> On 11-05-13 04:01 PM, David Miller wrote:
> > From: Eric Dumazet <eric.dumazet@gmail.com>
> > Date: Fri, 13 May 2011 21:47:38 +0200
> >
> >> I suspect we should push commit 2fceec13375e5d98 (tcp: len check is
> >> unnecessarily devastating, change to WARN_ON) to stable if not already
> >> done...
> >>
> >> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=2fceec13375e5d98
> >>
> >> David, is this commit in your stable queue ?
> >
> > No, but now it is.
>
> We've put this commit with the previous tcp_cubic patch on 60 of our
> servers and we're waiting to see how it goes.
Dont expect too much. It only permits to survive after logging messages,
instead of halting machine ;)
^ permalink raw reply
* Re: kernel BUG at net/ipv4/tcp_output.c:1006!
From: TB @ 2011-05-19 17:08 UTC (permalink / raw)
To: David Miller; +Cc: eric.dumazet, linux-kernel, netdev
In-Reply-To: <20110513.160138.1477780250019480052.davem@davemloft.net>
On 11-05-13 04:01 PM, David Miller wrote:
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Fri, 13 May 2011 21:47:38 +0200
>
>> I suspect we should push commit 2fceec13375e5d98 (tcp: len check is
>> unnecessarily devastating, change to WARN_ON) to stable if not already
>> done...
>>
>> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=2fceec13375e5d98
>>
>> David, is this commit in your stable queue ?
>
> No, but now it is.
We've put this commit with the previous tcp_cubic patch on 60 of our
servers and we're waiting to see how it goes.
^ permalink raw reply
* Re: [PATCH] tcp: Implement a two-level initial RTO as per draft RFC 2988bis-02.
From: Alexander Zimmermann @ 2011-05-19 16:55 UTC (permalink / raw)
To: tsuna
Cc: Hagen Paul Pfeifer, David Miller, kuznet, pekkas, jmorris,
yoshfuji, kaber, eric.dumazet, netdev, linux-kernel
In-Reply-To: <BANLkTimSZEbnNVzi3UvBFndHp25S0ow7YQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1647 bytes --]
Am 19.05.2011 um 18:40 schrieb tsuna:
> On Thu, May 19, 2011 at 1:02 AM, Hagen Paul Pfeifer <hagen@jauu.net> wrote:
>> So yes, it CAN be wise to choose other lower/upper bounds. But keep in
>> mind that we should NOT artificial limit ourself. I can image data center
>> scenarios where a initial RTO of <1 match perfectly.
>
> Yes that's exactly the point I was trying to make when talking to
> Alexander offline. On today's Internet, RTTs are easily in the
> hundreds of ms, and initRTO is 3s, so there's 2 orders of magnitude of
> difference. In my environment,
Exactly. This is the point. It's *your* environment. However, TCP is
general purpose. And for the wider internet 1s is know to be save. See the
measurements in the draft that Mark Allman run.
> if my RTT is ~2µs, an initRTO of 200ms
> means that there's a gap of 6 orders of magnitude (!).
Currently, initRTO is 3s. So you the gap is even larger.
> And yes,
> although I don't work for High Frequency Trading companies in Wall
> Street, I'm already buying switches full of line-rate 10Gb ports with
> a port-to-port latency of 500ns for L2/L3 forwarding/switching. I
> expect this kind of network gear will quickly become prevalent in
> datacenter/backend environments.
>
> --
> Benoit "tsuna" Sigoure
> Software Engineer @ www.StumbleUpon.com
//
// Dipl.-Inform. Alexander Zimmermann
// Department of Computer Science, Informatik 4
// RWTH Aachen University
// Ahornstr. 55, 52056 Aachen, Germany
// phone: (49-241) 80-21422, fax: (49-241) 80-22222
// email: zimmermann@cs.rwth-aachen.de
// web: http://www.umic-mesh.net
//
[-- Attachment #2: Signierter Teil der Nachricht --]
[-- Type: application/pgp-signature, Size: 243 bytes --]
^ permalink raw reply
* Re: [PATCH] tcp: Implement a two-level initial RTO as per draft RFC 2988bis-02.
From: tsuna @ 2011-05-19 16:40 UTC (permalink / raw)
To: Hagen Paul Pfeifer
Cc: Alexander Zimmermann, David Miller, kuznet, pekkas, jmorris,
yoshfuji, kaber, eric.dumazet, netdev, linux-kernel
In-Reply-To: <ef84de89c2597793d4cca5eee446ba90@localhost>
On Thu, May 19, 2011 at 1:02 AM, Hagen Paul Pfeifer <hagen@jauu.net> wrote:
> So yes, it CAN be wise to choose other lower/upper bounds. But keep in
> mind that we should NOT artificial limit ourself. I can image data center
> scenarios where a initial RTO of <1 match perfectly.
Yes that's exactly the point I was trying to make when talking to
Alexander offline. On today's Internet, RTTs are easily in the
hundreds of ms, and initRTO is 3s, so there's 2 orders of magnitude of
difference. In my environment, if my RTT is ~2µs, an initRTO of 200ms
means that there's a gap of 6 orders of magnitude (!). And yes,
although I don't work for High Frequency Trading companies in Wall
Street, I'm already buying switches full of line-rate 10Gb ports with
a port-to-port latency of 500ns for L2/L3 forwarding/switching. I
expect this kind of network gear will quickly become prevalent in
datacenter/backend environments.
--
Benoit "tsuna" Sigoure
Software Engineer @ www.StumbleUpon.com
^ permalink raw reply
* Re: [PATCH 4/4] rps: Inspect GRE encapsulated packets to get flow hash
From: Eric Dumazet @ 2011-05-19 16:16 UTC (permalink / raw)
To: Tom Herbert; +Cc: davem, netdev
In-Reply-To: <alpine.DEB.2.00.1105190827420.12804@pokey.mtv.corp.google.com>
Le jeudi 19 mai 2011 à 08:39 -0700, Tom Herbert a écrit :
> Crack open GRE packets in __skb_get_rxhash to compute 4-tuple hash on
> in encapsulated packet. Note that this is used only when the
> __skb_get_rxhash is taken, in particular only when the device does
> not compute provide the rxhash (ie. feature is disabled).
>
> This was tested by creating a single GRE tunnel between two 16 core
> AMD machines. 200 netperf TCP_RR streams were ran with 1 byte
> request and response size.
>
> Without patch: 157497 tps, 50/90/99% latencies 1250/1292/1364 usecs
> With patch: 325896 tps, 50/90/99% latencies 603/848/1169
>
> Signed-off-by: Tom Herbert <therbert@google.com>
> ---
> net/core/dev.c | 22 ++++++++++++++++++++++
> 1 files changed, 22 insertions(+), 0 deletions(-)
>
> diff --git a/net/core/dev.c b/net/core/dev.c
> index 0c83494..7799bbd 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -2552,6 +2552,28 @@ again:
> }
>
> switch (ip_proto) {
> + case IPPROTO_GRE:
> + if (pskb_may_pull(skb, nhoff + 16)) {
> + u8 *h = skb->data + nhoff;
> + __be16 flags = *(__be16 *)h;
> +
> + /*
> + * Only look inside GRE if version zero and no
> + * routing
> + */
> + if (!(flags & (GRE_VERSION|GRE_ROUTING))) {
> + proto = *(__be16 *)(h + 2);
> + nhoff += 4;
> + if (flags & GRE_CSUM)
> + nhoff += 4;
> + if (flags & GRE_KEY)
> + nhoff += 4;
> + if (flags & GRE_SEQ)
> + nhoff += 4;
> + goto again;
> + }
> + }
> + break;
> default:
> break;
> }
Hi Tom
For sure it helps if this machine is the final host for these packets.
If I am a firewall or router [and not looking into GRE packets], maybe I
dont want to spread all packets received on a tunnel to several cpus and
reorder them when forwarded.
Maybe we need to add a table, so that upper layer (GRE or IPIP tunnels)
can instruct __skb_get_rxhash() that we want to deep inspect packets.
1) Say we keep rxhash first evaluation be the one we have today.
2) Do a hash lookup in a new table to tell if upper layer handled a
previous packet for this first level flow and want more inspection.
3) table could contains 'pointers' to decoding function, that would
recompute a new rxhash function.
4) Find a way to "clean the table", garbage collect or expirations times
can do.
This way we can add stuff in GRE and IPIP modules [and other kind of
tunnels], without layer violations ?
^ permalink raw reply
* Re: [Bridge] [Patch] bridge: call NETDEV_ENSLAVE notifiers when adding a slave
From: Stephen Hemminger @ 2011-05-19 16:04 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Amerigo Wang, Neil Horman, bridge, netdev, Jay Vosburgh,
linux-kernel, akpm, David S. Miller
In-Reply-To: <20110519081213.15c05da2@nehalam>
On Thu, 19 May 2011 08:12:13 -0700
Stephen Hemminger <shemminger@linux-foundation.org> wrote:
> On Thu, 19 May 2011 18:24:17 +0800
> Amerigo Wang <amwang@redhat.com> wrote:
>
> > In the previous patch I added NETDEV_ENSLAVE, now
> > we can notify netconsole when adding a device to a bridge too.
> >
> > By the way, s/netdev_bonding_change/call_netdevice_notifiers/ in
> > bond_main.c, since this is not bonding specific.
> >
> > Signed-off-by: WANG Cong <amwang@redhat.com>
> > Cc: Neil Horman <nhorman@redhat.com>
> >
>
> Is there a usage for this? What listens for this notification?
Never mind it was in the first patch which you did not send.
You should always put a number on group of patches and send
to all parties.
Also, sending networking patches to LKML is a waste of bandwidth
please don't bother.
^ permalink raw reply
* [PATCH 4/4] rps: Inspect GRE encapsulated packets to get flow hash
From: Tom Herbert @ 2011-05-19 15:39 UTC (permalink / raw)
To: davem, netdev
Crack open GRE packets in __skb_get_rxhash to compute 4-tuple hash on
in encapsulated packet. Note that this is used only when the
__skb_get_rxhash is taken, in particular only when the device does
not compute provide the rxhash (ie. feature is disabled).
This was tested by creating a single GRE tunnel between two 16 core
AMD machines. 200 netperf TCP_RR streams were ran with 1 byte
request and response size.
Without patch: 157497 tps, 50/90/99% latencies 1250/1292/1364 usecs
With patch: 325896 tps, 50/90/99% latencies 603/848/1169
Signed-off-by: Tom Herbert <therbert@google.com>
---
net/core/dev.c | 22 ++++++++++++++++++++++
1 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index 0c83494..7799bbd 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2552,6 +2552,28 @@ again:
}
switch (ip_proto) {
+ case IPPROTO_GRE:
+ if (pskb_may_pull(skb, nhoff + 16)) {
+ u8 *h = skb->data + nhoff;
+ __be16 flags = *(__be16 *)h;
+
+ /*
+ * Only look inside GRE if version zero and no
+ * routing
+ */
+ if (!(flags & (GRE_VERSION|GRE_ROUTING))) {
+ proto = *(__be16 *)(h + 2);
+ nhoff += 4;
+ if (flags & GRE_CSUM)
+ nhoff += 4;
+ if (flags & GRE_KEY)
+ nhoff += 4;
+ if (flags & GRE_SEQ)
+ nhoff += 4;
+ goto again;
+ }
+ }
+ break;
default:
break;
}
--
1.7.3.1
^ permalink raw reply related
* [PATCH 3/4] rps: Infrastructure in __skb_get_rxhash for deep inspection
From: Tom Herbert @ 2011-05-19 15:39 UTC (permalink / raw)
To: davem, netdev
Basics for looking for ports in encapsulated packets in tunnels.
Signed-off-by: Tom Herbert <therbert@google.com>
---
net/core/dev.c | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index 37ddece..0c83494 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -133,6 +133,7 @@
#include <linux/pci.h>
#include <linux/inetdevice.h>
#include <linux/cpu_rmap.h>
+#include <linux/if_tunnel.h>
#include "net-sysfs.h"
@@ -2521,6 +2522,7 @@ void __skb_get_rxhash(struct sk_buff *skb)
nhoff = skb_network_offset(skb);
proto = skb->protocol;
+again:
switch (proto) {
case __constant_htons(ETH_P_IP):
if (!pskb_may_pull(skb, sizeof(*ip) + nhoff))
@@ -2549,6 +2551,11 @@ void __skb_get_rxhash(struct sk_buff *skb)
goto done;
}
+ switch (ip_proto) {
+ default:
+ break;
+ }
+
ports.v32 = 0;
poff = proto_ports_offset(ip_proto);
if (poff >= 0) {
--
1.7.3.1
^ permalink raw reply related
* [PATCH 2/4] rps: Add flag to skb to indicate rxhash is on L4 tuple
From: Tom Herbert @ 2011-05-19 15:39 UTC (permalink / raw)
To: davem, netdev
The l4_rxhash flag was added to the skb structure to indicate
that the rxhash value was computed over the 4 tuple for the
packet which includes the port information in the encapsulated
transport packet. This is used by the stack to preserve the
rxhash value in __skb_rx_tunnel.
Signed-off-by: Tom Herbert <therbert@google.com>
---
include/linux/skbuff.h | 5 +++--
include/net/dst.h | 9 ++++++++-
include/net/sock.h | 14 +++++++++++---
net/core/dev.c | 17 +++++++++++------
net/core/skbuff.c | 1 +
net/ipv4/tcp_ipv4.c | 4 ++--
net/ipv4/udp.c | 4 ++--
7 files changed, 38 insertions(+), 16 deletions(-)
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 79aafbb..4fab336 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -397,6 +397,7 @@ struct sk_buff {
__u8 ndisc_nodetype:2;
#endif
__u8 ooo_okay:1;
+ __u8 l4_rxhash:1;
kmemcheck_bitfield_end(flags2);
/* 0/13 bit hole */
@@ -555,11 +556,11 @@ extern unsigned int skb_find_text(struct sk_buff *skb, unsigned int from,
unsigned int to, struct ts_config *config,
struct ts_state *state);
-extern __u32 __skb_get_rxhash(struct sk_buff *skb);
+extern void __skb_get_rxhash(struct sk_buff *skb);
static inline __u32 skb_get_rxhash(struct sk_buff *skb)
{
if (!skb->rxhash)
- skb->rxhash = __skb_get_rxhash(skb);
+ __skb_get_rxhash(skb);
return skb->rxhash;
}
diff --git a/include/net/dst.h b/include/net/dst.h
index 07a0402..17ff602 100644
--- a/include/net/dst.h
+++ b/include/net/dst.h
@@ -307,7 +307,14 @@ static inline void skb_dst_force(struct sk_buff *skb)
static inline void __skb_tunnel_rx(struct sk_buff *skb, struct net_device *dev)
{
skb->dev = dev;
- skb->rxhash = 0;
+
+ /*
+ * Clear rxhash so that we can reculate the hash for the
+ * encapsulated packet, unless we have already determine the hash
+ * over the L4 4-tuple.
+ */
+ if (!skb->l4_rxhash)
+ skb->rxhash = 0;
skb_set_queue_mapping(skb, 0);
skb_dst_drop(skb);
nf_reset(skb);
diff --git a/include/net/sock.h b/include/net/sock.h
index f2046e4..e670c41 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -685,16 +685,24 @@ static inline void sock_rps_reset_flow(const struct sock *sk)
#endif
}
-static inline void sock_rps_save_rxhash(struct sock *sk, u32 rxhash)
+static inline void sock_rps_save_rxhash(struct sock *sk, struct sk_buff *skb)
{
#ifdef CONFIG_RPS
- if (unlikely(sk->sk_rxhash != rxhash)) {
+ if (unlikely(sk->sk_rxhash != skb->rxhash)) {
sock_rps_reset_flow(sk);
- sk->sk_rxhash = rxhash;
+ sk->sk_rxhash = skb->rxhash;
}
#endif
}
+static inline void sock_rps_reset_rxhash(struct sock *sk)
+{
+#ifdef CONFIG_RPS
+ sock_rps_reset_flow(sk);
+ sk->sk_rxhash = 0;
+#endif
+}
+
#define sk_wait_event(__sk, __timeo, __condition) \
({ int __rc; \
release_sock(__sk); \
diff --git a/net/core/dev.c b/net/core/dev.c
index a40eea9..37ddece 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2014,8 +2014,10 @@ static inline void skb_orphan_try(struct sk_buff *skb)
/* skb_tx_hash() wont be able to get sk.
* We copy sk_hash into skb->rxhash
*/
- if (!skb->rxhash)
+ if (!skb->rxhash) {
skb->rxhash = sk->sk_hash;
+ skb->l4_rxhash = 1;
+ }
skb_orphan(skb);
}
}
@@ -2499,12 +2501,13 @@ static inline void ____napi_schedule(struct softnet_data *sd,
/*
* __skb_get_rxhash: calculate a flow hash based on src/dst addresses
- * and src/dst port numbers. Returns a non-zero hash number on success
- * and 0 on failure.
+ * and src/dst port numbers. Sets rxhash in skb to non-zero hash value
+ * on success, zero indicates no valid hash. Also, sets l4_rxhash in skb
+ * if hash is a canonical 4-tuple hash over transport ports.
*/
-__u32 __skb_get_rxhash(struct sk_buff *skb)
+void __skb_get_rxhash(struct sk_buff *skb)
{
- int nhoff, hash = 0, poff;
+ int nhoff, hash = 0, l4hash = 0, poff;
const struct ipv6hdr *ip6;
const struct iphdr *ip;
u8 ip_proto;
@@ -2554,6 +2557,7 @@ __u32 __skb_get_rxhash(struct sk_buff *skb)
ports.v32 = * (__force u32 *) (skb->data + nhoff);
if (ports.v16[1] < ports.v16[0])
swap(ports.v16[0], ports.v16[1]);
+ l4hash = 1;
}
}
@@ -2566,7 +2570,8 @@ __u32 __skb_get_rxhash(struct sk_buff *skb)
hash = 1;
done:
- return hash;
+ skb->rxhash = hash;
+ skb->l4_rxhash = l4hash;
}
EXPORT_SYMBOL(__skb_get_rxhash);
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 7ebeed0..cb5c67d 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -513,6 +513,7 @@ static void __copy_skb_header(struct sk_buff *new, const struct sk_buff *old)
new->mac_header = old->mac_header;
skb_dst_copy(new, old);
new->rxhash = old->rxhash;
+ new->l4_rxhash = old->l4_rxhash;
#ifdef CONFIG_XFRM
new->sp = secpath_get(old->sp);
#endif
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index 3c8d9b6..a4b156dc 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -1572,7 +1572,7 @@ int tcp_v4_do_rcv(struct sock *sk, struct sk_buff *skb)
#endif
if (sk->sk_state == TCP_ESTABLISHED) { /* Fast path */
- sock_rps_save_rxhash(sk, skb->rxhash);
+ sock_rps_save_rxhash(sk, skb);
if (tcp_rcv_established(sk, skb, tcp_hdr(skb), skb->len)) {
rsk = sk;
goto reset;
@@ -1596,7 +1596,7 @@ int tcp_v4_do_rcv(struct sock *sk, struct sk_buff *skb)
return 0;
}
} else
- sock_rps_save_rxhash(sk, skb->rxhash);
+ sock_rps_save_rxhash(sk, skb);
if (tcp_rcv_state_process(sk, skb, tcp_hdr(skb), skb->len)) {
rsk = sk;
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index 599374f..d2277cf 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -1263,7 +1263,7 @@ int udp_disconnect(struct sock *sk, int flags)
sk->sk_state = TCP_CLOSE;
inet->inet_daddr = 0;
inet->inet_dport = 0;
- sock_rps_save_rxhash(sk, 0);
+ sock_rps_reset_rxhash(sk);
sk->sk_bound_dev_if = 0;
if (!(sk->sk_userlocks & SOCK_BINDADDR_LOCK))
inet_reset_saddr(sk);
@@ -1351,7 +1351,7 @@ static int __udp_queue_rcv_skb(struct sock *sk, struct sk_buff *skb)
int rc;
if (inet_sk(sk)->inet_daddr)
- sock_rps_save_rxhash(sk, skb->rxhash);
+ sock_rps_save_rxhash(sk, skb);
rc = ip_queue_rcv_skb(sk, skb);
if (rc < 0) {
--
1.7.3.1
^ permalink raw reply related
* [PATCH 1/4] rps: Some minor cleanup in get_rps_cpus
From: Tom Herbert @ 2011-05-19 15:39 UTC (permalink / raw)
To: davem, netdev
Use some variables for clarity and extensibility.
Signed-off-by: Tom Herbert <therbert@google.com>
---
net/core/dev.c | 12 +++++++-----
1 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index 155de20..a40eea9 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2508,15 +2508,17 @@ __u32 __skb_get_rxhash(struct sk_buff *skb)
const struct ipv6hdr *ip6;
const struct iphdr *ip;
u8 ip_proto;
- u32 addr1, addr2, ihl;
+ u32 addr1, addr2;
+ u16 proto;
union {
u32 v32;
u16 v16[2];
} ports;
nhoff = skb_network_offset(skb);
+ proto = skb->protocol;
- switch (skb->protocol) {
+ switch (proto) {
case __constant_htons(ETH_P_IP):
if (!pskb_may_pull(skb, sizeof(*ip) + nhoff))
goto done;
@@ -2528,7 +2530,7 @@ __u32 __skb_get_rxhash(struct sk_buff *skb)
ip_proto = ip->protocol;
addr1 = (__force u32) ip->saddr;
addr2 = (__force u32) ip->daddr;
- ihl = ip->ihl;
+ nhoff += ip->ihl * 4;
break;
case __constant_htons(ETH_P_IPV6):
if (!pskb_may_pull(skb, sizeof(*ip6) + nhoff))
@@ -2538,7 +2540,7 @@ __u32 __skb_get_rxhash(struct sk_buff *skb)
ip_proto = ip6->nexthdr;
addr1 = (__force u32) ip6->saddr.s6_addr32[3];
addr2 = (__force u32) ip6->daddr.s6_addr32[3];
- ihl = (40 >> 2);
+ nhoff += 40;
break;
default:
goto done;
@@ -2547,7 +2549,7 @@ __u32 __skb_get_rxhash(struct sk_buff *skb)
ports.v32 = 0;
poff = proto_ports_offset(ip_proto);
if (poff >= 0) {
- nhoff += ihl * 4 + poff;
+ nhoff += poff;
if (pskb_may_pull(skb, nhoff + 4)) {
ports.v32 = * (__force u32 *) (skb->data + nhoff);
if (ports.v16[1] < ports.v16[0])
--
1.7.3.1
^ permalink raw reply related
* [PATCH 0/4] rps: Look into tunnels to get hash
From: Tom Herbert @ 2011-05-19 15:38 UTC (permalink / raw)
To: davem, netdev
The patches in this series are to look into encapsulated packets
to compute the rx hash for RPS. Before these patches, all packets
received on the same tunnel would wind up on the same RPS CPU-- this
can lead to very poor loading, and make RFS ineffective on these
packets.
This patch supports getting the rxhash out of a GRE encapsulated packet.
A couple of caveats:
- rxhash should be disabled in device to be able to use this. I believe
probably all NICs would just provide rxhash on the outer packet
2-tuple.
- The l4_rxhash flag was added so that the hash is preserved across the
tunnel and can set in flow tables by the transport. It would be nice
it driverswould set this to so to provide more useful information to the
stack (like whether the rxhash hash should be used in the flow table).
Unfortutunately, I don't think all drivers will be able to distinguish
the type of hash (2-tuple, 4-tuple, ...) without looking into the
packet.
^ permalink raw reply
* RE: [RFC V4 PATCH] rtnetlink: Compute and store minimum ifinfo dump size
From: Rose, Gregory V @ 2011-05-19 15:35 UTC (permalink / raw)
To: Rose, Gregory V, David Miller
Cc: netdev@vger.kernel.org, bhutchings@solarflare.com,
eric.dumazet@gmail.com
In-Reply-To: <43F901BD926A4E43B106BF17856F0755018E321C4C@orsmsx508.amr.corp.intel.com>
> -----Original Message-----
> From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org]
> On Behalf Of Rose, Gregory V
> Sent: Wednesday, May 18, 2011 3:49 PM
> To: David Miller
> Cc: netdev@vger.kernel.org; bhutchings@solarflare.com;
> eric.dumazet@gmail.com
> Subject: RE: [RFC V4 PATCH] rtnetlink: Compute and store minimum ifinfo
> dump size
>
> > -----Original Message-----
> > From: David Miller [mailto:davem@davemloft.net]
> > Sent: Wednesday, May 18, 2011 3:48 PM
> > To: Rose, Gregory V
> > Cc: netdev@vger.kernel.org; bhutchings@solarflare.com;
> > eric.dumazet@gmail.com
> > Subject: Re: [RFC V4 PATCH] rtnetlink: Compute and store minimum ifinfo
> > dump size
> >
> > From: "Rose, Gregory V" <gregory.v.rose@intel.com>
> > Date: Wed, 18 May 2011 15:35:58 -0700
> >
> > > It looked to me like rtmsg_ifinfo is called when each device is
> > > registered through register_netdevice() and rtmsg_ifinfo in turn
> > > calls the if_nlmsg_size function returning the ifinfo dump size for
> > > each device. In my testing it looked like the proper maximum size
> > > was being set after I loaded the drivers for the SR-IOV capable
> > > devices.
> >
> > Aha, indeed you're right. I missed this part. Thanks for explaining.
> >
> > So as far as I can tell it should work, I'll let others review it to
> > see if they are ok with this approach.
>
> Ok, sure. We'll see if Eric catches anything, he's got an eagle eye.
Having seen no further comments on this RFC I am going to clean up the patch and submit it to our internal review list for further testing and validation. If/when it passes through that process I'll post it back here.
Thanks to all who commented and made suggestions for improvement.
- Greg
^ permalink raw reply
* Re: [PATCH v3] ipconfig wait for carrier
From: Dan Williams @ 2011-05-19 15:31 UTC (permalink / raw)
To: David Miller; +Cc: micha, netdev
In-Reply-To: <20110518.181427.1228926976939865196.davem@davemloft.net>
On Wed, 2011-05-18 at 18:14 -0400, David Miller wrote:
> From: Micha Nelissen <micha@neli.hopto.org>
> Date: Wed, 18 May 2011 08:59:32 +0200
>
> > Op 2011-05-18 8:37, David Miller schreef:
> >> From: Micha Nelissen<micha@neli.hopto.org>
> >> Date: Wed, 18 May 2011 08:32:35 +0200
> >>
> >>> I'm confused. Against which tree/commit do you want it then?
> >>
> >> Linus's current tree would be fine as would:
> >>
> >> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6.git
> >
> > Ok I see, thanks. The patch should apply just fine to your tree, there
> > is only a spelling change since 2.6.38 which does not conflict.
>
> Please fix ic_is_init_dev() to return a proper boolean "false" instead
> of "0" when IFF_LOOPBACK is set.
Shouldn't the code still wait at *least* one second? Not all drivers
support carrier detect, and those that don't set the carrier always-on.
Thus older devices that used to have 1s to get carrier in line (even if
they don't report it) now have only 10ms.
I think it should wait at least one second like the code currently does,
and then if the carrier still isn't up, wait longer.
Dan
^ permalink raw reply
* Re: [Patch] bridge: call NETDEV_ENSLAVE notifiers when adding a slave
From: Stephen Hemminger @ 2011-05-19 15:12 UTC (permalink / raw)
To: Amerigo Wang
Cc: linux-kernel, akpm, Neil Horman, Jay Vosburgh, David S. Miller,
netdev, bridge
In-Reply-To: <1305800661-4081-1-git-send-email-amwang@redhat.com>
On Thu, 19 May 2011 18:24:17 +0800
Amerigo Wang <amwang@redhat.com> wrote:
> In the previous patch I added NETDEV_ENSLAVE, now
> we can notify netconsole when adding a device to a bridge too.
>
> By the way, s/netdev_bonding_change/call_netdevice_notifiers/ in
> bond_main.c, since this is not bonding specific.
>
> Signed-off-by: WANG Cong <amwang@redhat.com>
> Cc: Neil Horman <nhorman@redhat.com>
>
Is there a usage for this? What listens for this notification?
^ permalink raw reply
* [PATCH net-next-2.6] macvlan: Forward unicast frames in bridge mode to lowerdev
From: David Ward @ 2011-05-19 12:53 UTC (permalink / raw)
To: netdev; +Cc: David Ward, Patrick McHardy
Unicast frames between macvlan interfaces in bridge mode are not otherwise
sent to network taps on the lowerdev (as all other macvlan frames are), so
forward the frames to the receive queue of the lowerdev first.
Signed-off-by: David Ward <david.ward@ll.mit.edu>
---
drivers/net/macvlan.c | 6 ++----
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/net/macvlan.c b/drivers/net/macvlan.c
index d7c0bc62..e7de3b3 100644
--- a/drivers/net/macvlan.c
+++ b/drivers/net/macvlan.c
@@ -237,10 +237,8 @@ static int macvlan_queue_xmit(struct sk_buff *skb, struct net_device *dev)
dest = macvlan_hash_lookup(port, eth->h_dest);
if (dest && dest->mode == MACVLAN_MODE_BRIDGE) {
- unsigned int length = skb->len + ETH_HLEN;
- int ret = dest->forward(dest->dev, skb);
- macvlan_count_rx(dest, length,
- ret == NET_RX_SUCCESS, 0);
+ /* send to lowerdev first for its network taps */
+ vlan->forward(vlan->lowerdev, skb);
return NET_XMIT_SUCCESS;
}
--
1.7.4.4
^ permalink raw reply related
* Re: [RFC/PATCH 00/13] wl12xx re-factor
From: Felipe Balbi @ 2011-05-19 14:06 UTC (permalink / raw)
To: Luciano Coelho; +Cc: Felipe Balbi, linux-wireless, netdev, linux-kernel
In-Reply-To: <1305809345.12586.1579.camel@cumari>
[-- Attachment #1: Type: text/plain, Size: 1589 bytes --]
Hi,
On Thu, May 19, 2011 at 03:49:05PM +0300, Luciano Coelho wrote:
> > this is the re-factor I was talking to you
> > about. Please have a look and give your
> > comments.
> >
> > It probably won't work as is, I compile
> > tested only, but it shows the idea.
>
> This looks very good! I think we should do something like this to avoid
> the code that is duplicated in the bus modules.
>
> But, as I already mentioned briefly on IRC, there is a problem with the
> way you changed the platform data structure, because it will break
> compat-wireless. The actual memory and data that is used by the
> platform data is in the board components and not part of the wireless
> subsystem. With compat-wireless, we need to make sure that new stuff
> works with older kernels. In your patches you modify the platform data
> structure, so when we run an old kernel with new compat-wireless, things
> will break.
>
> We already found a similar bug due to a previous change in the platform
> data structure, so I don't want this to happen again. So for now, I'll
> keep these patches aside, but as soon as we find a good solution, I'll
> definitely use your ideas here (or ask you to rebase :P).
>
> I'll probably apply some of the patches that are not related to the
> platform data change. I'll respond to those specific patches
> separately.
ok good. I have stated my POV WRT compatibility layers for in-tree
drivers on a separate thread. In summary, I think those shouldn't exist
at all :-)
Just let me know if you need anything ;-)
--
balbi
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox