* Re: [net-next 2/5] stmmac: allow mtu bigger than 1500 in case of normal desc (V2).
From: Giuseppe CAVALLARO @ 2011-10-14 7:15 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, davem, Deepak SIKRI
In-Reply-To: <1318449481.2644.11.camel@edumazet-laptop>
Hello Eric
On 10/12/2011 9:58 PM, Eric Dumazet wrote:
> Le mercredi 12 octobre 2011 à 15:38 +0200, Giuseppe CAVALLARO a écrit :
>> This patch allows to set the mtu bigger than 1500
>> in case of normal descriptors.
>> This is helping some SPEAr customers.
>>
>> Signed-off-by: Deepak SIKRI <deepak.sikri@st.com>
>> Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
>> ---
>> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 6 +++---
>> 1 files changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>> index ba7af2c..de3e536 100644
>> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>> @@ -1357,17 +1357,17 @@ static void stmmac_set_rx_mode(struct net_device *dev)
>> static int stmmac_change_mtu(struct net_device *dev, int new_mtu)
>> {
>> struct stmmac_priv *priv = netdev_priv(dev);
>> - int max_mtu;
>> + int max_mtu = ETH_DATA_LEN;
>
> Why are you setting max_mtu to ETH_DATA_LEN here ?
>
>>
>> if (netif_running(dev)) {
>> pr_err("%s: must be stopped to change its MTU\n", dev->name);
>> return -EBUSY;
>> }
>>
>> - if (priv->plat->has_gmac)
>> + if (priv->plat->enh_desc)
>> max_mtu = JUMBO_LEN;
>> else
>> - max_mtu = ETH_DATA_LEN;
>> + max_mtu = BUF_SIZE_4KiB;
>
> Since later you init to completely different values...
Hmm, yes you are right. it's not needed to initialized the max_mtu.
Thanks! I'll rework the patch and send it again in the V3.
Thx
Regards
Peppe
>
>
>
>
^ permalink raw reply
* Re: Route flagged RTCF_REDIRECTED without ICMP redirs?
From: Sven Ulland @ 2011-10-14 7:15 UTC (permalink / raw)
To: netdev
In-Reply-To: <20111013185015.fa2abpjlpw8c0408@staff.opera.com>
On 10/13/2011 08:50 PM, sveniu@opera.com wrote:
> How can a route end up with being flagged with RTCF_REDIRECTED, and
> point to the default gateway, even though it's explicitly set to
> route to another node in the same subnet, in the rpdb and routing
> tables? There is zero trace of icmp redirects, and all redirect
> sysctls have been disabled, and the route cache flushed before every
> test.
This turned out to be due to [1], where the inet peer cache kept
a redirect learned via icmp before accept_redirect and friends were
disabled, so it was propagated to the route cache. Resolved by
a reboot to clean the inet peer cache.
[1]: Commit f39925d:
<URL:https://github.com/torvalds/linux/commit/f39925dbde7788cfb96419c0f092b086aa325c0f>
best regards,
Sven Ulland
^ permalink raw reply
* [PATCH net-next] tcp: reduce memory needs of out of order queue
From: Eric Dumazet @ 2011-10-14 7:19 UTC (permalink / raw)
To: David Miller; +Cc: netdev
Many drivers allocates big skb to store a single TCP frame.
(WIFI drivers, or NIC using PAGE_SIZE fragments)
Its now common to get skb->truesize bigger than 4096 to store a ~1500
bytes TCP frame.
TCP sessions with large RTT and packet losses can fill their Out Of
Order queue with such oversized skbs, and hit their sk_rcvbuf limit,
starting a pruning of complete OFO queue, without giving chance to
receive the missing packet(s) and moving skbs from OFO to receive queue.
This patch adds skb_reduce_truesize() helper, and uses it for all skbs
queued into OFO queue.
Spending some time to perform a copy is worth the pain, since it permits
SACK processing to have a chance to complete over the RTT barrier.
This greatly improves user experience, without added cost on fast path.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
net/ipv4/tcp_input.c | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index c1653fe..1d10edb 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -4426,6 +4426,25 @@ static inline int tcp_try_rmem_schedule(struct sock *sk, unsigned int size)
return 0;
}
+/*
+ * Caller want to reduce memory needs before queueing skb
+ * The (expensive) copy should not be be done in fast path.
+ */
+static struct sk_buff *skb_reduce_truesize(struct sk_buff *skb)
+{
+ if (skb->truesize > 2 * SKB_TRUESIZE(skb->len)) {
+ struct sk_buff *nskb;
+
+ nskb = skb_copy_expand(skb, skb_headroom(skb), 0,
+ GFP_ATOMIC | __GFP_NOWARN);
+ if (nskb) {
+ __kfree_skb(skb);
+ skb = nskb;
+ }
+ }
+ return skb;
+}
+
static void tcp_data_queue(struct sock *sk, struct sk_buff *skb)
{
struct tcphdr *th = tcp_hdr(skb);
@@ -4553,6 +4572,11 @@ drop:
SOCK_DEBUG(sk, "out of order segment: rcv_next %X seq %X - %X\n",
tp->rcv_nxt, TCP_SKB_CB(skb)->seq, TCP_SKB_CB(skb)->end_seq);
+ /* Since this skb might stay on ofo a long time, try to reduce
+ * its truesize (if its too big) to avoid future pruning.
+ * Many drivers allocate large buffers even to hold tiny frames.
+ */
+ skb = skb_reduce_truesize(skb);
skb_set_owner_r(skb, sk);
if (!skb_peek(&tp->out_of_order_queue)) {
^ permalink raw reply related
* [PATCH net-next] skbuff: update sk truesize in pskb_expand_head
From: roy.qing.li @ 2011-10-14 7:39 UTC (permalink / raw)
To: netdev
when pskb_expand_head reallocates header of &sk_buff, the sk
truesize should be updated simultaneously
Signed-off-by: RongQing.Li <roy.qing.li@gmail.com>
---
net/core/skbuff.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 387703f..48e0be9 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -920,6 +920,7 @@ int pskb_expand_head(struct sk_buff *skb, int nhead, int ntail,
}
off = (data + nhead) - skb->head;
+ skb->truesize += (size - (skb_end_pointer(skb) - skb->head));
skb->head = data;
adjust_others:
skb->data += off;
--
1.7.1
^ permalink raw reply related
* Re: [PATCH net-next] tcp: reduce memory needs of out of order queue
From: David Miller @ 2011-10-14 7:42 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1318576791.2533.99.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 14 Oct 2011 09:19:51 +0200
> Many drivers allocates big skb to store a single TCP frame.
> (WIFI drivers, or NIC using PAGE_SIZE fragments)
>
> Its now common to get skb->truesize bigger than 4096 to store a ~1500
> bytes TCP frame.
>
> TCP sessions with large RTT and packet losses can fill their Out Of
> Order queue with such oversized skbs, and hit their sk_rcvbuf limit,
> starting a pruning of complete OFO queue, without giving chance to
> receive the missing packet(s) and moving skbs from OFO to receive queue.
>
> This patch adds skb_reduce_truesize() helper, and uses it for all skbs
> queued into OFO queue.
>
> Spending some time to perform a copy is worth the pain, since it permits
> SACK processing to have a chance to complete over the RTT barrier.
>
> This greatly improves user experience, without added cost on fast path.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
No objection from me, although I wish wireless drivers were able to
size their SKBs more appropriately. I wonder how many problems that
look like "OMG we gotz da Buffer Bloat, arrr!" are actually due to
this truesize issue.
I think such large truesize SKBs will cause problems even in non loss
situations, in that the receive buffer will hit it's limits more
quickly. I not sure that the receive buffer autotuning is built to
handle this sort of scenerio as a common occurance.
You might want to check if this is the actual root cause of your
problems. If the receive buffer autotuning doesn't expand the receive
buffer enough to hold two windows worth of these large truesize SKBs,
that's the real reason why we end up pruning.
We have to decide if these kinds of SKBs are acceptable as a normal
situation for MSS sized frames. And if they are then it's probably
a good idea to adjust the receive buffer autotuning code too.
Although I realize it might be difficult, getting rid of these weird
SKBs in the first place would be ideal.
It would also be a good idea to put the truesize inaccuracies into
perspective when selecting how to fix this. It's trying to prevent
1 byte packets not accounting for the 256 byte SKB and metadata.
That kind of case with such a high ratio of wastage is important.
On the other hand, using 2048 bytes for a 1500 byte packet and claiming
the truesize is 1500 + sizeof(metadata)... that might be an acceptable
lie to tell :-) This is especially true if it allows an easy solution
to this wireless problem.
Just some thoughts... and I wonder if the wireless thing is due to
some hardware limitation or similar.
^ permalink raw reply
* Re: [PATCH net-next] skbuff: update sk truesize in pskb_expand_head
From: David Miller @ 2011-10-14 7:48 UTC (permalink / raw)
To: roy.qing.li; +Cc: netdev
In-Reply-To: <1318577970-19566-1-git-send-email-roy.qing.li@gmail.com>
From: roy.qing.li@gmail.com
Date: Fri, 14 Oct 2011 15:39:30 +0800
> when pskb_expand_head reallocates header of &sk_buff, the sk
> truesize should be updated simultaneously
>
> Signed-off-by: RongQing.Li <roy.qing.li@gmail.com>
I know you did not test this patch at all.
You can't modify the truesize because packets passed to this routine
are often attached to a socket, thus if you change the truesize the
socket memory accouting will be adjusted incorrectly later when the
SKB is freed up.
Most SKB modifying functions have to operate with this restriction.
^ permalink raw reply
* Re: [PATCH net-next] skbuff: update sk truesize in pskb_expand_head
From: Eric Dumazet @ 2011-10-14 7:53 UTC (permalink / raw)
To: roy.qing.li; +Cc: netdev
In-Reply-To: <1318577970-19566-1-git-send-email-roy.qing.li@gmail.com>
Le vendredi 14 octobre 2011 à 15:39 +0800, roy.qing.li@gmail.com a
écrit :
> when pskb_expand_head reallocates header of &sk_buff, the sk
> truesize should be updated simultaneously
>
> Signed-off-by: RongQing.Li <roy.qing.li@gmail.com>
> ---
> net/core/skbuff.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/net/core/skbuff.c b/net/core/skbuff.c
> index 387703f..48e0be9 100644
> --- a/net/core/skbuff.c
> +++ b/net/core/skbuff.c
> @@ -920,6 +920,7 @@ int pskb_expand_head(struct sk_buff *skb, int nhead, int ntail,
> }
> off = (data + nhead) - skb->head;
>
> + skb->truesize += (size - (skb_end_pointer(skb) - skb->head));
> skb->head = data;
> adjust_others:
> skb->data += off;
I dont believe this is needed or complete patch.
Callers that need an updated truesize do the adjustement.
^ permalink raw reply
* Re: [PATCH net-next] tcp: reduce memory needs of out of order queue
From: Eric Dumazet @ 2011-10-14 8:05 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20111014.034224.1197576516015404466.davem@davemloft.net>
Le vendredi 14 octobre 2011 à 03:42 -0400, David Miller a écrit :
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Fri, 14 Oct 2011 09:19:51 +0200
>
> > Many drivers allocates big skb to store a single TCP frame.
> > (WIFI drivers, or NIC using PAGE_SIZE fragments)
> >
> > Its now common to get skb->truesize bigger than 4096 to store a ~1500
> > bytes TCP frame.
> >
> > TCP sessions with large RTT and packet losses can fill their Out Of
> > Order queue with such oversized skbs, and hit their sk_rcvbuf limit,
> > starting a pruning of complete OFO queue, without giving chance to
> > receive the missing packet(s) and moving skbs from OFO to receive queue.
> >
> > This patch adds skb_reduce_truesize() helper, and uses it for all skbs
> > queued into OFO queue.
> >
> > Spending some time to perform a copy is worth the pain, since it permits
> > SACK processing to have a chance to complete over the RTT barrier.
> >
> > This greatly improves user experience, without added cost on fast path.
> >
> > Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
>
> No objection from me, although I wish wireless drivers were able to
> size their SKBs more appropriately. I wonder how many problems that
> look like "OMG we gotz da Buffer Bloat, arrr!" are actually due to
> this truesize issue.
>
> I think such large truesize SKBs will cause problems even in non loss
> situations, in that the receive buffer will hit it's limits more
> quickly. I not sure that the receive buffer autotuning is built to
> handle this sort of scenerio as a common occurance.
>
> You might want to check if this is the actual root cause of your
> problems. If the receive buffer autotuning doesn't expand the receive
> buffer enough to hold two windows worth of these large truesize SKBs,
> that's the real reason why we end up pruning.
>
> We have to decide if these kinds of SKBs are acceptable as a normal
> situation for MSS sized frames. And if they are then it's probably
> a good idea to adjust the receive buffer autotuning code too.
>
> Although I realize it might be difficult, getting rid of these weird
> SKBs in the first place would be ideal.
>
> It would also be a good idea to put the truesize inaccuracies into
> perspective when selecting how to fix this. It's trying to prevent
> 1 byte packets not accounting for the 256 byte SKB and metadata.
> That kind of case with such a high ratio of wastage is important.
>
> On the other hand, using 2048 bytes for a 1500 byte packet and claiming
> the truesize is 1500 + sizeof(metadata)... that might be an acceptable
> lie to tell :-) This is especially true if it allows an easy solution
> to this wireless problem.
>
> Just some thoughts... and I wonder if the wireless thing is due to
> some hardware limitation or similar.
>
This patch specifically addresses the OFO problem, trying to lower
memory usage for machines handling lot of sockets (proxies for example)
For the general case, I believe we have to tune/change
tcp_win_from_space() to take into account general tendancy to get fat
skbs.
sysctl_tcp_adv_win_scale is not fine enough today, and default value (2)
gives too much collapses. It's also a very complex setting, I am pretty
sure nobody knows how to use it.
tcp_win_from_space(int space) -> 75% of space [ default ]
Only current kernels choices are to set it to one/-1 :
tcp_win_from_space(int space) -> 50% of space
or -2 :
tcp_win_from_space(int space) -> 25% of space
^ permalink raw reply
* [PATCH] net: Move rcu_barrier from rollback_registered_many to netdev_run_todo.
From: Eric W. Biederman @ 2011-10-14 8:25 UTC (permalink / raw)
To: David Miller; +Cc: Eric Dumazet, netdev
This patch moves the rcu_barrier from rollback_registered_many
(inside the rtnl_lock) into netdev_run_todo (just outside the rtnl_lock).
This allows us to gain the full benefit of sychronize_net calling
synchronize_rcu_expedited when the rtnl_lock is held.
The rcu_barrier in rollback_registered_many was originally a synchronize_net
but was promoted to be a rcu_barrier() when it was found that people were
unnecessarily hitting the 250ms wait in netdev_wait_allrefs(). Changing
the rcu_barrier back to a synchronize_net is therefore safe.
Since we only care about waiting for the rcu callbacks before we get
to netdev_wait_allrefs() it is also safe to move the wait into
netdev_run_todo.
This was tested by creating and destroying 1000 tap devices and observing
/proc/lock_stat. /proc/lock_stat reports this change reduces the hold
times of the rtnl_lock by a factor of 10. There was no observable
difference in the amount of time it takes to destroy a network device.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
---
net/core/dev.c | 8 +++++++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index 70ecb86..44dcacf 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -5235,7 +5235,7 @@ static void rollback_registered_many(struct list_head *head)
dev = list_first_entry(head, struct net_device, unreg_list);
call_netdevice_notifiers(NETDEV_UNREGISTER_BATCH, dev);
- rcu_barrier();
+ synchronize_net();
list_for_each_entry(dev, head, unreg_list)
dev_put(dev);
@@ -5748,6 +5748,12 @@ void netdev_run_todo(void)
__rtnl_unlock();
+ /* Wait for rcu callbacks to finish before attempting to drain
+ * the device list. This usually avoids a 250ms wait.
+ */
+ if (!list_empty(&list))
+ rcu_barrier();
+
while (!list_empty(&list)) {
struct net_device *dev
= list_first_entry(&list, struct net_device, todo_list);
--
1.7.2.5
^ permalink raw reply related
* [PATCH 0/4] can: the mailinglist moved to vger.kernel.org
From: Marc Kleine-Budde @ 2011-10-14 8:43 UTC (permalink / raw)
To: netdev; +Cc: linux-can
Hello,
the BerliOS project will close with the end of the year, so we moved our
mailinglist to vger.kernel.org, it's now linux-can@vger.kernel.org.
This patch series changes every mail address accordingly.
regards, Marc
^ permalink raw reply
* [PATCH 3/4] net/can: the mailinglist moved to vger.kernel.org
From: Marc Kleine-Budde @ 2011-10-14 8:43 UTC (permalink / raw)
To: netdev; +Cc: linux-can, Marc Kleine-Budde
In-Reply-To: <1318581817-12352-1-git-send-email-mkl@pengutronix.de>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
net/can/af_can.c | 2 +-
net/can/af_can.h | 2 +-
net/can/bcm.c | 2 +-
net/can/gw.c | 2 +-
net/can/proc.c | 2 +-
net/can/raw.c | 2 +-
6 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/net/can/af_can.c b/net/can/af_can.c
index d1ff515..4f299b1 100644
--- a/net/can/af_can.c
+++ b/net/can/af_can.c
@@ -38,7 +38,7 @@
* OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
* DAMAGE.
*
- * Send feedback to <socketcan-users@lists.berlios.de>
+ * Send feedback to <linux-can@vger.kernel.org>
*
*/
diff --git a/net/can/af_can.h b/net/can/af_can.h
index 34253b8..bcfbc42 100644
--- a/net/can/af_can.h
+++ b/net/can/af_can.h
@@ -35,7 +35,7 @@
* OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
* DAMAGE.
*
- * Send feedback to <socketcan-users@lists.berlios.de>
+ * Send feedback to <linux-can@vger.kernel.org>
*
*/
diff --git a/net/can/bcm.c b/net/can/bcm.c
index c84963d..5103cea 100644
--- a/net/can/bcm.c
+++ b/net/can/bcm.c
@@ -37,7 +37,7 @@
* OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
* DAMAGE.
*
- * Send feedback to <socketcan-users@lists.berlios.de>
+ * Send feedback to <linux-can@vger.kernel.org>
*
*/
diff --git a/net/can/gw.c b/net/can/gw.c
index ac11407..9a21120 100644
--- a/net/can/gw.c
+++ b/net/can/gw.c
@@ -37,7 +37,7 @@
* OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
* DAMAGE.
*
- * Send feedback to <socketcan-users@lists.berlios.de>
+ * Send feedback to <linux-can@vger.kernel.org>
*
*/
diff --git a/net/can/proc.c b/net/can/proc.c
index 0016f73..a5ee7d6 100644
--- a/net/can/proc.c
+++ b/net/can/proc.c
@@ -37,7 +37,7 @@
* OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
* DAMAGE.
*
- * Send feedback to <socketcan-users@lists.berlios.de>
+ * Send feedback to <linux-can@vger.kernel.org>
*
*/
diff --git a/net/can/raw.c b/net/can/raw.c
index dea99a6..45bab31 100644
--- a/net/can/raw.c
+++ b/net/can/raw.c
@@ -37,7 +37,7 @@
* OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
* DAMAGE.
*
- * Send feedback to <socketcan-users@lists.berlios.de>
+ * Send feedback to <linux-can@vger.kernel.org>
*
*/
--
1.7.4.1
^ permalink raw reply related
* [PATCH 1/4] MAINTAINERS: can: the mailinglist moved to vger.kernel.org
From: Marc Kleine-Budde @ 2011-10-14 8:43 UTC (permalink / raw)
To: netdev; +Cc: linux-can, Marc Kleine-Budde
In-Reply-To: <1318581817-12352-1-git-send-email-mkl@pengutronix.de>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Acked-by: Oliver Hartkopp <socketcan@hartkopp.net>
---
MAINTAINERS | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index aac56f9..5008b08 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1671,7 +1671,7 @@ CAN NETWORK LAYER
M: Oliver Hartkopp <socketcan@hartkopp.net>
M: Oliver Hartkopp <oliver.hartkopp@volkswagen.de>
M: Urs Thuermann <urs.thuermann@volkswagen.de>
-L: socketcan-core@lists.berlios.de (subscribers-only)
+L: linux-can@vger.kernel.org
L: netdev@vger.kernel.org
W: http://developer.berlios.de/projects/socketcan/
S: Maintained
@@ -1683,7 +1683,7 @@ F: include/linux/can/raw.h
CAN NETWORK DRIVERS
M: Wolfgang Grandegger <wg@grandegger.com>
-L: socketcan-core@lists.berlios.de (subscribers-only)
+L: linux-can@vger.kernel.org
L: netdev@vger.kernel.org
W: http://developer.berlios.de/projects/socketcan/
S: Maintained
--
1.7.4.1
^ permalink raw reply related
* [PATCH 4/4] include/linux/can: the mailinglist moved to vger.kernel.org
From: Marc Kleine-Budde @ 2011-10-14 8:43 UTC (permalink / raw)
To: netdev; +Cc: linux-can, Marc Kleine-Budde
In-Reply-To: <1318581817-12352-1-git-send-email-mkl@pengutronix.de>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
include/linux/can.h | 2 +-
include/linux/can/bcm.h | 2 +-
include/linux/can/core.h | 2 +-
include/linux/can/dev.h | 2 +-
include/linux/can/error.h | 2 +-
include/linux/can/gw.h | 2 +-
include/linux/can/netlink.h | 2 +-
include/linux/can/raw.h | 2 +-
8 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/include/linux/can.h b/include/linux/can.h
index bb047dc..d0d7028 100644
--- a/include/linux/can.h
+++ b/include/linux/can.h
@@ -8,7 +8,7 @@
* Copyright (c) 2002-2007 Volkswagen Group Electronic Research
* All rights reserved.
*
- * Send feedback to <socketcan-users@lists.berlios.de>
+ * Send feedback to <linux-can@vger.kernel.org>
*
*/
diff --git a/include/linux/can/bcm.h b/include/linux/can/bcm.h
index e96154d..cc2f800 100644
--- a/include/linux/can/bcm.h
+++ b/include/linux/can/bcm.h
@@ -7,7 +7,7 @@
* Copyright (c) 2002-2007 Volkswagen Group Electronic Research
* All rights reserved.
*
- * Send feedback to <socketcan-users@lists.berlios.de>
+ * Send feedback to <linux-can@vger.kernel.org>
*
*/
diff --git a/include/linux/can/core.h b/include/linux/can/core.h
index 5ce6b5d..12b2878 100644
--- a/include/linux/can/core.h
+++ b/include/linux/can/core.h
@@ -8,7 +8,7 @@
* Copyright (c) 2002-2007 Volkswagen Group Electronic Research
* All rights reserved.
*
- * Send feedback to <socketcan-users@lists.berlios.de>
+ * Send feedback to <linux-can@vger.kernel.org>
*
*/
diff --git a/include/linux/can/dev.h b/include/linux/can/dev.h
index cc0bb49..bf5fa49 100644
--- a/include/linux/can/dev.h
+++ b/include/linux/can/dev.h
@@ -8,7 +8,7 @@
*
* Copyright (C) 2008 Wolfgang Grandegger <wg@grandegger.com>
*
- * Send feedback to <socketcan-users@lists.berlios.de>
+ * Send feedback to <linux-can@vger.kernel.org>
*/
#ifndef CAN_DEV_H
diff --git a/include/linux/can/error.h b/include/linux/can/error.h
index 5958074..9aa0dfb 100644
--- a/include/linux/can/error.h
+++ b/include/linux/can/error.h
@@ -7,7 +7,7 @@
* Copyright (c) 2002-2007 Volkswagen Group Electronic Research
* All rights reserved.
*
- * Send feedback to <socketcan-users@lists.berlios.de>
+ * Send feedback to <linux-can@vger.kernel.org>
*
*/
diff --git a/include/linux/can/gw.h b/include/linux/can/gw.h
index 5527b54..37cd710 100644
--- a/include/linux/can/gw.h
+++ b/include/linux/can/gw.h
@@ -7,7 +7,7 @@
* Copyright (c) 2011 Volkswagen Group Electronic Research
* All rights reserved.
*
- * Send feedback to <socketcan-users@lists.berlios.de>
+ * Send feedback to <linux-can@vger.kernel.org>
*
*/
diff --git a/include/linux/can/netlink.h b/include/linux/can/netlink.h
index 34542d3..e497cd8 100644
--- a/include/linux/can/netlink.h
+++ b/include/linux/can/netlink.h
@@ -5,7 +5,7 @@
*
* Copyright (c) 2009 Wolfgang Grandegger <wg@grandegger.com>
*
- * Send feedback to <socketcan-users@lists.berlios.de>
+ * Send feedback to <linux-can@vger.kernel.org>
*
*/
diff --git a/include/linux/can/raw.h b/include/linux/can/raw.h
index b2a0f87..f825c94 100644
--- a/include/linux/can/raw.h
+++ b/include/linux/can/raw.h
@@ -8,7 +8,7 @@
* Copyright (c) 2002-2007 Volkswagen Group Electronic Research
* All rights reserved.
*
- * Send feedback to <socketcan-users@lists.berlios.de>
+ * Send feedback to <linux-can@vger.kernel.org>
*
*/
--
1.7.4.1
^ permalink raw reply related
* [PATCH 2/4] drivers/net/can: the mailinglist moved to vger.kernel.org
From: Marc Kleine-Budde @ 2011-10-14 8:43 UTC (permalink / raw)
To: netdev; +Cc: linux-can, Marc Kleine-Budde
In-Reply-To: <1318581817-12352-1-git-send-email-mkl@pengutronix.de>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
drivers/net/can/at91_can.c | 2 +-
drivers/net/can/sja1000/sja1000.c | 2 +-
drivers/net/can/sja1000/sja1000.h | 2 +-
drivers/net/can/slcan.c | 2 +-
drivers/net/can/vcan.c | 2 +-
5 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/net/can/at91_can.c b/drivers/net/can/at91_can.c
index 121ede6..63bfbd1 100644
--- a/drivers/net/can/at91_can.c
+++ b/drivers/net/can/at91_can.c
@@ -8,7 +8,7 @@
* Public License ("GPL") version 2 as distributed in the 'COPYING'
* file from the main directory of the linux kernel source.
*
- * Send feedback to <socketcan-users@lists.berlios.de>
+ * Send feedback to <linux-can@vger.kernel.org>
*
*
* Your platform definition file should specify something like:
diff --git a/drivers/net/can/sja1000/sja1000.c b/drivers/net/can/sja1000/sja1000.c
index f501bba..5eb4c95 100644
--- a/drivers/net/can/sja1000/sja1000.c
+++ b/drivers/net/can/sja1000/sja1000.c
@@ -40,7 +40,7 @@
* OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
* DAMAGE.
*
- * Send feedback to <socketcan-users@lists.berlios.de>
+ * Send feedback to <linux-can@vger.kernel.org>
*
*/
diff --git a/drivers/net/can/sja1000/sja1000.h b/drivers/net/can/sja1000/sja1000.h
index 78bd4ec..a6c388b 100644
--- a/drivers/net/can/sja1000/sja1000.h
+++ b/drivers/net/can/sja1000/sja1000.h
@@ -40,7 +40,7 @@
* OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
* DAMAGE.
*
- * Send feedback to <socketcan-users@lists.berlios.de>
+ * Send feedback to <linux-can@vger.kernel.org>
*
*/
diff --git a/drivers/net/can/slcan.c b/drivers/net/can/slcan.c
index 4b70b7e..727b686 100644
--- a/drivers/net/can/slcan.c
+++ b/drivers/net/can/slcan.c
@@ -35,7 +35,7 @@
* OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
* DAMAGE.
*
- * Send feedback to <socketcan-users@lists.berlios.de>
+ * Send feedback to <linux-can@vger.kernel.org>
*
*/
diff --git a/drivers/net/can/vcan.c b/drivers/net/can/vcan.c
index a30b8f4..54cc62a 100644
--- a/drivers/net/can/vcan.c
+++ b/drivers/net/can/vcan.c
@@ -37,7 +37,7 @@
* OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
* DAMAGE.
*
- * Send feedback to <socketcan-users@lists.berlios.de>
+ * Send feedback to <linux-can@vger.kernel.org>
*
*/
--
1.7.4.1
^ permalink raw reply related
* Re: [PATCH 0/4] can: the mailinglist moved to vger.kernel.org
From: Marc Kleine-Budde @ 2011-10-14 9:20 UTC (permalink / raw)
To: netdev; +Cc: linux-can
In-Reply-To: <1318581817-12352-1-git-send-email-mkl@pengutronix.de>
[-- Attachment #1: Type: text/plain, Size: 2087 bytes --]
On 10/14/2011 10:43 AM, Marc Kleine-Budde wrote:
> Hello,
>
> the BerliOS project will close with the end of the year, so we moved our
> mailinglist to vger.kernel.org, it's now linux-can@vger.kernel.org.
>
> This patch series changes every mail address accordingly.
The following changes since commit 7ae60b3f3b297b7f04025c93f1cb2275c3a1dfcd:
sky2: fix skb truesize underestimation (2011-10-13 17:12:46 -0400)
are available in the git repository at:
git.pengutronix.de:/git/mkl/linux-2.6.git can/mailinglist-for-net-next
Marc Kleine-Budde (4):
MAINTAINERS: can: the mailinglist moved to vger.kernel.org
drivers/net/can: the mailinglist moved to vger.kernel.org
net/can: the mailinglist moved to vger.kernel.org
include/linux/can: the mailinglist moved to vger.kernel.org
MAINTAINERS | 4 ++--
drivers/net/can/at91_can.c | 2 +-
drivers/net/can/sja1000/sja1000.c | 2 +-
drivers/net/can/sja1000/sja1000.h | 2 +-
drivers/net/can/slcan.c | 2 +-
drivers/net/can/vcan.c | 2 +-
include/linux/can.h | 2 +-
include/linux/can/bcm.h | 2 +-
include/linux/can/core.h | 2 +-
include/linux/can/dev.h | 2 +-
include/linux/can/error.h | 2 +-
include/linux/can/gw.h | 2 +-
include/linux/can/netlink.h | 2 +-
include/linux/can/raw.h | 2 +-
net/can/af_can.c | 2 +-
net/can/af_can.h | 2 +-
net/can/bcm.c | 2 +-
net/can/gw.c | 2 +-
net/can/proc.c | 2 +-
net/can/raw.c | 2 +-
20 files changed, 21 insertions(+), 21 deletions(-)
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
^ permalink raw reply
* Re: [net-next 5/6] igb: fix timecompare_upate race condition
From: Richard Cochran @ 2011-10-14 9:26 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: davem, Jacob Keller, netdev, gospo, sassmann
In-Reply-To: <1318573288-18286-6-git-send-email-jeffrey.t.kirsher@intel.com>
On Thu, Oct 13, 2011 at 11:21:27PM -0700, Jeff Kirsher wrote:
> From: Jacob Keller <jacob.e.keller@intel.com>
>
> This patch closes a possible race condition when timestamping using
> the timecompare_update function as a method to detect clock skew of
> the internal cycle counter. Because timecompare_update usually allows
> skew detection no more than once a second, if ptpd or other software
> performs a clock offset (for example, using the "date" command), there
> is a small window of time where the clock skew will not match the
> current kernel wall time. This patch forces the timecompare_update to
> calculate skew every time we timestamp a packet, which removes the
> possibility of this race condition.
NAK.
What will happen when you use the card for the telecom profile?
In that case you can expect 32 sync packets per second (plus delay
requests times number of clients).
A better way is to remove the timecompare stuff and offer a PTP
Hardware Clock instead. That would make the race condition a non-issue
and also enable the nice hardware clock offered by the card(s).
Thanks,
Richard
^ permalink raw reply
* [PATCH net-next 0/1] net: validate HWTSTAMP ioctl parameters
From: Richard Cochran @ 2011-10-14 9:37 UTC (permalink / raw)
To: netdev; +Cc: David Miller
In-Reply-To: <20110926.160443.1205173553442138535.davem@davemloft.net>
Okay, here is a patch to check the ioctl.
I took the liberty to check both the Rx and Tx fields. I coded the
check rather pedantically, using a switch/case over the enumerated
values. The advantage of this style is that the compiler will warn
if someone adds a new enum into net_tstamp.h without fixing the
checking function in dev.c.
Richard Cochran (1):
net: validate HWTSTAMP ioctl parameters
include/linux/net_tstamp.h | 4 +-
net/core/dev.c | 58 ++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 60 insertions(+), 2 deletions(-)
--
1.7.2.5
^ permalink raw reply
* [PATCH net-next 1/1] net: validate HWTSTAMP ioctl parameters
From: Richard Cochran @ 2011-10-14 9:37 UTC (permalink / raw)
To: netdev; +Cc: David Miller
In-Reply-To: <cover.1318584677.git.richard.cochran@omicron.at>
This patch adds a sanity check on the values provided by user space for
the hardware time stamping configuration. If the values lie outside of
the absolute limits, then the ioctl request will be denied.
Signed-off-by: Richard Cochran <richard.cochran@omicron.at>
---
include/linux/net_tstamp.h | 4 +-
net/core/dev.c | 58 ++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 60 insertions(+), 2 deletions(-)
diff --git a/include/linux/net_tstamp.h b/include/linux/net_tstamp.h
index 3df0984..ae5df12 100644
--- a/include/linux/net_tstamp.h
+++ b/include/linux/net_tstamp.h
@@ -45,7 +45,7 @@ struct hwtstamp_config {
};
/* possible values for hwtstamp_config->tx_type */
-enum {
+enum hwtstamp_tx_types {
/*
* No outgoing packet will need hardware time stamping;
* should a packet arrive which asks for it, no hardware
@@ -72,7 +72,7 @@ enum {
};
/* possible values for hwtstamp_config->rx_filter */
-enum {
+enum hwtstamp_rx_filters {
/* time stamp no incoming packet at all */
HWTSTAMP_FILTER_NONE,
diff --git a/net/core/dev.c b/net/core/dev.c
index 70ecb86..bc347e6 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -136,6 +136,7 @@
#include <linux/if_tunnel.h>
#include <linux/if_pppox.h>
#include <linux/ppp_defs.h>
+#include <linux/net_tstamp.h>
#include "net-sysfs.h"
@@ -1477,6 +1478,57 @@ static inline void net_timestamp_check(struct sk_buff *skb)
__net_timestamp(skb);
}
+static int net_hwtstamp_validate(struct ifreq *ifr)
+{
+ struct hwtstamp_config cfg;
+ enum hwtstamp_tx_types tx_type;
+ enum hwtstamp_rx_filters rx_filter;
+ int tx_type_valid = 0;
+ int rx_filter_valid = 0;
+
+ if (copy_from_user(&cfg, ifr->ifr_data, sizeof(cfg)))
+ return -EFAULT;
+
+ if (cfg.flags) /* reserved for future extensions */
+ return -EINVAL;
+
+ tx_type = cfg.tx_type;
+ rx_filter = cfg.rx_filter;
+
+ switch (tx_type) {
+ case HWTSTAMP_TX_OFF:
+ case HWTSTAMP_TX_ON:
+ case HWTSTAMP_TX_ONESTEP_SYNC:
+ tx_type_valid = 1;
+ break;
+ }
+
+ switch (rx_filter) {
+ case HWTSTAMP_FILTER_NONE:
+ case HWTSTAMP_FILTER_ALL:
+ case HWTSTAMP_FILTER_SOME:
+ case HWTSTAMP_FILTER_PTP_V1_L4_EVENT:
+ case HWTSTAMP_FILTER_PTP_V1_L4_SYNC:
+ case HWTSTAMP_FILTER_PTP_V1_L4_DELAY_REQ:
+ case HWTSTAMP_FILTER_PTP_V2_L4_EVENT:
+ case HWTSTAMP_FILTER_PTP_V2_L4_SYNC:
+ case HWTSTAMP_FILTER_PTP_V2_L4_DELAY_REQ:
+ case HWTSTAMP_FILTER_PTP_V2_L2_EVENT:
+ case HWTSTAMP_FILTER_PTP_V2_L2_SYNC:
+ case HWTSTAMP_FILTER_PTP_V2_L2_DELAY_REQ:
+ case HWTSTAMP_FILTER_PTP_V2_EVENT:
+ case HWTSTAMP_FILTER_PTP_V2_SYNC:
+ case HWTSTAMP_FILTER_PTP_V2_DELAY_REQ:
+ rx_filter_valid = 1;
+ break;
+ }
+
+ if (!tx_type_valid || !rx_filter_valid)
+ return -ERANGE;
+
+ return 0;
+}
+
static inline bool is_skb_forwardable(struct net_device *dev,
struct sk_buff *skb)
{
@@ -4921,6 +4973,12 @@ static int dev_ifsioc(struct net *net, struct ifreq *ifr, unsigned int cmd)
ifr->ifr_newname[IFNAMSIZ-1] = '\0';
return dev_change_name(dev, ifr->ifr_newname);
+ case SIOCSHWTSTAMP:
+ err = net_hwtstamp_validate(ifr);
+ if (err)
+ return err;
+ /* fall through */
+
/*
* Unknown or private ioctl
*/
--
1.7.2.5
^ permalink raw reply related
* [PATCH] dev: use ifindex hash for dev_seq_ops
From: Mihai Maruseac @ 2011-10-14 9:53 UTC (permalink / raw)
To: davem
Cc: eric.dumazet, mirq-linux, therbert, jpirko, netdev, linux-kernel,
dbaluta, Mihai Maruseac
In-Reply-To: <1318413446-22258-1-git-send-email-mmaruseac@ixiacom.com>
Instead of using the dev->next chain and trying to resync at each call to
dev_seq_start, use the ifindex, keeping the last index in seq->private field.
Tests revealed the following results for ifconfig > /dev/null
* 1000 interfaces:
* 0.114s without patch
* 0.089s with patch
* 3000 interfaces:
* 0.489s without patch
* 0.110s with patch
* 5000 interfaces:
* 1.363s without patch
* 0.250s with patch
* 128000 interfaces (other setup):
* ~100s without patch
* ~30s with patch
Signed-off-by: Mihai Maruseac <mmaruseac@ixiacom.com>
---
net/core/dev.c | 55 ++++++++++++++++++++++++++++++++++---------------------
1 files changed, 34 insertions(+), 21 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index 70ecb86..ea24445 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -4041,6 +4041,37 @@ static int dev_ifconf(struct net *net, char __user *arg)
}
#ifdef CONFIG_PROC_FS
+
+struct dev_iter_state {
+ struct seq_net_private p;
+ int ifindex;
+};
+
+static struct net_device *__dev_seq_next(struct seq_file *seq, loff_t *pos)
+{
+ struct dev_iter_state *state = seq->private;
+ struct net *net = seq_file_net(seq);
+ struct net_device *dev;
+ loff_t off;
+
+ dev = dev_get_by_index_rcu(net, state->ifindex);
+ if (likely(dev))
+ goto found;
+
+ off = 0;
+ for_each_netdev_rcu(net, dev)
+ if (off++ == *pos) {
+ state->ifindex = dev->ifindex;
+ goto found;
+ }
+
+ return NULL;
+found:
+ state->ifindex++;
+ ++*pos;
+ return dev;
+}
+
/*
* This is invoked by the /proc filesystem handler to display a device
* in detail.
@@ -4048,33 +4079,15 @@ static int dev_ifconf(struct net *net, char __user *arg)
void *dev_seq_start(struct seq_file *seq, loff_t *pos)
__acquires(RCU)
{
- struct net *net = seq_file_net(seq);
- loff_t off;
- struct net_device *dev;
-
rcu_read_lock();
if (!*pos)
return SEQ_START_TOKEN;
-
- off = 1;
- for_each_netdev_rcu(net, dev)
- if (off++ == *pos)
- return dev;
-
- return NULL;
+ return __dev_seq_next(seq, pos);
}
void *dev_seq_next(struct seq_file *seq, void *v, loff_t *pos)
{
- struct net_device *dev = v;
-
- if (v == SEQ_START_TOKEN)
- dev = first_net_device_rcu(seq_file_net(seq));
- else
- dev = next_net_device_rcu(dev);
-
- ++*pos;
- return dev;
+ return __dev_seq_next(seq, pos);
}
void dev_seq_stop(struct seq_file *seq, void *v)
@@ -4173,7 +4186,7 @@ static const struct seq_operations dev_seq_ops = {
static int dev_seq_open(struct inode *inode, struct file *file)
{
return seq_open_net(inode, file, &dev_seq_ops,
- sizeof(struct seq_net_private));
+ sizeof(struct dev_iter_state));
}
static const struct file_operations dev_seq_fops = {
--
1.7.4.1
^ permalink raw reply related
* Re:
From: Hamde Nazar @ 2011-10-14 9:54 UTC (permalink / raw)
Dear Friend,
I have an offer which I need your assistant, your share will be 50%;
please if you are interested do contact me for more details.my personal
email:vhong_p11@yahoo.com.hk
Email Address:vhong_p11@yahoo.com.hk
Mr Vincent Hong
^ permalink raw reply
* [PATCH] r8169: fix driver shutdown WoL regression.
From: Francois Romieu @ 2011-10-14 10:57 UTC (permalink / raw)
To: netdev; +Cc: Marc Ballarin, David Miller, Hayes
Due to commit 92fc43b4159b518f5baae57301f26d770b0834c9 ("r8169: modify the
flow of the hw reset."), rtl8169_hw_reset stomps during driver shutdown on
RxConfig bits which are needed for WOL on some versions of the hardware.
As these bits were formerly set from the r81{0x, 68}_pll_power_down methods,
factor them out for use in the driver shutdown (rtl_shutdown) handler.
I favored __rtl8169_get_wol() -hardware state indication- over
RTL_FEATURE_WOL as the latter has become a good candidate for removal.
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Cc: Hayes <hayeswang@realtek.com>
---
Marc, can you add your Tested-by: to this patch ? It avoids the extra
phy writes which were included in the previous revision of the patch.
They did not happen before the regression so there is no reason to
sneak them in -release. Works ok with RTL_GIGA_MAC_VER_34.
drivers/net/r8169.c | 88 ++++++++++++++++++++++++++++++++------------------
1 files changed, 56 insertions(+), 32 deletions(-)
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index c236670..24219ec 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -3316,6 +3316,37 @@ static void __devinit rtl_init_mdio_ops(struct rtl8169_private *tp)
}
}
+static void rtl_wol_suspend_quirk(struct rtl8169_private *tp)
+{
+ void __iomem *ioaddr = tp->mmio_addr;
+
+ switch (tp->mac_version) {
+ case RTL_GIGA_MAC_VER_29:
+ case RTL_GIGA_MAC_VER_30:
+ case RTL_GIGA_MAC_VER_32:
+ case RTL_GIGA_MAC_VER_33:
+ case RTL_GIGA_MAC_VER_34:
+ RTL_W32(RxConfig, RTL_R32(RxConfig) |
+ AcceptBroadcast | AcceptMulticast | AcceptMyPhys);
+ break;
+ default:
+ break;
+ }
+}
+
+static bool rtl_wol_pll_power_down(struct rtl8169_private *tp)
+{
+ if (!(__rtl8169_get_wol(tp) & WAKE_ANY))
+ return false;
+
+ rtl_writephy(tp, 0x1f, 0x0000);
+ rtl_writephy(tp, MII_BMCR, 0x0000);
+
+ rtl_wol_suspend_quirk(tp);
+
+ return true;
+}
+
static void r810x_phy_power_down(struct rtl8169_private *tp)
{
rtl_writephy(tp, 0x1f, 0x0000);
@@ -3330,18 +3361,8 @@ static void r810x_phy_power_up(struct rtl8169_private *tp)
static void r810x_pll_power_down(struct rtl8169_private *tp)
{
- void __iomem *ioaddr = tp->mmio_addr;
-
- if (__rtl8169_get_wol(tp) & WAKE_ANY) {
- rtl_writephy(tp, 0x1f, 0x0000);
- rtl_writephy(tp, MII_BMCR, 0x0000);
-
- if (tp->mac_version == RTL_GIGA_MAC_VER_29 ||
- tp->mac_version == RTL_GIGA_MAC_VER_30)
- RTL_W32(RxConfig, RTL_R32(RxConfig) | AcceptBroadcast |
- AcceptMulticast | AcceptMyPhys);
+ if (rtl_wol_pll_power_down(tp))
return;
- }
r810x_phy_power_down(tp);
}
@@ -3430,17 +3451,8 @@ static void r8168_pll_power_down(struct rtl8169_private *tp)
tp->mac_version == RTL_GIGA_MAC_VER_33)
rtl_ephy_write(ioaddr, 0x19, 0xff64);
- if (__rtl8169_get_wol(tp) & WAKE_ANY) {
- rtl_writephy(tp, 0x1f, 0x0000);
- rtl_writephy(tp, MII_BMCR, 0x0000);
-
- if (tp->mac_version == RTL_GIGA_MAC_VER_32 ||
- tp->mac_version == RTL_GIGA_MAC_VER_33 ||
- tp->mac_version == RTL_GIGA_MAC_VER_34)
- RTL_W32(RxConfig, RTL_R32(RxConfig) | AcceptBroadcast |
- AcceptMulticast | AcceptMyPhys);
+ if (rtl_wol_pll_power_down(tp))
return;
- }
r8168_phy_power_down(tp);
@@ -5788,11 +5800,30 @@ static const struct dev_pm_ops rtl8169_pm_ops = {
#endif /* !CONFIG_PM */
+static void rtl_wol_shutdown_quirk(struct rtl8169_private *tp)
+{
+ void __iomem *ioaddr = tp->mmio_addr;
+
+ /* WoL fails with 8168b when the receiver is disabled. */
+ switch (tp->mac_version) {
+ case RTL_GIGA_MAC_VER_11:
+ case RTL_GIGA_MAC_VER_12:
+ case RTL_GIGA_MAC_VER_17:
+ pci_clear_master(tp->pci_dev);
+
+ RTL_W8(ChipCmd, CmdRxEnb);
+ /* PCI commit */
+ RTL_R8(ChipCmd);
+ break;
+ default:
+ break;
+ }
+}
+
static void rtl_shutdown(struct pci_dev *pdev)
{
struct net_device *dev = pci_get_drvdata(pdev);
struct rtl8169_private *tp = netdev_priv(dev);
- void __iomem *ioaddr = tp->mmio_addr;
rtl8169_net_suspend(dev);
@@ -5806,16 +5837,9 @@ static void rtl_shutdown(struct pci_dev *pdev)
spin_unlock_irq(&tp->lock);
if (system_state == SYSTEM_POWER_OFF) {
- /* WoL fails with 8168b when the receiver is disabled. */
- if ((tp->mac_version == RTL_GIGA_MAC_VER_11 ||
- tp->mac_version == RTL_GIGA_MAC_VER_12 ||
- tp->mac_version == RTL_GIGA_MAC_VER_17) &&
- (tp->features & RTL_FEATURE_WOL)) {
- pci_clear_master(pdev);
-
- RTL_W8(ChipCmd, CmdRxEnb);
- /* PCI commit */
- RTL_R8(ChipCmd);
+ if (__rtl8169_get_wol(tp) & WAKE_ANY) {
+ rtl_wol_suspend_quirk(tp);
+ rtl_wol_shutdown_quirk(tp);
}
pci_wake_from_d3(pdev, true);
--
1.7.6.4
^ permalink raw reply related
* Re: [PATCH] r8169: fix driver shutdown WoL regression.
From: Marc Ballarin @ 2011-10-14 12:12 UTC (permalink / raw)
To: Francois Romieu; +Cc: netdev, David Miller, Hayes
In-Reply-To: <20111014105745.GA11204@electric-eye.fr.zoreil.com>
On Fri, 14 Oct 2011 12:57:45 +0200
Francois Romieu <romieu@fr.zoreil.com> wrote:
> ...
> Marc, can you add your Tested-by: to this patch ? It avoids the extra
> phy writes which were included in the previous revision of the patch.
> They did not happen before the regression so there is no reason to
> sneak them in -release. Works ok with RTL_GIGA_MAC_VER_34.
Works fine on RTL_GIGA_MAC_VER_33 as well.
Tested-by: Marc Ballarin <ballarin.marc@gmx.de>
^ permalink raw reply
* Re: [PATCH] dev: use ifindex hash for dev_seq_ops
From: Mihai Maruseac @ 2011-10-14 12:20 UTC (permalink / raw)
To: Stephen Hemminger
Cc: davem, eric.dumazet, mirq-linux, therbert, jpirko, netdev,
linux-kernel, dbaluta, Mihai Maruseac
In-Reply-To: <20111012085024.634281a2@nehalam.linuxnetplumber.net>
On Wed, Oct 12, 2011 at 6:50 PM, Stephen Hemminger
<shemminger@vyatta.com> wrote:
> On Wed, 12 Oct 2011 12:57:26 +0300
> Mihai Maruseac <mihai.maruseac@gmail.com> wrote:
>
> It looks like you lost the ability to seek back and read the header
> (start token). How is the header handled, is possible to rewind
> the file and read it over again?
We tested with a simple program reading a part of the /proc file and
then doing a seek to the start and rereading. It worked with latest
submitted patch.
>> +static inline struct net_device *next_dev(struct seq_file *seq, loff_t *pos)
>> +{
>> + struct dev_iter_state *state = seq->private;
>> + struct net *net = seq_file_net(seq);
>> + struct net_device *dev = NULL;
>> + loff_t off;
>> +
>> + ++*pos;
>> + dev = dev_get_by_index_rcu(net, state->ifindex);
>
> Looks good a couple of minor nits.
>
> 1. The function should not be inline, since it is in no way performance
> critical. The compiler will probably inline it anyway.
>
> 2. dev does not have to be initialized since it is assigned a few
> lines later. Most programmers are trained now to always initialize
> variables, but often it is unnecessary.
>
> 3. The name next_dev() is a little generic; maybe a better name.
>
Fixed all of them,
Thanks,
--
Mihai
^ permalink raw reply
* [PATCH 17/21] stmmac: drop unused Kconfig symbol
From: Paul Bolle @ 2011-10-14 12:30 UTC (permalink / raw)
To: Giuseppe Cavallaro; +Cc: netdev, linux-kernel
Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
---
drivers/net/stmmac/Kconfig | 9 ---------
1 files changed, 0 insertions(+), 9 deletions(-)
diff --git a/drivers/net/stmmac/Kconfig b/drivers/net/stmmac/Kconfig
index 7df7df4..9e37a9a 100644
--- a/drivers/net/stmmac/Kconfig
+++ b/drivers/net/stmmac/Kconfig
@@ -20,15 +20,6 @@ config STMMAC_DA
By default, the DMA arbitration scheme is based on Round-robin
(rx:tx priority is 1:1).
-config STMMAC_DUAL_MAC
- bool "STMMAC: dual mac support (EXPERIMENTAL)"
- default n
- depends on EXPERIMENTAL && STMMAC_ETH && !STMMAC_TIMER
- help
- Some ST SoCs (for example the stx7141 and stx7200c2) have two
- Ethernet Controllers. This option turns on the second Ethernet
- device on this kind of platforms.
-
config STMMAC_TIMER
bool "STMMAC Timer optimisation"
default n
--
1.7.4.4
^ permalink raw reply related
* Re: [PATCH] dev: use ifindex hash for dev_seq_ops
From: Eric Dumazet @ 2011-10-14 12:53 UTC (permalink / raw)
To: Mihai Maruseac
Cc: davem, mirq-linux, therbert, jpirko, netdev, linux-kernel,
dbaluta, Mihai Maruseac
In-Reply-To: <1318586017-17207-1-git-send-email-mmaruseac@ixiacom.com>
Le vendredi 14 octobre 2011 à 12:53 +0300, Mihai Maruseac a écrit :
> Instead of using the dev->next chain and trying to resync at each call to
> dev_seq_start, use the ifindex, keeping the last index in seq->private field.
>
> Tests revealed the following results for ifconfig > /dev/null
> * 1000 interfaces:
> * 0.114s without patch
> * 0.089s with patch
> * 3000 interfaces:
> * 0.489s without patch
> * 0.110s with patch
> * 5000 interfaces:
> * 1.363s without patch
> * 0.250s with patch
> * 128000 interfaces (other setup):
> * ~100s without patch
> * ~30s with patch
>
> Signed-off-by: Mihai Maruseac <mmaruseac@ixiacom.com>
> ---
> net/core/dev.c | 55 ++++++++++++++++++++++++++++++++++---------------------
> 1 files changed, 34 insertions(+), 21 deletions(-)
>
> diff --git a/net/core/dev.c b/net/core/dev.c
> index 70ecb86..ea24445 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -4041,6 +4041,37 @@ static int dev_ifconf(struct net *net, char __user *arg)
> }
>
> #ifdef CONFIG_PROC_FS
> +
> +struct dev_iter_state {
> + struct seq_net_private p;
> + int ifindex;
> +};
> +
> +static struct net_device *__dev_seq_next(struct seq_file *seq, loff_t *pos)
> +{
> + struct dev_iter_state *state = seq->private;
> + struct net *net = seq_file_net(seq);
> + struct net_device *dev;
> + loff_t off;
> +
> + dev = dev_get_by_index_rcu(net, state->ifindex);
> + if (likely(dev))
> + goto found;
> +
> + off = 0;
> + for_each_netdev_rcu(net, dev)
> + if (off++ == *pos) {
> + state->ifindex = dev->ifindex;
> + goto found;
> + }
> +
> + return NULL;
> +found:
> + state->ifindex++;
This assumes device ifindexes are contained in a small range
[N .. N + X]
I understand this can help some benchmarks, but in real world this wont
help that much once ifindexes are 'fragmented' (If really this multi
thousand devices stuff is for real)
Listen, we currently have 256 slots in the hash table.
Can we try to make 'offset' something like (slot_number<<24) +
(position in hash chain [slot_number]), instead of (position in devices
global list)
^ 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