* Re: [PATCH net-next-2.6 16/17] sfc: Use current MAC address, not NVRAM MAC address, for WoL filter
From: David Miller @ 2010-12-03 17:10 UTC (permalink / raw)
To: bhutchings; +Cc: netdev, linux-net-drivers
In-Reply-To: <1291333700.3259.39.camel@bwh-desktop>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Thu, 02 Dec 2010 23:48:20 +0000
> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next-2.6 15/17] sfc: When waking a stopped tx_queue, only lock that tx_queue
From: David Miller @ 2010-12-03 17:10 UTC (permalink / raw)
To: bhutchings; +Cc: netdev, linux-net-drivers
In-Reply-To: <1291333694.3259.38.camel@bwh-desktop>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Thu, 02 Dec 2010 23:48:14 +0000
> From: Steve Hodgson <shodgson@solarflare.com>
>
> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next-2.6 14/17] sfc: Update kernel-doc to match earlier move of Toeplitz hash key
From: David Miller @ 2010-12-03 17:09 UTC (permalink / raw)
To: bhutchings; +Cc: netdev, linux-net-drivers
In-Reply-To: <1291333676.3259.37.camel@bwh-desktop>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Thu, 02 Dec 2010 23:47:56 +0000
> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next-2.6 13/17] sfc: Move xmac_poll_required into struct falcon_nic_data
From: David Miller @ 2010-12-03 17:09 UTC (permalink / raw)
To: bhutchings; +Cc: netdev, linux-net-drivers
In-Reply-To: <1291333671.3259.36.camel@bwh-desktop>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Thu, 02 Dec 2010 23:47:51 +0000
> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next-2.6 12/17] sfc: Move Falcon global event handling to falcon.c
From: David Miller @ 2010-12-03 17:09 UTC (permalink / raw)
To: bhutchings; +Cc: netdev, linux-net-drivers
In-Reply-To: <1291333665.3259.35.camel@bwh-desktop>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Thu, 02 Dec 2010 23:47:45 +0000
> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next-2.6 11/17] sfc: Move mdio_lock to struct falcon_nic_data
From: David Miller @ 2010-12-03 17:09 UTC (permalink / raw)
To: bhutchings; +Cc: netdev, linux-net-drivers
In-Reply-To: <1291333655.3259.34.camel@bwh-desktop>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Thu, 02 Dec 2010 23:47:35 +0000
> We only have direct access to MDIO on Falcon, so move this out of
> struct efx_nic.
>
> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next-2.6 10/17] sfc: Move SPI state to struct falcon_nic_data
From: David Miller @ 2010-12-03 17:09 UTC (permalink / raw)
To: bhutchings; +Cc: netdev, linux-net-drivers
In-Reply-To: <1291333649.3259.33.camel@bwh-desktop>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Thu, 02 Dec 2010 23:47:29 +0000
> We only have direct access to SPI on Falcon, so move all this state
> out of struct efx_nic.
>
> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next-2.6 09/17] sfc: Remove unnecessary inclusion of various private header files
From: David Miller @ 2010-12-03 17:09 UTC (permalink / raw)
To: bhutchings; +Cc: netdev, linux-net-drivers
In-Reply-To: <1291333637.3259.32.camel@bwh-desktop>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Thu, 02 Dec 2010 23:47:17 +0000
> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next-2.6 08/17] sfc: Expose Falcon BootROM config through MTD, not ethtool
From: David Miller @ 2010-12-03 17:09 UTC (permalink / raw)
To: bhutchings; +Cc: netdev, linux-net-drivers
In-Reply-To: <1291333630.3259.31.camel@bwh-desktop>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Thu, 02 Dec 2010 23:47:10 +0000
> The ethtool EEPROM interface is really meant for exposing chip
> configuration, not BootROM configuration.
>
> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next-2.6 07/17] sfc: Remove broken automatic fallback for invalid Falcon chip/board config
From: David Miller @ 2010-12-03 17:09 UTC (permalink / raw)
To: bhutchings; +Cc: netdev, linux-net-drivers
In-Reply-To: <1291333621.3259.30.camel@bwh-desktop>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Thu, 02 Dec 2010 23:47:01 +0000
> If the Falcon board config is invalid, we cannot proceed - we do not
> have a valid board type to pass to falcon_probe_board(), and if we
> kluge that to work with an unknown board then other initialisation
> code will crash.
>
> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next-2.6 06/17] sfc: Fix event based MCDI completion and MC REBOOT/CMDDONE ordering issue
From: David Miller @ 2010-12-03 17:09 UTC (permalink / raw)
To: bhutchings; +Cc: netdev, linux-net-drivers
In-Reply-To: <1291333615.3259.29.camel@bwh-desktop>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Thu, 02 Dec 2010 23:46:55 +0000
> From: Steve Hodgson <shodgson@solarflare.com>
>
> The mcfw *never* sends CMDDONE when rebooting. Changing this so that it always
> sends CMDDONE *before* REBOOT is easy on Siena, but it's not obvious that we
> could guarantee to be able to implement this on future hardware.
>
> Given this, I'm less convinced that the protocol should be changed.
>
> To reiterate the failure mode: The driver sees this:
>
> issue command
> receive REBOOT event
>
> Was that reboot event sent before the command was issued, or in
> response to the command? If the former then there will be a subsequent
> CMDDONE event, if the latter, then there will be no CMDDONE event.
>
> Options to resolve this are:
>
> 1. REBOOT always completes an outstanding mcdi request, and we set
> the credits count to ignore a subsequent CMDDONE event with
> mismatching seqno.
>
> 2. REBOOT never completes an outstanding mcdi request. If there is
> no CMDDONE event then we rely on the mcdi timeout code to complete
> the outstanding request, incurring a 10s delay.
>
> I'd argue that (2) is tidier, but that incurring a 10s delay is a little
> needless. Let's go with (1).
>
> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next-2.6 05/17] sfc: Clear RXIN_SEL when soft-resetting QT2025C
From: David Miller @ 2010-12-03 17:08 UTC (permalink / raw)
To: bhutchings; +Cc: netdev, linux-net-drivers
In-Reply-To: <1291333597.3259.28.camel@bwh-desktop>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Thu, 02 Dec 2010 23:46:37 +0000
> When we enable PMA/PMD loopback this automatically sets RXIN_SEL
> (inverse polarity for RXIN). We need to clear that bit during the
> soft-reset sequence, as it is not done automatically.
>
> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next-2.6 04/17] sfc: Read-to-clear LM87 alarm/interrupt status at start of day
From: David Miller @ 2010-12-03 17:08 UTC (permalink / raw)
To: bhutchings; +Cc: netdev, linux-net-drivers
In-Reply-To: <1291333591.3259.27.camel@bwh-desktop>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Thu, 02 Dec 2010 23:46:31 +0000
> We do not want to shut down the board based on a fault that has
> already been cleared.
>
> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next-2.6 03/17] sfc: Distinguish critical and non-critical over-temperature conditions
From: David Miller @ 2010-12-03 17:08 UTC (permalink / raw)
To: bhutchings; +Cc: netdev, linux-net-drivers
In-Reply-To: <1291333584.3259.26.camel@bwh-desktop>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Thu, 02 Dec 2010 23:46:24 +0000
> Set both the 'maximum' and critical temperature limits for LM87
> hardware monitors on Falcon boards. Do not shut down a port until the
> critical temperature is reached, but warn as soon as the 'maximum'
> temperature is reached.
>
> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next-2.6 02/17] sfc: Fix condition for no-op in set_phy_flash_cfg()
From: David Miller @ 2010-12-03 17:08 UTC (permalink / raw)
To: bhutchings; +Cc: netdev, linux-net-drivers
In-Reply-To: <1291333574.3259.25.camel@bwh-desktop>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Thu, 02 Dec 2010 23:46:14 +0000
> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next-2.6 01/17] sfc: Reduce log level for MCDI error response in efx_mcdi_rpc()
From: David Miller @ 2010-12-03 17:08 UTC (permalink / raw)
To: bhutchings; +Cc: netdev, linux-net-drivers
In-Reply-To: <1291333569.3259.24.camel@bwh-desktop>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Thu, 02 Dec 2010 23:46:09 +0000
> Some errors are expected, e.g. when sending new commands to an MC
> running old firmware. Only the caller of efx_mcdi_rpc() can decide
> what is a real error. Therefore log the error responses with
> netif_dbg().
>
> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Applied.
^ permalink raw reply
* Re: [PATCH v2] ethtool : Allow ethtool to set interface in loopback mode.
From: David Lamparter @ 2010-12-03 16:48 UTC (permalink / raw)
To: Ben Hutchings
Cc: David Lamparter, Mahesh Bandewar, linux-netdev, Tom Herbert,
David Miller
In-Reply-To: <1291394014.13384.7.camel@bwh-desktop>
On Fri, Dec 03, 2010 at 04:33:34PM +0000, Ben Hutchings wrote:
> On Fri, 2010-12-03 at 17:03 +0100, David Lamparter wrote:
> > On Thu, Dec 02, 2010 at 02:35:51PM -0800, Mahesh Bandewar wrote:
> > > This patch adds -L command-line option to switch loopback mode on/off
> > > and -l option to display current loopback mode on a specified interface.
> > [...]
> > > +.A1 on off
> > > +Switches loopback mode
> > > +.B on
> > > +or
> > > +.B off
> >
> > What about devices that support different kinds of loopback, like MAC
> > loopback & PHY loopback? (No idea if we have kernel support for this
> > either...)
>
> That distinction is useful for diagnostic purposes, but drivers can
> already cover those different loopback modes in self-test. The
> motivation for this feature is testing data path behaviour, and Mahesh
> has specified that loopback should be enabled as near as possible to the
> host.
Ah, good enough. Thanks.
-David
^ permalink raw reply
* BUG: secpath not clearing between namespaces
From: Andrew Dickinson @ 2010-12-03 16:47 UTC (permalink / raw)
To: netdev
Hi,
I think I've found a bug in the xfrm stack relating to namespaces. I
can reproduce this consistently (see below).
I have the 3 namespaces which I refer to as "CORE", "VPN1" and "VPN2".
VPN1 and VPN2 each have 1 veth interfaces, CORE has 2 veth interfaces.
I'm using a pair of bridge (not in a namespace) to plumb the
namespaces together:
VPN1 and CORE are on 10.0.1.12/30 with each of their veth pairs in a
non-namespaced bridge.
VPN2 and CORE are on 10.0.1.16/30 with each of their veth pairs in a
different non-namespaced bridge.
VPN1 has an ipsec tunnel to 10.254.0.0/23
VPN2 has an ipsec tunnel to 10.254.2.0/23
What does work: From CORE, I can happily ping hosts on the far side of
either tunnel (as expected). Likewise, from VPN1 I can ping hosts
down its tunnel and the same for VPN2. (again: as expected).
What DOESN'T work: from VPN1 I can't ping a host on the far side of
VPN2 and visa-versa.
What I see is that when the traffic arrives at VPN2 it tries to ARP
for it's next-hop (which _should_ be encrypted and set across the
tunnel). It appears that it's chosing to NOT encrypt the traffic and
perform normal IPv4 forwarding. I suspect that this is because when
the frame was being processed in VPN1 it hit an SPD policy setting the
secpath action to "none":
The last few lines in VPN1's "setkey.conf" file:
spdadd 0.0.0.0/0 0.0.0.0/0 any -P in prio 10 none;
spdadd 0.0.0.0/0 0.0.0.0/0 any -P out prio 10 none;
As such, when the packet arrives on VPN2, VPN2 is seeing that the sp
is already set and not trying to re-compute the policy.
I can further confirm this by setting an SPD in CORE which does ONLY
the "none/none" policy and the traffic will instantly break; clearing
the SPD and SAD in CORE restores service. See here:
root@CORE:~# cat /etc/racoon/setkey.conf
flush;
spdflush;
spdadd 0.0.0.0/0 0.0.0.0/0 any -P in prio 10 none;
spdadd 0.0.0.0/0 0.0.0.0/0 any -P out prio 10 none;
root@CORE:~# ping -c1 10.254.2.5
PING 10.254.2.5 (10.254.2.5) 56(84) bytes of data.
>From 10.1.2.18: icmp_seq=1 Redirect Host(New nexthop: 169.254.254.5)
>From 10.1.2.18 icmp_seq=1 Destination Host Unreachable
--- 10.254.2.5 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms
root@CORE:~# setkey -F; setkey -PF
root@CORE:~# ping -c1 10.254.2.5
PING 10.254.2.5 (10.254.2.5) 56(84) bytes of data.
64 bytes from 10.254.2.5: icmp_seq=1 ttl=62 time=186 ms
--- 10.254.2.5 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 186.187/186.187/186.187/0.000 ms
It seems like the xfrm code needs to validate that the sp that's set
belongs to the current namespace that's processing it???
-A
^ permalink raw reply
* Re: RFS configuration questions
From: Eric Dumazet @ 2010-12-03 16:34 UTC (permalink / raw)
To: Shawn Bohrer; +Cc: netdev, therbert
In-Reply-To: <20101203160035.GA2698@BohrerMBP.rgmadvisors.com>
Le vendredi 03 décembre 2010 à 10:00 -0600, Shawn Bohrer a écrit :
> On Thu, Dec 02, 2010 at 10:40:41PM +0100, Eric Dumazet wrote:
> > Le jeudi 02 décembre 2010 à 15:16 -0600, Shawn Bohrer a écrit :
> > > I've been playing around with RPS/RFS on my multiqueue 10g Chelsio NIC
> > > and I've got some questions about configuring RFS.
> > >
> > > I've enabled RPS with:
> > >
> > > for x in $(seq 0 7); do
> > > echo FFFFFFFF,FFFFFFFF > /sys/class/net/vlan816/queues/rx-${x}/rps_cpus
> > > done
> > >
> > > This appears to work when I watch 'mpstat -P ALL 1' as I can see the
> > > softirq load is now getting distributed across all of the CPUs instead
> > > of just the four (the card is a two port card and assigns four queues
> > > per port) original hw receive queues which I have bound to CPUs
> > > 0-3.
> > >
> > > To enable RFS I've run:
> > >
> > > echo 16384 > /proc/sys/net/core/rps_sock_flow_entries
> > >
> > > Is there any explanation of what this sysctl actually does? Is this
> > > the max number of sockets/flows that the kernel can steer? Is this a
> > > system wide max, a per interface max, or a per receive queue max?
> > >
> >
> > Yes, some doc is missing...
> >
> > Its a system wide and shared limit.
>
> So the sum of /sys/class/net/*/queues/rx-*/rps_flow_cnt should be less
> than or equal to rps_sock_flow_entries?
>
I always used same count, but you probably can use lower values
for /sys/class/net/*/queues/rx-*/rps_flow_cnt if you dont have much
memory.
> > > Next I ran:
> > >
> > > for x in $(seq 0 7); do
> > > echo 16384 > /sys/class/net/vlan816/queues/rx-${x}/rps_flow_cnt
> > > done
> > >
> > > Is this correct? Is these the max number of sockets/flows that can be
> > > steered per receive queue? Does the sum of these values need to add
> > > up to rps_sock_flow_entries (I also tried 2048)? Is this all that is
> > > needed to enable RFS?
> > >
> >
> > Yes thats all.
>
> Same as above... I should be using 2048 if I have 8 queues and have
> set rps_sock_flow_entries to 16384? Out of curiosity what happens
> when you open more sockets than you have rps_flow_cnt?
Its a hash table, so collisions can happen. Nothing bad happens.
>
> > > With these settings I can watch 'mpstat -P ALL 1' and it doesn't
> > > appear RFS has changed the softirq load. To get a better idea if it
> > > was working I used taskset to bind my receiving processes to a set of
> > > cores, yet mpstat still shows the softirq load getting distributed
> > > across all cores, not just the ones where my receiving processes are
> > > bound. Is there a better way to determine if RFS is actually working?
> > > Have I configured RFS incorrectly?
> >
> > It seems fine to me, but what kind of workload do you have, and what
> > version of kernel do you run ?
>
> I just did some more testing on 2.6.36.1. Using netperf UDP_STREAM
> and TCP_STREAM I was able to see that the softirq load would run on
> the CPU where netperf was bound so it appears that RFS is working.
Be careful about softirq times, they most of the time are wrong.
You can do "cat /proc/net/softnet_stat" and check last column to see if
packets are really distributed to "other cpus"
>
> However if I run one of my applications which is a single process
> listening to ~30 multicast addresses the softirq load does not run on
> the CPU where the application is bound. Does RFS not support
> receiving multicast?
No because :
net/ipv4/udp.c
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);
Rationale is : RFS is implemented for _connected_ sockets only (TCP or
connected UDP)
(You can check commit changelog :
http://git2.kernel.org/?p=linux/kernel/git/davem/net-next-2.6.git;a=commit;h=fec5e652e58fa6017b2c9e06466cb2a6538de5b4
This is because rxhash value is different for each src address.
If we allowed your process to call sock_rps_save_rxhash(sk,
skb->rxhash); with many different rxhash, it would blow the hash table.
You might try to remove the "if (inet_sk(sk)->inet_daddr)" test for
your benches, or add a new logic (socket flag maybe ?) to really trigger
RFS on your UDP sockets.
^ permalink raw reply
* Re: [PATCH v2] ethtool : Allow ethtool to set interface in loopback mode.
From: Ben Hutchings @ 2010-12-03 16:33 UTC (permalink / raw)
To: David Lamparter; +Cc: Mahesh Bandewar, linux-netdev, Tom Herbert, David Miller
In-Reply-To: <20101203160333.GA235120@jupiter.n2.diac24.net>
On Fri, 2010-12-03 at 17:03 +0100, David Lamparter wrote:
> On Thu, Dec 02, 2010 at 02:35:51PM -0800, Mahesh Bandewar wrote:
> > This patch adds -L command-line option to switch loopback mode on/off
> > and -l option to display current loopback mode on a specified interface.
> [...]
> > +.A1 on off
> > +Switches loopback mode
> > +.B on
> > +or
> > +.B off
>
> What about devices that support different kinds of loopback, like MAC
> loopback & PHY loopback? (No idea if we have kernel support for this
> either...)
That distinction is useful for diagnostic purposes, but drivers can
already cover those different loopback modes in self-test. The
motivation for this feature is testing data path behaviour, and Mahesh
has specified that loopback should be enabled as near as possible to the
host.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: RFS configuration questions
From: Ben Hutchings @ 2010-12-03 16:30 UTC (permalink / raw)
To: Shawn Bohrer; +Cc: Eric Dumazet, netdev, therbert
In-Reply-To: <20101203160035.GA2698@BohrerMBP.rgmadvisors.com>
On Fri, 2010-12-03 at 10:00 -0600, Shawn Bohrer wrote:
> On Thu, Dec 02, 2010 at 10:40:41PM +0100, Eric Dumazet wrote:
> > Le jeudi 02 décembre 2010 à 15:16 -0600, Shawn Bohrer a écrit :
> > > I've been playing around with RPS/RFS on my multiqueue 10g Chelsio NIC
> > > and I've got some questions about configuring RFS.
> > >
> > > I've enabled RPS with:
> > >
> > > for x in $(seq 0 7); do
> > > echo FFFFFFFF,FFFFFFFF > /sys/class/net/vlan816/queues/rx-${x}/rps_cpus
> > > done
> > >
> > > This appears to work when I watch 'mpstat -P ALL 1' as I can see the
> > > softirq load is now getting distributed across all of the CPUs instead
> > > of just the four (the card is a two port card and assigns four queues
> > > per port) original hw receive queues which I have bound to CPUs
> > > 0-3.
> > >
> > > To enable RFS I've run:
> > >
> > > echo 16384 > /proc/sys/net/core/rps_sock_flow_entries
> > >
> > > Is there any explanation of what this sysctl actually does? Is this
> > > the max number of sockets/flows that the kernel can steer? Is this a
> > > system wide max, a per interface max, or a per receive queue max?
> > >
> >
> > Yes, some doc is missing...
> >
> > Its a system wide and shared limit.
>
> So the sum of /sys/class/net/*/queues/rx-*/rps_flow_cnt should be less
> than or equal to rps_sock_flow_entries?
No, that is not required.
> > > Next I ran:
> > >
> > > for x in $(seq 0 7); do
> > > echo 16384 > /sys/class/net/vlan816/queues/rx-${x}/rps_flow_cnt
> > > done
> > >
> > > Is this correct? Is these the max number of sockets/flows that can be
> > > steered per receive queue? Does the sum of these values need to add
> > > up to rps_sock_flow_entries (I also tried 2048)? Is this all that is
> > > needed to enable RFS?
> > >
> >
> > Yes thats all.
>
> Same as above... I should be using 2048 if I have 8 queues and have
> set rps_sock_flow_entries to 16384? Out of curiosity what happens
> when you open more sockets than you have rps_flow_cnt?
[...]
There will be a hash collision - multiple flows will hash to the same
value and must therefore be handled on the same processor. (In fact
this is likely to happen long before you fill the table completely.)
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH v2] ethtool : Allow ethtool to set interface in loopback mode.
From: David Lamparter @ 2010-12-03 16:03 UTC (permalink / raw)
To: Mahesh Bandewar; +Cc: Ben Hutchings, linux-netdev, Tom Herbert, David Miller
In-Reply-To: <AANLkTi=GygGKnuSZmWecmGejDjzLx2uaHuk+DroVfHDy@mail.gmail.com>
On Thu, Dec 02, 2010 at 02:35:51PM -0800, Mahesh Bandewar wrote:
> This patch adds -L command-line option to switch loopback mode on/off
> and -l option to display current loopback mode on a specified interface.
[...]
> +.A1 on off
> +Switches loopback mode
> +.B on
> +or
> +.B off
What about devices that support different kinds of loopback, like MAC
loopback & PHY loopback? (No idea if we have kernel support for this
either...)
-David
^ permalink raw reply
* Re: RFS configuration questions
From: Shawn Bohrer @ 2010-12-03 16:00 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, therbert
In-Reply-To: <1291326041.2854.2.camel@edumazet-laptop>
On Thu, Dec 02, 2010 at 10:40:41PM +0100, Eric Dumazet wrote:
> Le jeudi 02 décembre 2010 à 15:16 -0600, Shawn Bohrer a écrit :
> > I've been playing around with RPS/RFS on my multiqueue 10g Chelsio NIC
> > and I've got some questions about configuring RFS.
> >
> > I've enabled RPS with:
> >
> > for x in $(seq 0 7); do
> > echo FFFFFFFF,FFFFFFFF > /sys/class/net/vlan816/queues/rx-${x}/rps_cpus
> > done
> >
> > This appears to work when I watch 'mpstat -P ALL 1' as I can see the
> > softirq load is now getting distributed across all of the CPUs instead
> > of just the four (the card is a two port card and assigns four queues
> > per port) original hw receive queues which I have bound to CPUs
> > 0-3.
> >
> > To enable RFS I've run:
> >
> > echo 16384 > /proc/sys/net/core/rps_sock_flow_entries
> >
> > Is there any explanation of what this sysctl actually does? Is this
> > the max number of sockets/flows that the kernel can steer? Is this a
> > system wide max, a per interface max, or a per receive queue max?
> >
>
> Yes, some doc is missing...
>
> Its a system wide and shared limit.
So the sum of /sys/class/net/*/queues/rx-*/rps_flow_cnt should be less
than or equal to rps_sock_flow_entries?
> > Next I ran:
> >
> > for x in $(seq 0 7); do
> > echo 16384 > /sys/class/net/vlan816/queues/rx-${x}/rps_flow_cnt
> > done
> >
> > Is this correct? Is these the max number of sockets/flows that can be
> > steered per receive queue? Does the sum of these values need to add
> > up to rps_sock_flow_entries (I also tried 2048)? Is this all that is
> > needed to enable RFS?
> >
>
> Yes thats all.
Same as above... I should be using 2048 if I have 8 queues and have
set rps_sock_flow_entries to 16384? Out of curiosity what happens
when you open more sockets than you have rps_flow_cnt?
> > With these settings I can watch 'mpstat -P ALL 1' and it doesn't
> > appear RFS has changed the softirq load. To get a better idea if it
> > was working I used taskset to bind my receiving processes to a set of
> > cores, yet mpstat still shows the softirq load getting distributed
> > across all cores, not just the ones where my receiving processes are
> > bound. Is there a better way to determine if RFS is actually working?
> > Have I configured RFS incorrectly?
>
> It seems fine to me, but what kind of workload do you have, and what
> version of kernel do you run ?
I just did some more testing on 2.6.36.1. Using netperf UDP_STREAM
and TCP_STREAM I was able to see that the softirq load would run on
the CPU where netperf was bound so it appears that RFS is working.
However if I run one of my applications which is a single process
listening to ~30 multicast addresses the softirq load does not run on
the CPU where the application is bound. Does RFS not support
receiving multicast?
--
Shawn
^ permalink raw reply
* Re: [PATCH] net: am79c961a: Omit private ndo_get_stats function
From: Russell King - ARM Linux @ 2010-12-03 15:40 UTC (permalink / raw)
To: Tobias Klauser; +Cc: David S. Miller, netdev
In-Reply-To: <1291310405-5759-1-git-send-email-tklauser@distanz.ch>
On Thu, Dec 02, 2010 at 06:20:05PM +0100, Tobias Klauser wrote:
> am79c961_getstats() just returns dev->stats so we can leave it out
> alltogether and let dev_get_stats() do the job.
>
> Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
> ---
> drivers/net/arm/am79c961a.c | 9 ---------
> 1 files changed, 0 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/net/arm/am79c961a.c b/drivers/net/arm/am79c961a.c
> index 62f2110..0c9217f 100644
> --- a/drivers/net/arm/am79c961a.c
> +++ b/drivers/net/arm/am79c961a.c
> @@ -340,14 +340,6 @@ am79c961_close(struct net_device *dev)
> return 0;
> }
>
> -/*
> - * Get the current statistics.
> - */
> -static struct net_device_stats *am79c961_getstats (struct net_device *dev)
> -{
> - return &dev->stats;
> -}
> -
> static void am79c961_mc_hash(char *addr, unsigned short *hash)
> {
> if (addr[0] & 0x01) {
> @@ -665,7 +657,6 @@ static const struct net_device_ops am79c961_netdev_ops = {
> .ndo_open = am79c961_open,
> .ndo_stop = am79c961_close,
> .ndo_start_xmit = am79c961_sendpacket,
> - .ndo_get_stats = am79c961_getstats,
> .ndo_set_multicast_list = am79c961_setmulticastlist,
> .ndo_tx_timeout = am79c961_timeout,
> .ndo_validate_addr = eth_validate_addr,
> --
> 1.7.0.4
>
^ permalink raw reply
* DONATION!!!
From: W.I.N.S @ 2010-12-03 15:08 UTC (permalink / raw)
Your email was chosen in the EUROPEAN CHARITY DONATION promo award
that was participated December 2nd, and you are to claim the amount
of 1,000,000 USD Please contact Thomas Herman with the following detail Below:
EMAIL: thomasherman7@onfruit.cn
NAME IN FULL:
ADDRESS:
AGE:
NATIONALITY:
OCCUPATION:
PHONE:
SEX:
Joyce Patrick,
Promo Announcer.
^ 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