* [PATCH] net: fix compile error due to double return type in SOCK_DEBUG
From: Jan Engelhardt @ 2010-05-02 18:00 UTC (permalink / raw)
To: davem; +Cc: netdev
Fix this one:
include/net/sock.h: error: two or more data types in declaration specifiers
Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
---
include/net/sock.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/net/sock.h b/include/net/sock.h
index 56df440..0f0b6d6 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -74,7 +74,7 @@
printk(KERN_DEBUG msg); } while (0)
#else
/* Validate arguments and do nothing */
-static void inline int __attribute__ ((format (printf, 2, 3)))
+static inline void __attribute__ ((format (printf, 2, 3)))
SOCK_DEBUG(struct sock *sk, const char *msg, ...)
{
}
--
1.7.0.5
^ permalink raw reply related
* Re: [PATCH v6] net: batch skb dequeueing from softnet input_pkt_queue
From: Eric Dumazet @ 2010-05-02 19:22 UTC (permalink / raw)
To: Arjan van de Ven
Cc: Andi Kleen, David Miller, hadi, xiaosuo, therbert, shemminger,
netdev, lenb
In-Reply-To: <20100502105418.7abf83a7@infradead.org>
Le dimanche 02 mai 2010 à 10:54 -0700, Arjan van de Ven a écrit :
> On Sun, 02 May 2010 16:27:28 +0200
> Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
> > C2 latency seems to be 64 (us ?), while C1 seems to be 1
>
> the processor_idle module has a "latency_factor" module parameter.
> The default is 2, but sometimes people think 6 is a better value...
> .. any chance you can try that value ?
>
I tried 6 and 20, nothing changed ;(
> Also, I'm starting to wonder if Andi's patch to use io_schedule() needs
> to be replaced with a net_schedule() kind of thing. The cpuidle code
> currently has a weight factor for IO (based on measuring/experiments),
> and maybe networking really needs another factor... so just having a
> parallel concept with a different weight could be the right answer for
> that.
>
But a task blocked on disk IO is probably blocked for a small amount of
time, while on network, it can be for a long time. I am not sure its the
right metric.
I was expecting something based on recent history.
Say if we have 20.000 wakeups per second, most likely we should not
enter C2/C3 states...
>
> we'll fix powertop to report the marketing name soon.
>
>
Ah, I see, thanks :)
^ permalink raw reply
* Re: [PATCH] net: fix compile error due to double return type in SOCK_DEBUG
From: David Miller @ 2010-05-02 20:43 UTC (permalink / raw)
To: jengelh; +Cc: netdev
In-Reply-To: <1272823202-25957-1-git-send-email-jengelh@medozas.de>
From: Jan Engelhardt <jengelh@medozas.de>
Date: Sun, 2 May 2010 20:00:01 +0200
> Fix this one:
> include/net/sock.h: error: two or more data types in declaration specifiers
>
> Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
Applied, thanks Jan.
Shows how many people actually try to mess with that ifdef.
I think we should just kill it off.
^ permalink raw reply
* Re: [PATCH v6] net: batch skb dequeueing from softnet input_pkt_queue
From: Andi Kleen @ 2010-05-02 21:25 UTC (permalink / raw)
To: Eric Dumazet
Cc: David Miller, hadi, xiaosuo, therbert, shemminger, netdev, lenb,
arjan
In-Reply-To: <1272818131.2173.127.camel@edumazet-laptop>
> You mean we can wakeup a thread with something else than an IPI ?
It's pointless to send an IPI to your thread sibling for this.
Everything it could do you can do yourself too with the same performance.
-Andi
^ permalink raw reply
* Re: [PATCH v6] net: batch skb dequeueing from softnet input_pkt_queue
From: Andi Kleen @ 2010-05-02 21:30 UTC (permalink / raw)
To: Arjan van de Ven
Cc: Eric Dumazet, David Miller, hadi, xiaosuo, therbert, shemminger,
netdev, lenb
In-Reply-To: <20100502105418.7abf83a7@infradead.org>
On Sun, May 02, 2010 at 10:54:18AM -0700, Arjan van de Ven wrote:
> On Sun, 02 May 2010 16:27:28 +0200
> Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
> > C2 latency seems to be 64 (us ?), while C1 seems to be 1
>
> the processor_idle module has a "latency_factor" module parameter.
> The default is 2, but sometimes people think 6 is a better value...
> .. any chance you can try that value ?
>
> Also, I'm starting to wonder if Andi's patch to use io_schedule() needs
> to be replaced with a net_schedule() kind of thing. The cpuidle code
> currently has a weight factor for IO (based on measuring/experiments),
> and maybe networking really needs another factor... so just having a
> parallel concept with a different weight could be the right answer for
> that.
We definitely need a net_schedule() for other reasons too: to avoid the blkio
wait code and then also because networking needs a short "fast idle" timeout
because the delays are not bounded.
Otherwise a sender that suddenly stops sending could break all your power
saving.
I think the reference count used in io_schedule is not the right model for
this, probably needs a per cpu timeout ("be fast until this time"). Possibly
a dynamic one feed by the measured input rate.
-Andi
^ permalink raw reply
* Re: [PATCH v6] net: batch skb dequeueing from softnet input_pkt_queue
From: Eric Dumazet @ 2010-05-02 21:45 UTC (permalink / raw)
To: Andi Kleen
Cc: David Miller, hadi, xiaosuo, therbert, shemminger, netdev, lenb,
arjan
In-Reply-To: <20100502212550.GA2673@gargoyle.fritz.box>
Le dimanche 02 mai 2010 à 23:25 +0200, Andi Kleen a écrit :
> It's pointless to send an IPI to your thread sibling for this.
> Everything it could do you can do yourself too with the same performance.
>
> -Andi
Amen
Tests just prove the reverse.
I have some collegues that disable HyperThreading for exact same
reasons. I wonder why Intel designed HT. Should be marketing I guess.
^ permalink raw reply
* Re: [PATCH v6] net: batch skb dequeueing from softnet input_pkt_queue
From: Andi Kleen @ 2010-05-02 21:54 UTC (permalink / raw)
To: Eric Dumazet
Cc: David Miller, hadi, xiaosuo, therbert, shemminger, netdev, lenb,
arjan
In-Reply-To: <1272836755.2173.153.camel@edumazet-laptop>
On Sun, May 02, 2010 at 11:45:55PM +0200, Eric Dumazet wrote:
> Le dimanche 02 mai 2010 à 23:25 +0200, Andi Kleen a écrit :
>
> > It's pointless to send an IPI to your thread sibling for this.
> > Everything it could do you can do yourself too with the same performance.
> >
> > -Andi
>
> Amen
That is in terms of cache locality.
>
> Tests just prove the reverse.
What do you mean?
>
> I have some collegues that disable HyperThreading for exact same
> reasons. I wonder why Intel designed HT. Should be marketing I guess.
HT (especially Nehalem HT) is useful for a wide range of workloads.
Just handling network interrupts for its thread sibling is not one of them.
-Andi
^ permalink raw reply
* Re: [PATCH v6] net: batch skb dequeueing from softnet input_pkt_queue
From: Andi Kleen @ 2010-05-02 22:06 UTC (permalink / raw)
To: Eric Dumazet
Cc: Arjan van de Ven, David Miller, hadi, xiaosuo, therbert,
shemminger, netdev, lenb
In-Reply-To: <1272828143.2173.150.camel@edumazet-laptop>
> But a task blocked on disk IO is probably blocked for a small amount of
> time, while on network, it can be for a long time. I am not sure its the
> right metric.
I think it needs a dynamic timeout.
I agree the reference count as is will not work well for networking.
>
> I was expecting something based on recent history.
> Say if we have 20.000 wakeups per second, most likely we should not
> enter C2/C3 states...
That's what the menu governour already does, it just doesn't work
in some cases :/
-Andi
^ permalink raw reply
* Re: [PATCH v6] net: batch skb dequeueing from softnet input_pkt_queue
From: Eric Dumazet @ 2010-05-02 22:08 UTC (permalink / raw)
To: Andi Kleen
Cc: David Miller, hadi, xiaosuo, therbert, shemminger, netdev, lenb,
arjan
In-Reply-To: <20100502215450.GC2673@gargoyle.fritz.box>
Le dimanche 02 mai 2010 à 23:54 +0200, Andi Kleen a écrit :
> On Sun, May 02, 2010 at 11:45:55PM +0200, Eric Dumazet wrote:
> > Tests just prove the reverse.
>
> What do you mean?
>
Test I did this week with Jamal.
We first set a "ee" rps mask, because all NIC interrupts were handled by
CPU0, and Jamal thought like you, that not using cpu4 would give better
performance.
But using "fe" mask gave me a bonus, from ~700.000 pps to ~800.000 pps
CPU : E5450 @3.00GHz
Two quad-core cpus in the machine, tg3 NIC.
With RPS, CPU0 does not a lot of things, just talk with the NIC, bring a
few cache lines per packet and dispatch it to a slave cpu.
> HT (especially Nehalem HT) is useful for a wide range of workloads.
> Just handling network interrupts for its thread sibling is not one of them.
>
Thats the theory, now in practice I see different results.
Of course, this might be related to hash distribution being different
and more uniform.
I should redo the test with many more flows.
^ permalink raw reply
* [PATCH] ixgb and e1000: Use new function for copybreak tests
From: Joe Perches @ 2010-05-03 0:46 UTC (permalink / raw)
To: Jeff Kirsher
Cc: Jesse Brandeburg, Bruce Allan, Alex Duyck, PJ Waskiewicz,
John Ronciak, e1000-devel, netdev, LKML
There appears to be an off-by-1 defect in the maximum packet size
copied when copybreak is speified in these modules.
The copybreak module params are specified as:
"Maximum size of packet that is copied to a new buffer on receive"
The tests are changed from "< copybreak" to "<= copybreak"
and moved into new static functions for readability.
Signed-off-by: Joe Perches <joe@perches.com>
---
drivers/net/e1000/e1000_main.c | 47 ++++++++++++++++++++---------------
drivers/net/ixgb/ixgb_main.c | 52 +++++++++++++++++++++++----------------
2 files changed, 58 insertions(+), 41 deletions(-)
diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
index e6ebc22..2adc83c 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -3773,6 +3773,31 @@ next_desc:
return cleaned;
}
+/*
+ * this should improve performance for small packets with large amounts
+ * of reassembly being done in the stack
+ */
+static void e1000_check_copybreak(struct net_device *netdev,
+ struct e1000_buffer *buffer_info,
+ u32 length, struct sk_buff **skb)
+{
+ struct sk_buff *new_skb;
+
+ if (length > copybreak)
+ return;
+
+ new_skb = netdev_alloc_skb_ip_align(netdev, length);
+ if (!new_skb)
+ return;
+
+ skb_copy_to_linear_data_offset(new_skb, -NET_IP_ALIGN,
+ (*skb)->data - NET_IP_ALIGN,
+ length + NET_IP_ALIGN);
+ /* save the skb in buffer_info as good */
+ buffer_info->skb = *skb;
+ *skb = new_skb;
+}
+
/**
* e1000_clean_rx_irq - Send received data up the network stack; legacy
* @adapter: board private structure
@@ -3871,26 +3896,8 @@ static bool e1000_clean_rx_irq(struct e1000_adapter *adapter,
total_rx_bytes += length;
total_rx_packets++;
- /* code added for copybreak, this should improve
- * performance for small packets with large amounts
- * of reassembly being done in the stack */
- if (length < copybreak) {
- struct sk_buff *new_skb =
- netdev_alloc_skb_ip_align(netdev, length);
- if (new_skb) {
- skb_copy_to_linear_data_offset(new_skb,
- -NET_IP_ALIGN,
- (skb->data -
- NET_IP_ALIGN),
- (length +
- NET_IP_ALIGN));
- /* save the skb in buffer_info as good */
- buffer_info->skb = skb;
- skb = new_skb;
- }
- /* else just continue with the old one */
- }
- /* end copybreak code */
+ e1000_check_copybreak(netdev, buffer_info, length, &skb);
+
skb_put(skb, length);
/* Receive Checksum Offload */
diff --git a/drivers/net/ixgb/ixgb_main.c b/drivers/net/ixgb/ixgb_main.c
index d58ca6b..c6b75c8 100644
--- a/drivers/net/ixgb/ixgb_main.c
+++ b/drivers/net/ixgb/ixgb_main.c
@@ -1921,6 +1921,31 @@ ixgb_rx_checksum(struct ixgb_adapter *adapter,
}
}
+/*
+ * this should improve performance for small packets with large amounts
+ * of reassembly being done in the stack
+ */
+static void ixgb_check_copybreak(struct net_device *netdev,
+ struct ixgb_buffer *buffer_info,
+ u32 length, struct sk_buff **skb)
+{
+ struct sk_buff *new_skb;
+
+ if (length > copybreak)
+ return;
+
+ new_skb = netdev_alloc_skb_ip_align(netdev, length);
+ if (!new_skb)
+ return;
+
+ skb_copy_to_linear_data_offset(new_skb, -NET_IP_ALIGN,
+ (*skb)->data - NET_IP_ALIGN,
+ length + NET_IP_ALIGN);
+ /* save the skb in buffer_info as good */
+ buffer_info->skb = *skb;
+ *skb = new_skb;
+}
+
/**
* ixgb_clean_rx_irq - Send received data up the network stack,
* @adapter: board private structure
@@ -1957,11 +1982,14 @@ ixgb_clean_rx_irq(struct ixgb_adapter *adapter, int *work_done, int work_to_do)
prefetch(skb->data - NET_IP_ALIGN);
- if (++i == rx_ring->count) i = 0;
+ if (++i == rx_ring->count)
+ i = 0;
next_rxd = IXGB_RX_DESC(*rx_ring, i);
prefetch(next_rxd);
- if ((j = i + 1) == rx_ring->count) j = 0;
+ j = i + 1;
+ if (j == rx_ring->count)
+ j = 0;
next2_buffer = &rx_ring->buffer_info[j];
prefetch(next2_buffer);
@@ -1997,25 +2025,7 @@ ixgb_clean_rx_irq(struct ixgb_adapter *adapter, int *work_done, int work_to_do)
goto rxdesc_done;
}
- /* code added for copybreak, this should improve
- * performance for small packets with large amounts
- * of reassembly being done in the stack */
- if (length < copybreak) {
- struct sk_buff *new_skb =
- netdev_alloc_skb_ip_align(netdev, length);
- if (new_skb) {
- skb_copy_to_linear_data_offset(new_skb,
- -NET_IP_ALIGN,
- (skb->data -
- NET_IP_ALIGN),
- (length +
- NET_IP_ALIGN));
- /* save the skb in buffer_info as good */
- buffer_info->skb = skb;
- skb = new_skb;
- }
- }
- /* end copybreak code */
+ ixgb_check_copybreak(netdev, buffer_info, length, &skb);
/* Good Receive */
skb_put(skb, length);
^ permalink raw reply related
* linux-next: build failure after merge of the net tree
From: Stephen Rothwell @ 2010-05-03 2:08 UTC (permalink / raw)
To: David Miller, netdev; +Cc: linux-next, linux-kernel, Eric Dumazet, Wei Yongjun
[-- Attachment #1: Type: text/plain, Size: 774 bytes --]
Hi Dave,
After merging the net tree, today's linux-next build (x86_64
allmodconfig) failed like this:
net/sctp/socket.c: In function 'sctp_data_ready':
net/sctp/socket.c:6191: error: implicit declaration of function 'sk_has_sleeper'
net/sctp/socket.c:6192: error: 'struct sock' has no member named 'sk_sleep'
Caused by commit 43815482370c510c569fd18edb57afcb0fa8cab6 ("net:
sock_def_readable() and friends RCU conversion") interacting with commit
561b1733a465cf9677356b40c27653dd45f1ac56 ("sctp: avoid irq lock inversion
while call sk->sk_data_ready()") which entered Linus' tree on April 29.
I have used the net tree from next-20100430 for today.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: linux-next: build failure after merge of the net tree
From: David Miller @ 2010-05-03 2:37 UTC (permalink / raw)
To: sfr; +Cc: netdev, linux-next, linux-kernel, eric.dumazet, yjwei
In-Reply-To: <20100503120847.e9328e75.sfr@canb.auug.org.au>
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 3 May 2010 12:08:47 +1000
> After merging the net tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> net/sctp/socket.c: In function 'sctp_data_ready':
> net/sctp/socket.c:6191: error: implicit declaration of function 'sk_has_sleeper'
> net/sctp/socket.c:6192: error: 'struct sock' has no member named 'sk_sleep'
>
> Caused by commit 43815482370c510c569fd18edb57afcb0fa8cab6 ("net:
> sock_def_readable() and friends RCU conversion") interacting with commit
> 561b1733a465cf9677356b40c27653dd45f1ac56 ("sctp: avoid irq lock inversion
> while call sk->sk_data_ready()") which entered Linus' tree on April 29.
>
> I have used the net tree from next-20100430 for today.
Thanks Stephen, I'll do a merge of net-2.6 into net-next-2.6 and fix
the build for you.
^ permalink raw reply
* Re: Receive issues with bonding and vlans
From: John Fastabend @ 2010-05-03 3:04 UTC (permalink / raw)
To: Jay Vosburgh
Cc: Leech, Christopher, netdev@vger.kernel.org, Andy Gospodarek,
Patrick McHardy, bonding-devel@lists.sourceforge.net
In-Reply-To: <2695.1271117318@death.nxdomain.ibm.com>
Jay Vosburgh wrote:
> Chris Leech <christopher.leech@intel.com> wrote:
>
>> On Mon, Apr 12, 2010 at 04:10:51PM -0700, Jay Vosburgh wrote:
>>> Is the FCoE supposed to run over the inactive bonding slave? Or
>>> am I misunderstanding what you're saying? I had thought the LLDP, et
>>> al, special case in bonding was to permit, essentially, path discovery,
>>> not necessarily active use of the inactive slave.
>> That's what I'm trying to do, yes. Mostly because it's a setup that
>> would work if you removed the FCoE traffic from the network data path,
>> and only converged at the driver level and below. It's possible that
>> the answer is "don't do that".
>
> So, basically, you want the bond to act like usual for "regular"
> ethernet traffic, but act like the slaves are independent from the bond
> for the magic FCoE traffic, right?
>
> I'm not really sure if that's a "don't do that" or not.
>
>>> Not that this is necessarily bad; the "drop stuff on inactive
>>> slaves" is really there for duplicate suppression, but it also can
>>> uncover network topology issues, e.g., network layouts that won't work
>>> if the devices fail, but appear to work during testing because the
>>> "inactive" slave still receives traffic (it hasn't really failed).
>>>
>>>> The problem is that it doesn't work for hardware accelerated VLAN
>>>> devices, because the VLAN receive paths have their own
>>>> skb_bond_should_drop calls that were not updated.
>>>>
>>> >From what I can tell, VLAN receives always end up going through
>>>> netif_receive_skb anyway, so skb_bond_should_drop gets called twice if
>>>> the frame isn't dropped the first time. I think the bonding checks in
>>>> __vlan_hwaccel_rx and vlan_gro_common should just be removed.
>>> I'm not so sure. The checks in __vlan_hwaccel_rx are done with
>>> the original receiving device in skb->dev; by the time the packet gets
>>> to netif_receive_skb, the original slave the packet was received on has
>>> been lost (and replaced with the VLAN device). Various things are
>>> interested in that, in particular the "arp_validate" and the "inactive
>>> slave drop" logic for bonding depend on knowing the real device the
>>> packet arrived on.
>>>
>>> I note that the vlan accel logic doesn't change skb_iif to the
>>> VLAN device; it remains as the original device. I suppose one
>>> alternative would be to convert the bonding drop, et al, logic to use
>>> skb_iif instead of skb->dev; if that works, then I think the VLAN core
>>> would not need to call skb_bond_should_drop, which in turn would be a
>>> bit more complicated as it would have to look up the dev from the
>>> skb_iif. There's already some code in bonding that takes advantage of
>>> this property of the VLANs, so maybe this is the way to go.
>> Thanks, I'll take another look and see if I can come up with something
>> better.
>
> I looked at the skb_bond_should_drop stuff a bit more after I
> wrote that; it's not as easy as I had suspected. The big sticking point
> is that currently the test in netif_receive_skb (now __netif_receive_skb
> in net-next-2.6) is on skb->dev->master to identify packets arriving on
> slaves of bonding. The VLAN skb->dev has ->master set to NULL. Doing
> that test against skb->skb_iif would be much more expensive, as it would
> require a device lookup for every packet.
>
> So, I suspect that something has to happen in the VLAN
> acceleration path, although I don't know exactly what. I don't know if
> it would be possible to flag the packets in some special way to indicate
> that they're "bonding slave" packets, or if it's better to keep the
> current structure and just fix the calls somehow.
>
> -J
>
>
Jay,
It should be OK to allow packets to be received on the VLAN if it is not
explicitly in the bond?
Or if we want to be more paranoid deliver packets only to handlers with
exact matches for the device. For non vlan devices we deliver skb's to
packet handlers that match exactly even on inactive slaves so doing this
on vlan devices as well makes sense and shouldn't cause any unexpected
problems.
Also on a somewhat unrelated note I suspect null_or_orig and
null_or_bond are not working as expected in __netif_receive_skb(). At
least the comment 'deliver only exact match' could be inaccurate.
Here's a patch to illustrate what I'm thinking compile tested only. If
this sounds reasonable I'll work up an official patch.
[PATCH] net: allow vlans on bonded real net_devices
For converged I/O it is reasonable to use dm_multipathing to provice
failover and load balancing for storage traffic and then use bonding
for the LAN failover and load balancing.
Currently this works if the multipathed devices are using the real
net_device and those devices are enslaved to a bonded device what
does not work is creating a vlan on the real device and trying to
use it outside the bond for multipathing.
This patch adds logic so that if the skb is destined for a vlan
that is not in the bond the skb will not be dropped.
Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
---
net/8021q/vlan_core.c | 31 +++++++++++++++++++++----------
net/core/dev.c | 11 ++++++++---
2 files changed, 29 insertions(+), 13 deletions(-)
diff --git a/net/8021q/vlan_core.c b/net/8021q/vlan_core.c
index c584a0a..3bce0c3 100644
--- a/net/8021q/vlan_core.c
+++ b/net/8021q/vlan_core.c
@@ -8,18 +8,24 @@
int __vlan_hwaccel_rx(struct sk_buff *skb, struct vlan_group *grp,
u16 vlan_tci, int polling)
{
+ struct net_device *vlan_dev;
+
if (netpoll_rx(skb))
return NET_RX_DROP;
- if (skb_bond_should_drop(skb, ACCESS_ONCE(skb->dev->master)))
+ vlan_dev = vlan_group_get_device(grp, vlan_tci & VLAN_VID_MASK);
+
+ if (!vlan_dev)
+ goto drop;
+
+ if ((vlan_dev->priv_flags & IFF_BONDING ||
+ vlan_dev_real_dev(vlan_dev)->flags & IFF_MASTER) &&
+ skb_bond_should_drop(skb, ACCESS_ONCE(skb->dev->master)))
goto drop;
skb->skb_iif = skb->dev->ifindex;
__vlan_hwaccel_put_tag(skb, vlan_tci);
- skb->dev = vlan_group_get_device(grp, vlan_tci & VLAN_VID_MASK);
-
- if (!skb->dev)
- goto drop;
+ skb->dev = vlan_dev;
return (polling ? netif_receive_skb(skb) : netif_rx(skb));
@@ -82,16 +88,21 @@ vlan_gro_common(struct napi_struct *napi, struct
vlan_group *grp,
unsigned int vlan_tci, struct sk_buff *skb)
{
struct sk_buff *p;
+ struct net_device *vlan_dev;
- if (skb_bond_should_drop(skb, ACCESS_ONCE(skb->dev->master)))
+ vlan_dev = vlan_group_get_device(grp, vlan_tci & VLAN_VID_MASK);
+
+ if (!vlan_dev)
+ goto drop;
+
+ if ((vlan_dev->priv_flags & IFF_BONDING ||
+ vlan_dev_real_dev(vlan_dev)->flags & IFF_MASTER) &&
+ skb_bond_should_drop(skb, ACCESS_ONCE(skb->dev->master)))
goto drop;
skb->skb_iif = skb->dev->ifindex;
__vlan_hwaccel_put_tag(skb, vlan_tci);
- skb->dev = vlan_group_get_device(grp, vlan_tci & VLAN_VID_MASK);
-
- if (!skb->dev)
- goto drop;
+ skb->dev = vlan_dev;
for (p = napi->gro_list; p; p = p->next) {
NAPI_GRO_CB(p)->same_flow =
diff --git a/net/core/dev.c b/net/core/dev.c
index 100dcbd..9ea4550 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2780,6 +2780,7 @@ static int __netif_receive_skb(struct sk_buff *skb)
struct net_device *master;
struct net_device *null_or_orig;
struct net_device *null_or_bond;
+ struct net_device *real_dev;
int ret = NET_RX_DROP;
__be16 type;
@@ -2853,9 +2854,13 @@ ncls:
* handler may have to adjust skb->dev and orig_dev.
*/
null_or_bond = NULL;
- if ((skb->dev->priv_flags & IFF_802_1Q_VLAN) &&
- (vlan_dev_real_dev(skb->dev)->priv_flags & IFF_BONDING)) {
- null_or_bond = vlan_dev_real_dev(skb->dev);
+ if ((skb->dev->priv_flags & IFF_802_1Q_VLAN)) {
+ real_dev = vlan_dev_real_dev(skb->dev);
+ if (real_dev->priv_flags & IFF_BONDING)
+ null_or_bond = vlan_dev_real_dev(skb->dev);
+ if (!(skb->dev->priv_flags & IFF_BONDING) &&
+ real_dev->priv_flags & IFF_SLAVE_INACTIVE)
+ null_or_orig = skb->dev;
}
type = skb->protocol;
^ permalink raw reply related
* Re: [PATCH v6] net: batch skb dequeueing from softnet input_pkt_queue
From: Arjan van de Ven @ 2010-05-03 3:50 UTC (permalink / raw)
To: Eric Dumazet
Cc: Andi Kleen, David Miller, hadi, xiaosuo, therbert, shemminger,
netdev, lenb
In-Reply-To: <1272828143.2173.150.camel@edumazet-laptop>
> > Also, I'm starting to wonder if Andi's patch to use io_schedule()
> > needs to be replaced with a net_schedule() kind of thing. The
> > cpuidle code currently has a weight factor for IO (based on
> > measuring/experiments), and maybe networking really needs another
> > factor... so just having a parallel concept with a different weight
> > could be the right answer for that.
> >
>
> But a task blocked on disk IO is probably blocked for a small amount
> of time, while on network, it can be for a long time. I am not sure
> its the right metric.
it's not so much about the duration, as it is about the performance
sensitivity....
> I was expecting something based on recent history.
> Say if we have 20.000 wakeups per second, most likely we should not
> enter C2/C3 states...
we effectively do that. The thing is that C2 is so low cost normally
that it's still worth it even at 20k wakeups...
this is where the bios tells us how "heavy" the states are....
and 64 usec... is just not very much.
--
Arjan van de Ven Intel Open Source Technology Centre
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
^ permalink raw reply
* Re: [net-next-2.6 PATCH 2/2] add ndo_set_port_profile op support for enic dynamic vnics
From: Vivek Kashyap @ 2010-05-03 4:29 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: Scott Feldman, davem, netdev, chrisw, Jens Osterkamp
In-Reply-To: <201004291748.38702.arnd@arndb.de>
>
>>>> ip port_profile set DEVICE [ base DEVICE ] [ { pre_associate |
>>>> pre_associate_rr } ]
>>>> { name PORT-PROFILE | vsi MGR:VTID:VER }
>>
>> BTW, I was meaning to ask: is there a way to role the vsi tuple and the
>> flags up into a single identifier, say a string like PORT-PROFILE? I'm
>> asking because it seems awkward from an admin's perspective to know how to
>> construct a vsi tuple or to know what pre_associate_rr means. I have to
>> admit I didn't fully grok what pre_associate_rr means myself. Even if there
>> was a simple local database to map named port-profiles to the underlying
>> {vsi tuple, flags}, that would bring us closer to a more consistent user
>> interface. Is this possible?
>
> I think that's technically possible but may not be helpful to make the
> user interface easier. Some background on pre-associate:
>
> The purpose of this is to assist guest migration. A single VSI (i.e. guest
> network adapter) may only be connected to a single switch port at any
> given time. The VSI is identified by its UUID and it has a unique
> MAC address.
>
> When migrating a guest to a new hypervisor, we need to ask the switch
> to associate that VSI at the destination switch port (which may or may
> not be on the same different switch as the source port). This operation
> may fail for a number of reasons and can take some time. Since we want
> migration to alway succeed and take as little time as possible, we
> do a pre-associate-with-resource-reservation before the migration and
> only start the actual guest migration if that completes successfully.
>
> After a successful pre-associate-with-resource-reservation step, we
> know that the actual associate step will be both fast and successful.
> After it completes, the VSI is known to be on the destination
> and all traffic goes there (replacing the gratuitous ARP method we do
> today).
>
> I don't think we'd ever do a pre-associate without the
> resource-reservation, but the standard defines both. In theory,
> we could do a pre-associate at every switch in the data center
> in order to find out if it's possible to migrate there.
>
> If you want to have more details, please look at the draft spec at
> http://www.ieee802.org/1/files/public/docs2010/bg-joint-evb-0410v1.pdf
The basic difference is that in 'pre-associate with resoruce reservation', the
local buffers and resources needed for the eventual 'associate' are reserved
at the switch port. Therefore the associate will not fail with
'insufficient resources'. It might otherwise.
thanks
Vivek
> --
> 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: linux-next: build failure after merge of the net tree
From: Stephen Rothwell @ 2010-05-03 4:44 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-next, linux-kernel, eric.dumazet, yjwei
In-Reply-To: <20100502.193756.106812290.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 329 bytes --]
Hi Dave,
On Sun, 02 May 2010 19:37:56 -0700 (PDT) David Miller <davem@davemloft.net> wrote:
>
> Thanks Stephen, I'll do a merge of net-2.6 into net-next-2.6 and fix
> the build for you.
Thanks, that will help.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH v6] net: batch skb dequeueing from softnet input_pkt_queue
From: Eric Dumazet @ 2010-05-03 5:17 UTC (permalink / raw)
To: Arjan van de Ven
Cc: Andi Kleen, David Miller, hadi, xiaosuo, therbert, shemminger,
netdev, lenb
In-Reply-To: <20100502205044.450beda2@infradead.org>
Le dimanche 02 mai 2010 à 20:50 -0700, Arjan van de Ven a écrit :
> we effectively do that. The thing is that C2 is so low cost normally
> that it's still worth it even at 20k wakeups...
>
> this is where the bios tells us how "heavy" the states are....
> and 64 usec... is just not very much.
Maybe its low cost, (apparently, it is, since I can reach ~900.000 ipis
on my 16 cores machine) but multiply this by 16 or 32 or 64 cpus, and
clockevents_notify() cost appears to be a killer, all cpus compete on a
single lock.
Maybe this notifier could use RCU ?
^ permalink raw reply
* Re: [PATCH v3] net: fix softnet_stat
From: David Miller @ 2010-05-03 5:29 UTC (permalink / raw)
To: eric.dumazet; +Cc: xiaosuo, netdev
In-Reply-To: <1272818607.2173.133.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sun, 02 May 2010 18:43:27 +0200
> Le dimanche 02 mai 2010 à 23:42 +0800, Changli Gao a écrit :
>> fix softnet_stat
>>
>> Per cpu variable softnet_data.total was shared between IRQ and SoftIRQ context
>> without any protection. And enqueue_to_backlog should update the netdev_rx_stat
>> of the target CPU.
>>
>> This patch renames softnet_data.total to softnet_data.processed: the number of
>> packets processed in uppper levels(IP stacks).
>>
>> softnet_stat data is moved into softnet_data.
>>
>> Signed-off-by: Changli Gao <xiaosuo@gmail.com>
>
> Thats a fine patch, thanks Changli.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied thanks.
I applied this follow-on patch to take the opportunity to clean up
something that has been bugging me for a long time, but never had the
energy to take care of :-)
net: Use explicit "unsigned int" instead of plain "unsigned" in netdevice.h
Signed-off-by: David S. Miller <davem@davemloft.net>
---
include/linux/netdevice.h | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index c39938f..98112fb 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -878,7 +878,7 @@ struct net_device {
unsigned char operstate; /* RFC2863 operstate */
unsigned char link_mode; /* mapping policy to operstate */
- unsigned mtu; /* interface MTU value */
+ unsigned int mtu; /* interface MTU value */
unsigned short type; /* interface hardware type */
unsigned short hard_header_len; /* hardware hdr length */
@@ -1381,10 +1381,10 @@ struct softnet_data {
struct sk_buff_head process_queue;
/* stats */
- unsigned processed;
- unsigned time_squeeze;
- unsigned cpu_collision;
- unsigned received_rps;
+ unsigned int processed;
+ unsigned int time_squeeze;
+ unsigned int cpu_collision;
+ unsigned int received_rps;
#ifdef CONFIG_RPS
struct softnet_data *rps_ipi_list;
--
1.7.0.4
^ permalink raw reply related
* Re: [patch 01/13] KS8851: Fix ks8851 snl transmit problem
From: David Miller @ 2010-05-03 5:38 UTC (permalink / raw)
To: ben; +Cc: netdev, tristram.ha, support
In-Reply-To: <20100429231739.509103394@fluff.org.uk>
From: Ben Dooks <ben@simtec.co.uk>
Date: Fri, 30 Apr 2010 00:16:22 +0100
> From: Tristram Ha <Tristram.Ha@micrel.com>
>
> This fixes a transmit problem of the ks8851 snl network driver.
>
> Under heavy TCP traffic the device will stop transmitting. Turning off
> the transmit interrupt avoids this issue. A new workqueue was
> implemented to replace the functionality of the transmit interrupt processing.
>
> Signed-off-by: Tristram Ha <Tristram.Ha@micrel.com>
Please, try to fix this properly. Unless you have a known chip errata
with the TX interrupt that cannot be worked around reasonably, which
would need to be detailed and explained completely in the commit log
message, you should try to figure out what the real problem is.
Otherwise just tossing everything to a workqueue looks like a hack, at
best.
I suspect you have some kind of race between IRQ processing and the
->ndo_start_xmit() handler, so you end up missing a queue wakeup.
Either that or you end up misprogramming the hardware due to the race.
There is no way I'm applying this as-is.
^ permalink raw reply
* Re: mmotm 2010-04-28 - RCU whinges
From: Eric Dumazet @ 2010-05-03 5:38 UTC (permalink / raw)
To: Valdis.Kletnieks
Cc: Andrew Morton, Peter Zijlstra, Patrick McHardy, David S. Miller,
linux-kernel, netfilter-devel, netdev, Paul E. McKenney
In-Reply-To: <5702.1272822394@localhost>
Le dimanche 02 mai 2010 à 13:46 -0400, Valdis.Kletnieks@vt.edu a écrit :
> On Wed, 28 Apr 2010 16:53:32 PDT, akpm@linux-foundation.org said:
> > The mm-of-the-moment snapshot 2010-04-28-16-53 has been uploaded to
> >
> > http://userweb.kernel.org/~akpm/mmotm/
>
> I thought we swatted all these, hit another one...
>
> [ 9.131490] ctnetlink v0.93: registering with nfnetlink.
> [ 9.131535]
> [ 9.131535] ===================================================
> [ 9.131704] [ INFO: suspicious rcu_dereference_check() usage. ]
> [ 9.131794] ---------------------------------------------------
> [ 9.131883] net/netfilter/nf_conntrack_ecache.c:88 invoked rcu_dereference_check() without protection!
> [ 9.131977]
> [ 9.131977] other info that might help us debug this:
> [ 9.131978]
> [ 9.132218]
> [ 9.132219] rcu_scheduler_active = 1, debug_locks = 0
> [ 9.132434] 1 lock held by swapper/1:
> [ 9.132519] #0: (nf_ct_ecache_mutex){+.+...}, at: [<ffffffff8148922d>] nf_conntrack_register_notifier+0x1a/0x75
> [ 9.132938]
> [ 9.132939] stack backtrace:
> [ 9.133129] Pid: 1, comm: swapper Tainted: G W 2.6.34-rc5-mmotm0428 #1
> [ 9.133220] Call Trace:
> [ 9.133319] [<ffffffff81064832>] lockdep_rcu_dereference+0xaa/0xb2
> [ 9.133410] [<ffffffff81489250>] nf_conntrack_register_notifier+0x3d/0x75
> [ 9.133521] [<ffffffff81b5a157>] ctnetlink_init+0x71/0xd5
> [ 9.133627] [<ffffffff81b5a0e6>] ? ctnetlink_init+0x0/0xd5
> [ 9.133735] [<ffffffff810001ef>] do_one_initcall+0x59/0x14e
> [ 9.133843] [<ffffffff81b2e68a>] kernel_init+0x144/0x1ce
> [ 9.133949] [<ffffffff81003414>] kernel_thread_helper+0x4/0x10
> [ 9.134060] [<ffffffff81598a40>] ? restore_args+0x0/0x30
> [ 9.134196] [<ffffffff81b2e546>] ? kernel_init+0x0/0x1ce
> [ 9.134328] [<ffffffff81003410>] ? kernel_thread_helper+0x0/0x10
> [ 9.134530] ip_tables: (C) 2000-2006 Netfilter Core Team
> [ 9.134655] TCP bic registered
>
Thanks for the report !
We can use rcu_dereference_protected() in those cases.
[PATCH] net: Use rcu_dereference_protected in nf_conntrack_ecache
Writers own nf_ct_ecache_mutex.
Reported-by: Valdis Kletnieks <Valdis.Kletnieks@vt.edu>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
net/netfilter/nf_conntrack_ecache.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/net/netfilter/nf_conntrack_ecache.c b/net/netfilter/nf_conntrack_ecache.c
index f516961..cdcc764 100644
--- a/net/netfilter/nf_conntrack_ecache.c
+++ b/net/netfilter/nf_conntrack_ecache.c
@@ -85,7 +85,8 @@ int nf_conntrack_register_notifier(struct nf_ct_event_notifier *new)
struct nf_ct_event_notifier *notify;
mutex_lock(&nf_ct_ecache_mutex);
- notify = rcu_dereference(nf_conntrack_event_cb);
+ notify = rcu_dereference_protected(nf_conntrack_event_cb,
+ lockdep_is_held(&nf_ct_ecache_mutex));
if (notify != NULL) {
ret = -EBUSY;
goto out_unlock;
@@ -105,7 +106,8 @@ void nf_conntrack_unregister_notifier(struct nf_ct_event_notifier *new)
struct nf_ct_event_notifier *notify;
mutex_lock(&nf_ct_ecache_mutex);
- notify = rcu_dereference(nf_conntrack_event_cb);
+ notify = rcu_dereference_protected(nf_conntrack_event_cb,
+ lockdep_is_held(&nf_ct_ecache_mutex));
BUG_ON(notify != new);
rcu_assign_pointer(nf_conntrack_event_cb, NULL);
mutex_unlock(&nf_ct_ecache_mutex);
@@ -118,7 +120,8 @@ int nf_ct_expect_register_notifier(struct nf_exp_event_notifier *new)
struct nf_exp_event_notifier *notify;
mutex_lock(&nf_ct_ecache_mutex);
- notify = rcu_dereference(nf_expect_event_cb);
+ notify = rcu_dereference_protected(nf_expect_event_cb,
+ lockdep_is_held(&nf_ct_ecache_mutex));
if (notify != NULL) {
ret = -EBUSY;
goto out_unlock;
@@ -138,7 +141,8 @@ void nf_ct_expect_unregister_notifier(struct nf_exp_event_notifier *new)
struct nf_exp_event_notifier *notify;
mutex_lock(&nf_ct_ecache_mutex);
- notify = rcu_dereference(nf_expect_event_cb);
+ notify = rcu_dereference_protected(nf_expect_event_cb,
+ lockdep_is_held(&nf_ct_ecache_mutex));
BUG_ON(notify != new);
rcu_assign_pointer(nf_expect_event_cb, NULL);
mutex_unlock(&nf_ct_ecache_mutex);
^ permalink raw reply related
* Re: mmotm 2010-04-28 - RCU whinges
From: Eric Dumazet @ 2010-05-03 5:41 UTC (permalink / raw)
To: Valdis.Kletnieks
Cc: Andrew Morton, Peter Zijlstra, Patrick McHardy, David S. Miller,
linux-kernel, netfilter-devel, netdev, Paul E. McKenney
In-Reply-To: <1272865137.2173.179.camel@edumazet-laptop>
Le lundi 03 mai 2010 à 07:38 +0200, Eric Dumazet a écrit :
> Le dimanche 02 mai 2010 à 13:46 -0400, Valdis.Kletnieks@vt.edu a écrit :
> > On Wed, 28 Apr 2010 16:53:32 PDT, akpm@linux-foundation.org said:
> > > The mm-of-the-moment snapshot 2010-04-28-16-53 has been uploaded to
> > >
> > > http://userweb.kernel.org/~akpm/mmotm/
> >
> > I thought we swatted all these, hit another one...
> >
> > [ 9.131490] ctnetlink v0.93: registering with nfnetlink.
> > [ 9.131535]
> > [ 9.131535] ===================================================
> > [ 9.131704] [ INFO: suspicious rcu_dereference_check() usage. ]
> > [ 9.131794] ---------------------------------------------------
> > [ 9.131883] net/netfilter/nf_conntrack_ecache.c:88 invoked rcu_dereference_check() without protection!
> > [ 9.131977]
> > [ 9.131977] other info that might help us debug this:
> > [ 9.131978]
> > [ 9.132218]
> > [ 9.132219] rcu_scheduler_active = 1, debug_locks = 0
> > [ 9.132434] 1 lock held by swapper/1:
> > [ 9.132519] #0: (nf_ct_ecache_mutex){+.+...}, at: [<ffffffff8148922d>] nf_conntrack_register_notifier+0x1a/0x75
> > [ 9.132938]
> > [ 9.132939] stack backtrace:
> > [ 9.133129] Pid: 1, comm: swapper Tainted: G W 2.6.34-rc5-mmotm0428 #1
> > [ 9.133220] Call Trace:
> > [ 9.133319] [<ffffffff81064832>] lockdep_rcu_dereference+0xaa/0xb2
> > [ 9.133410] [<ffffffff81489250>] nf_conntrack_register_notifier+0x3d/0x75
> > [ 9.133521] [<ffffffff81b5a157>] ctnetlink_init+0x71/0xd5
> > [ 9.133627] [<ffffffff81b5a0e6>] ? ctnetlink_init+0x0/0xd5
> > [ 9.133735] [<ffffffff810001ef>] do_one_initcall+0x59/0x14e
> > [ 9.133843] [<ffffffff81b2e68a>] kernel_init+0x144/0x1ce
> > [ 9.133949] [<ffffffff81003414>] kernel_thread_helper+0x4/0x10
> > [ 9.134060] [<ffffffff81598a40>] ? restore_args+0x0/0x30
> > [ 9.134196] [<ffffffff81b2e546>] ? kernel_init+0x0/0x1ce
> > [ 9.134328] [<ffffffff81003410>] ? kernel_thread_helper+0x0/0x10
> > [ 9.134530] ip_tables: (C) 2000-2006 Netfilter Core Team
> > [ 9.134655] TCP bic registered
> >
>
> Thanks for the report !
>
> We can use rcu_dereference_protected() in those cases.
>
> [PATCH] net: Use rcu_dereference_protected in nf_conntrack_ecache
>
> Writers own nf_ct_ecache_mutex.
>
> Reported-by: Valdis Kletnieks <Valdis.Kletnieks@vt.edu>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> ---
Oops scratch that, I'll resend a correct version.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" 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: mmotm 2010-04-28 - RCU whinges
From: Eric Dumazet @ 2010-05-03 5:43 UTC (permalink / raw)
To: Valdis.Kletnieks
Cc: Andrew Morton, Peter Zijlstra, Patrick McHardy, David S. Miller,
linux-kernel, netfilter-devel, netdev, Paul E. McKenney
In-Reply-To: <1272865267.2173.180.camel@edumazet-laptop>
Le lundi 03 mai 2010 à 07:41 +0200, Eric Dumazet a écrit :
> Oops scratch that, I'll resend a correct version.
>
>
Sorry, patch _is_ fine, I had one brain collapse when re-reading it, I
thought a different mutex was in use in one of the functions.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" 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: mmotm 2010-04-28 - RCU whinges
From: David Miller @ 2010-05-03 5:55 UTC (permalink / raw)
To: eric.dumazet
Cc: Valdis.Kletnieks, akpm, peterz, kaber, linux-kernel,
netfilter-devel, netdev, paulmck
In-Reply-To: <1272865436.2173.182.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 03 May 2010 07:43:56 +0200
> Le lundi 03 mai 2010 à 07:41 +0200, Eric Dumazet a écrit :
>
>> Oops scratch that, I'll resend a correct version.
>>
>>
>
> Sorry, patch _is_ fine, I had one brain collapse when re-reading it, I
> thought a different mutex was in use in one of the functions.
Ok, Patrick please review, thanks.
^ permalink raw reply
* Re: [PATCH 1/2] ppp_generic: pull 2 bytes so that PPP_PROTO(skb) is valid
From: David Miller @ 2010-05-03 6:25 UTC (permalink / raw)
To: simon; +Cc: netdev, paulus, linux-ppp
In-Reply-To: <4BDB244D.40800@simon.arlott.org.uk>
From: Simon Arlott <simon@fire.lp0.eu>
Date: Fri, 30 Apr 2010 19:41:17 +0100
> @@ -1572,8 +1572,18 @@ ppp_input(struct ppp_channel *chan, struct sk_buff *skb)
> return;
> }
>
> - proto = PPP_PROTO(skb);
> +
> read_lock_bh(&pch->upl);
> + if (!pskb_may_pull(skb, 2)) {
> + kfree_skb(skb);
> + if (pch->ppp) {
> + ++pch->ppp->dev->stats.rx_length_errors;
> + ppp_receive_error(pch->ppp);
> + }
> + goto done;
> + }
> +
> + proto = PPP_PROTO(skb);
This makes the skb->len == 0 test at the beginning completely redundant.
Put your pskb_may_pull(skb, 2) call there and remove the skb->len==0
check entirely.
^ permalink raw reply
* Re: [PATCH 3/3] ptp: Added a clock that uses the eTSEC found on the MPC85xx.
From: Richard Cochran @ 2010-05-03 6:26 UTC (permalink / raw)
To: Kumar Gala; +Cc: Netdev, linuxppc-dev, devicetree-discuss
In-Reply-To: <FFD6BE31-AF2B-4D44-9751-61DB06327DBD@kernel.crashing.org>
On Sat, May 01, 2010 at 11:36:12AM -0500, Kumar Gala wrote:
> Is there a binding document that describes this node you are adding?
No, but I will add one to Documentation/powerpc/dts-bindings.
Thanks,
Richard
^ 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