* Re: [Patch v2] netpoll: warn when there are spaces in parameters
From: Neil Horman @ 2010-03-22 12:30 UTC (permalink / raw)
To: Amerigo Wang; +Cc: linux-kernel, netdev, elendil, David Miller
In-Reply-To: <20100322090341.5289.10770.sendpatchset@localhost.localdomain>
On Mon, Mar 22, 2010 at 04:59:58AM -0400, Amerigo Wang wrote:
> v2: update according to Frans' comments.
>
> Currently, if we leave spaces before dst port,
> netconsole will silently accept it as 0. Warn about this.
>
> Also, when spaces appear in other places, make them
> visible in error messages.
>
> Signed-off-by: WANG Cong <amwang@redhat.com>
> Cc: David Miller <davem@davemloft.net>
>
> ---
>
> diff --git a/net/core/netpoll.c b/net/core/netpoll.c
> index 7aa6972..6df1863 100644
> --- a/net/core/netpoll.c
> +++ b/net/core/netpoll.c
> @@ -614,7 +614,7 @@ void netpoll_print_options(struct netpoll *np)
> np->name, np->local_port);
> printk(KERN_INFO "%s: local IP %pI4\n",
> np->name, &np->local_ip);
> - printk(KERN_INFO "%s: interface %s\n",
> + printk(KERN_INFO "%s: interface '%s'\n",
> np->name, np->dev_name);
> printk(KERN_INFO "%s: remote port %d\n",
> np->name, np->remote_port);
> @@ -661,6 +661,9 @@ int netpoll_parse_options(struct netpoll *np, char *opt)
> if ((delim = strchr(cur, '@')) == NULL)
> goto parse_failed;
> *delim = 0;
> + if (*cur == ' ' || *cur == '\t')
> + printk(KERN_INFO "%s: warning: whitespace"
> + "is not allowed\n", np->name);
> np->remote_port = simple_strtol(cur, NULL, 10);
> cur = delim;
> }
> @@ -708,7 +711,7 @@ int netpoll_parse_options(struct netpoll *np, char *opt)
> return 0;
>
> parse_failed:
> - printk(KERN_INFO "%s: couldn't parse config at %s!\n",
> + printk(KERN_INFO "%s: couldn't parse config at '%s'!\n",
> np->name, cur);
> return -1;
> }
Acked-by: Neil Horman <nhorman@tuxdriver.com>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
^ permalink raw reply
* Re: [net-next-2.6 PATCH] bonding: flush unicast and multicast lists when changing type
From: Jiri Pirko @ 2010-03-22 12:26 UTC (permalink / raw)
To: David Miller; +Cc: netdev, fubar, bonding-devel
In-Reply-To: <20100321.183220.220048937.davem@davemloft.net>
Mon, Mar 22, 2010 at 02:32:20AM CET, davem@davemloft.net wrote:
>From: Jiri Pirko <jpirko@redhat.com>
>Date: Fri, 19 Mar 2010 15:00:23 +0100
>
>> After the type change, addresses in unicast and multicast lists wouldn't make
>> sense, not to mention possible different lenghts. So flush both lists here.
>>
>> Note "dev_addr_discard" will be very soon replaced by "dev_mc_flush" (once
>> mc_list conversion will be done).
>>
>> Signed-off-by: Jiri Pirko <jpirko@redhat.com>
>
>Applied, but maybe these should be EXPORT_SYMBOL_GPL? Just
>asking...
I would keep them EXPORT_SYMBOL as other uc/mc list functions...
^ permalink raw reply
* [patch] korina: use resource_size()
From: Dan Carpenter @ 2010-03-22 12:11 UTC (permalink / raw)
To: netdev
Cc: kernel-janitors, David S. Miller, Phil Sutter, Jiri Pirko,
Stephen Hemminger, Joe Perches
This size calculation is wrong. It should be end - start + 1.
Use resource_size() to calculate it correctly.
Signed-off-by: Dan Carpenter <error27@gmail.com>
---
I don't have a way to test this, or even to compile it. :/
diff --git a/drivers/net/korina.c b/drivers/net/korina.c
index 300c224..edaedc7 100644
--- a/drivers/net/korina.c
+++ b/drivers/net/korina.c
@@ -1135,7 +1135,7 @@ static int korina_probe(struct platform_device *pdev)
r = platform_get_resource_byname(pdev, IORESOURCE_MEM, "korina_regs");
dev->base_addr = r->start;
- lp->eth_regs = ioremap_nocache(r->start, r->end - r->start);
+ lp->eth_regs = ioremap_nocache(r->start, resource_size(r));
if (!lp->eth_regs) {
printk(KERN_ERR DRV_NAME ": cannot remap registers\n");
rc = -ENXIO;
@@ -1143,7 +1143,7 @@ static int korina_probe(struct platform_device *pdev)
}
r = platform_get_resource_byname(pdev, IORESOURCE_MEM, "korina_dma_rx");
- lp->rx_dma_regs = ioremap_nocache(r->start, r->end - r->start);
+ lp->rx_dma_regs = ioremap_nocache(r->start, resource_size(r));
if (!lp->rx_dma_regs) {
printk(KERN_ERR DRV_NAME ": cannot remap Rx DMA registers\n");
rc = -ENXIO;
@@ -1151,7 +1151,7 @@ static int korina_probe(struct platform_device *pdev)
}
r = platform_get_resource_byname(pdev, IORESOURCE_MEM, "korina_dma_tx");
- lp->tx_dma_regs = ioremap_nocache(r->start, r->end - r->start);
+ lp->tx_dma_regs = ioremap_nocache(r->start, resource_size(r));
if (!lp->tx_dma_regs) {
printk(KERN_ERR DRV_NAME ": cannot remap Tx DMA registers\n");
rc = -ENXIO;
^ permalink raw reply related
* [patch] stmmac: use resource_size()
From: Dan Carpenter @ 2010-03-22 12:11 UTC (permalink / raw)
To: netdev
Cc: Giuseppe Cavallaro, Joe Perches, linux-kernel, kernel-janitors,
David S. Miller
The size calculation is not correct. It should be end - start + 1.
Use resource_size() to calculate it instead.
Signed-off-by: Dan Carpenter <error27@gmail.com>
diff --git a/drivers/net/stmmac/stmmac_main.c b/drivers/net/stmmac/stmmac_main.c
index a673361..92bef30 100644
--- a/drivers/net/stmmac/stmmac_main.c
+++ b/drivers/net/stmmac/stmmac_main.c
@@ -1685,8 +1685,7 @@ static int stmmac_dvr_probe(struct platform_device *pdev)
}
pr_info("done!\n");
- if (!request_mem_region(res->start, (res->end - res->start),
- pdev->name)) {
+ if (!request_mem_region(res->start, resource_size(res), pdev->name)) {
pr_err("%s: ERROR: memory allocation failed"
"cannot get the I/O addr 0x%x\n",
__func__, (unsigned int)res->start);
@@ -1694,9 +1693,9 @@ static int stmmac_dvr_probe(struct platform_device *pdev)
goto out;
}
- addr = ioremap(res->start, (res->end - res->start));
+ addr = ioremap(res->start, resource_size(res));
if (!addr) {
- pr_err("%s: ERROR: memory mapping failed \n", __func__);
+ pr_err("%s: ERROR: memory mapping failed\n", __func__);
ret = -ENOMEM;
goto out;
}
@@ -1774,7 +1773,7 @@ static int stmmac_dvr_probe(struct platform_device *pdev)
out:
if (ret < 0) {
platform_set_drvdata(pdev, NULL);
- release_mem_region(res->start, (res->end - res->start));
+ release_mem_region(res->start, resource_size(res));
if (addr != NULL)
iounmap(addr);
}
@@ -1812,7 +1811,7 @@ static int stmmac_dvr_remove(struct platform_device *pdev)
iounmap((void *)ndev->base_addr);
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- release_mem_region(res->start, (res->end - res->start));
+ release_mem_region(res->start, resource_size(res));
free_netdev(ndev);
^ permalink raw reply related
* [patch] ewrk3: range checking problem
From: Dan Carpenter @ 2010-03-22 12:07 UTC (permalink / raw)
To: netdev
Cc: Stephen Hemminger, Patrick McHardy, Jiri Pirko, Alexey Dobriyan,
linux-kernel, kernel-janitors, David S. Miller
The range checking here is wrong. It should be HASH_TABLE_LEN which
is 512.
Signed-off-by: Dan Carpenter <error27@gmail.com>
diff --git a/drivers/net/ewrk3.c b/drivers/net/ewrk3.c
index 91e59f3..ae02de1 100644
--- a/drivers/net/ewrk3.c
+++ b/drivers/net/ewrk3.c
@@ -1776,8 +1776,7 @@ static int ewrk3_ioctl(struct net_device *dev, struct ifreq *rq, int cmd)
break;
case EWRK3_SET_MCA: /* Set a multicast address */
if (capable(CAP_NET_ADMIN)) {
- if (ioc->len > 1024)
- {
+ if (ioc->len > HASH_TABLE_LEN) {
status = -EINVAL;
break;
}
^ permalink raw reply related
* 8021p to dscp remarking
From: Smital Desai @ 2010-03-22 11:54 UTC (permalink / raw)
To: netdev@vger.kernel.org
Hello
Is it possible to support 8021p -> Dscp remarking in kernel for the routers that
are not supporting such kind of remarking mechanism at hardware level ?
Any such support available in latest kernel ?
Any help / suggestions will be appreciated .
Thanks,
Smital Desai
This Email may contain confidential or privileged information for the intended recipient (s) If you are not the intended recipient, please do not use or disseminate the information, notify the sender and delete it from your system.
______________________________________________________________________
^ permalink raw reply
* Re: Performance hit with IP-tunnels
From: Eric Dumazet @ 2010-03-22 11:06 UTC (permalink / raw)
To: Kristian Evensen; +Cc: netdev, linux-ppp
In-Reply-To: <000301cac9a8$dcd53750$967fa5f0$@no>
Le lundi 22 mars 2010 à 11:17 +0100, Kristian Evensen a écrit :
> Hello,
>
> I am currently comparing different IP-tunneling protocols/implementations,
> and have stumbled upon something I am not able to explain. Regardless of
> which tunneling technology I use, the latency increases with a couple of 10s
> of ms and I see a significant degradation of throughput (compared to when no
> tunnels are used). The only exception is IP-in-IP, where I get similar
> performance with and without tunnels, but it does unfortunately not work in
> my scenario.
>
> First, I thought this was caused by the different tunneling software, but
> after measuring the processing time of the applications (xl2tp and
> pptp-client) and when the packets are seen by the different iptables chains
> (using LOG), these delays seem to be acceptable. However, one delay sticks
> out. After the packet has been decapsulated and fed to PPP, it takes a
> "long" time before it is seen again. My question is, can PPP be the cause of
> the higher latency and lower throughput?
>
> Similar observations are made at both ends of the tunnel.
A soon as a round trip on a user process is requested to handle a
packet, you can have delay because of scheduling constraints.
You could try latencytop and check if something strange raises, 10 ms
seems excessive.
IP-TIP tunnels dont use a user space program, they are immune to
scheduler latencies.
^ permalink raw reply
* tc download always to "default"
From: Mihamina Rakotomandimby @ 2010-03-22 10:44 UTC (permalink / raw)
To: netdev
Manao ahoana, Hello, Bonjour,
This is my simple topology:
LAN <--> (eth1)[gateway](eth2) <--> Internet
The gataway NATs (Masquerade) but there is no trouble about this.
I would like to limit the DOWNLOAD bandwidth per host.
Download is:
Internet -> gateway -> eth1 -> LAN Host
LAN is 10.150.0.128/25
There are sample lines of my "tc" ruleset:
http://pastebin.org/119806
My problem is all the traffic is caught by "classid 1:10", the default
class.
Nothing is trapped by "classid 1:301" -> "classid 1:426"
At a first glance, would you see something wrong in these?
Misaotra, Thanks, Merci.
--
Architecte Informatique chez Blueline/Gulfsat:
Administration Systeme, Recherche & Developpement
+261 34 29 155 34 / +261 33 11 207 36
^ permalink raw reply
* Performance hit with IP-tunnels
From: Kristian Evensen @ 2010-03-22 10:17 UTC (permalink / raw)
To: netdev, linux-ppp
Hello,
I am currently comparing different IP-tunneling protocols/implementations,
and have stumbled upon something I am not able to explain. Regardless of
which tunneling technology I use, the latency increases with a couple of 10s
of ms and I see a significant degradation of throughput (compared to when no
tunnels are used). The only exception is IP-in-IP, where I get similar
performance with and without tunnels, but it does unfortunately not work in
my scenario.
First, I thought this was caused by the different tunneling software, but
after measuring the processing time of the applications (xl2tp and
pptp-client) and when the packets are seen by the different iptables chains
(using LOG), these delays seem to be acceptable. However, one delay sticks
out. After the packet has been decapsulated and fed to PPP, it takes a
"long" time before it is seen again. My question is, can PPP be the cause of
the higher latency and lower throughput?
Similar observations are made at both ends of the tunnel.
Thanks in advance for any help,
Kristian
^ permalink raw reply
* [Patch] netconsole: do not depend on experimental
From: Amerigo Wang @ 2010-03-22 9:59 UTC (permalink / raw)
To: linux-kernel; +Cc: netdev, Amerigo Wang, David Miller
Nowadays, most distributions enable netconsole by default,
including RHEL, Fedora, Debian, Arch, Opensuse. And
we don't have any bug reports about it. So I think there
is no need to mark it as experimental any more.
Cc: David S. Miller <davem@davemloft.net>
Signed-off-by: WANG Cong <amwang@redhat.com>
---
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 0ba5b8e..e3d6c52 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -3252,15 +3252,14 @@ config NET_FC
"SCSI generic support".
config NETCONSOLE
- tristate "Network console logging support (EXPERIMENTAL)"
- depends on EXPERIMENTAL
+ tristate "Network console logging support"
---help---
If you want to log kernel messages over the network, enable this.
See <file:Documentation/networking/netconsole.txt> for details.
config NETCONSOLE_DYNAMIC
- bool "Dynamic reconfiguration of logging targets (EXPERIMENTAL)"
- depends on NETCONSOLE && SYSFS && EXPERIMENTAL
+ bool "Dynamic reconfiguration of logging targets"
+ depends on NETCONSOLE && SYSFS
select CONFIGFS_FS
help
This option enables the ability to dynamically reconfigure target
^ permalink raw reply related
* -next Mar 22: s390 build failure (drivers/s390/net/qeth_l3)
From: Sachin Sant @ 2010-03-22 9:10 UTC (permalink / raw)
To: linux-s390
Cc: linux-next, netdev, ursula.braun, Stephen Hemminger,
Heiko Carstens
In-Reply-To: <20100322171937.d753bdba.sfr@canb.auug.org.au>
Todays next fails to build on a s390 box with
CC [M] drivers/s390/net/qeth_l3_main.o
drivers/s390/net/qeth_l3_main.c: In function 'qeth_l3_free_vlan_addresses6':
drivers/s390/net/qeth_l3_main.c:1931: error: incompatible types in assignment
drivers/s390/net/qeth_l3_main.c:1931: error: 'struct inet6_ifaddr' has no member named 'lst_next'
make[2]: *** [drivers/s390/net/qeth_l3_main.o] Error 1
commit c2e21293c054817c42eb5fa9c613d2ad51954136
(ipv6: convert addrconf list to hlist)
converted lst_next member of inet6_ifaddr struct to a hlist.
Thanks
-Sachin
--
---------------------------------
Sachin Sant
IBM Linux Technology Center
India Systems and Technology Labs
Bangalore, India
---------------------------------
^ permalink raw reply
* [Patch v2] netpoll: warn when there are spaces in parameters
From: Amerigo Wang @ 2010-03-22 8:59 UTC (permalink / raw)
To: linux-kernel; +Cc: netdev, elendil, Amerigo Wang, David Miller
v2: update according to Frans' comments.
Currently, if we leave spaces before dst port,
netconsole will silently accept it as 0. Warn about this.
Also, when spaces appear in other places, make them
visible in error messages.
Signed-off-by: WANG Cong <amwang@redhat.com>
Cc: David Miller <davem@davemloft.net>
---
diff --git a/net/core/netpoll.c b/net/core/netpoll.c
index 7aa6972..6df1863 100644
--- a/net/core/netpoll.c
+++ b/net/core/netpoll.c
@@ -614,7 +614,7 @@ void netpoll_print_options(struct netpoll *np)
np->name, np->local_port);
printk(KERN_INFO "%s: local IP %pI4\n",
np->name, &np->local_ip);
- printk(KERN_INFO "%s: interface %s\n",
+ printk(KERN_INFO "%s: interface '%s'\n",
np->name, np->dev_name);
printk(KERN_INFO "%s: remote port %d\n",
np->name, np->remote_port);
@@ -661,6 +661,9 @@ int netpoll_parse_options(struct netpoll *np, char *opt)
if ((delim = strchr(cur, '@')) == NULL)
goto parse_failed;
*delim = 0;
+ if (*cur == ' ' || *cur == '\t')
+ printk(KERN_INFO "%s: warning: whitespace"
+ "is not allowed\n", np->name);
np->remote_port = simple_strtol(cur, NULL, 10);
cur = delim;
}
@@ -708,7 +711,7 @@ int netpoll_parse_options(struct netpoll *np, char *opt)
return 0;
parse_failed:
- printk(KERN_INFO "%s: couldn't parse config at %s!\n",
+ printk(KERN_INFO "%s: couldn't parse config at '%s'!\n",
np->name, cur);
return -1;
}
^ permalink raw reply related
* [RFC Patch 3/3] bonding: make bonding support netpoll
From: Amerigo Wang @ 2010-03-22 8:17 UTC (permalink / raw)
To: linux-kernel
Cc: netdev, bridge, Andy Gospodarek, Neil Horman, Amerigo Wang,
Stephen Hemminger, bonding-devel, Jay Vosburgh, David Miller
In-Reply-To: <20100322082059.4967.63492.sendpatchset@localhost.localdomain>
Based on Andy's work, but I modify a lot.
Similar to the patch for bridge, this patch does:
1) implement the 4 methods to support netpoll for bonding;
2) modify netpoll during forwarding packets in bonding;
3) disable netpoll support of bridge when a netpoll-unabled device
is added to bonding;
4) enable netpoll support when all underlying devices support netpoll.
Cc: Andy Gospodarek <gospo@redhat.com>
Cc: Neil Horman <nhorman@tuxdriver.com>
Cc: Jay Vosburgh <fubar@us.ibm.com>
Cc: David Miller <davem@davemloft.net>
Signed-off-by: WANG Cong <amwang@redhat.com>
---
Index: linux-2.6/drivers/net/bonding/bond_main.c
===================================================================
--- linux-2.6.orig/drivers/net/bonding/bond_main.c
+++ linux-2.6/drivers/net/bonding/bond_main.c
@@ -59,6 +59,7 @@
#include <linux/uaccess.h>
#include <linux/errno.h>
#include <linux/netdevice.h>
+#include <linux/netpoll.h>
#include <linux/inetdevice.h>
#include <linux/igmp.h>
#include <linux/etherdevice.h>
@@ -430,7 +431,17 @@ int bond_dev_queue_xmit(struct bonding *
}
skb->priority = 1;
- dev_queue_xmit(skb);
+#ifdef CONFIG_NET_POLL_CONTROLLER
+ if (bond->dev->priv_flags & IFF_IN_NETPOLL) {
+ bond->dev->npinfo->netpoll->dev = skb->dev;
+ if (!slave_dev->npinfo)
+ slave_dev->npinfo = bond->dev->npinfo;
+ slave_dev->priv_flags |= IFF_IN_NETPOLL;
+ netpoll_send_skb(bond->dev->npinfo->netpoll, skb);
+ slave_dev->priv_flags &= ~IFF_IN_NETPOLL;
+ } else
+#endif
+ dev_queue_xmit(skb);
return 0;
}
@@ -1324,6 +1335,87 @@ static void bond_detach_slave(struct bon
bond->slave_cnt--;
}
+#ifdef CONFIG_NET_POLL_CONTROLLER
+static bool slaves_support_netpoll(struct net_device *bond_dev)
+{
+ struct bonding *bond = netdev_priv(bond_dev);
+ struct slave *slave;
+ int i = 0;
+ bool ret = true;
+
+ read_lock_bh(&bond->lock);
+ bond_for_each_slave(bond, slave, i) {
+ if ((slave->dev->priv_flags & IFF_DISABLE_NETPOLL)
+ || !slave->dev->netdev_ops->ndo_poll_controller)
+ ret = false;
+ }
+ read_unlock_bh(&bond->lock);
+ return i != 0 && ret;
+}
+
+static void bond_poll_controller(struct net_device *bond_dev)
+{
+ struct bonding *bond = netdev_priv(bond_dev);
+ struct slave *slave;
+ int i;
+
+ read_lock(&bond->lock);
+ bond_for_each_slave(bond, slave, i) {
+ if (slave->dev->netdev_ops->ndo_poll_controller)
+ netpoll_poll_dev(slave->dev);
+ }
+ read_unlock(&bond->lock);
+}
+
+static void bond_netpoll_setup(struct net_device *bond_dev,
+ struct netpoll_info *npinfo)
+{
+ struct bonding *bond = netdev_priv(bond_dev);
+ struct slave *slave;
+ int i;
+
+ write_lock_bh(&bond->lock);
+ bond_for_each_slave(bond, slave, i) {
+ if (slave->dev)
+ slave->dev->npinfo = npinfo;
+ }
+ write_unlock_bh(&bond->lock);
+}
+
+static void bond_netpoll_cleanup(struct net_device *bond_dev)
+{
+ struct bonding *bond = netdev_priv(bond_dev);
+ struct slave *slave;
+ const struct net_device_ops *ops;
+ int i;
+
+ write_lock_bh(&bond->lock);
+ bond_dev->npinfo = NULL;
+ bond_for_each_slave(bond, slave, i) {
+ if (slave->dev) {
+ ops = slave->dev->netdev_ops;
+ if (ops->ndo_netpoll_cleanup)
+ ops->ndo_netpoll_cleanup(slave->dev);
+ else
+ slave->dev->npinfo = NULL;
+ }
+ }
+ write_unlock_bh(&bond->lock);
+}
+
+static int bond_netpoll_xmit(struct netpoll *np, struct sk_buff *skb,
+ struct net_device *dev)
+{
+ int ret;
+
+ dev->priv_flags |= IFF_IN_NETPOLL;
+ ret = dev->netdev_ops->ndo_start_xmit(skb, dev);
+ np->dev = dev;
+ dev->priv_flags &= ~IFF_IN_NETPOLL;
+ return ret;
+}
+#endif
+
/*---------------------------------- IOCTL ----------------------------------*/
static int bond_sethwaddr(struct net_device *bond_dev,
@@ -1741,6 +1833,18 @@ int bond_enslave(struct net_device *bond
new_slave->state == BOND_STATE_ACTIVE ? "n active" : " backup",
new_slave->link != BOND_LINK_DOWN ? "n up" : " down");
+#ifdef CONFIG_NET_POLL_CONTROLLER
+ if (slaves_support_netpoll(bond_dev)) {
+ bond_dev->priv_flags &= ~IFF_DISABLE_NETPOLL;
+ if (bond_dev->npinfo)
+ slave_dev->npinfo = bond_dev->npinfo;
+ } else if (!(bond_dev->priv_flags & IFF_DISABLE_NETPOLL)) {
+ bond_dev->priv_flags |= IFF_DISABLE_NETPOLL;
+ pr_info("New slave device %s does not support netpoll\n",
+ slave_dev->name);
+ pr_info("Disabling netpoll support for %s\n", bond_dev->name);
+ }
+#endif
/* enslave is successful */
return 0;
@@ -1924,6 +2028,15 @@ int bond_release(struct net_device *bond
netdev_set_master(slave_dev, NULL);
+#ifdef CONFIG_NET_POLL_CONTROLLER
+ if (slaves_support_netpoll(bond_dev))
+ bond_dev->priv_flags &= ~IFF_DISABLE_NETPOLL;
+ if (slave_dev->netdev_ops->ndo_netpoll_cleanup)
+ slave_dev->netdev_ops->ndo_netpoll_cleanup(slave_dev);
+ else
+ slave_dev->npinfo = NULL;
+#endif
+
/* close slave before restoring its mac address */
dev_close(slave_dev);
@@ -2032,6 +2145,9 @@ static int bond_release_all(struct net_d
netdev_set_master(slave_dev, NULL);
+#ifdef CONFIG_NET_POLL_CONTROLLER
+ slave_dev->npinfo = NULL;
+#endif
/* close slave before restoring its mac address */
dev_close(slave_dev);
@@ -4424,6 +4540,12 @@ static const struct net_device_ops bond_
.ndo_vlan_rx_register = bond_vlan_rx_register,
.ndo_vlan_rx_add_vid = bond_vlan_rx_add_vid,
.ndo_vlan_rx_kill_vid = bond_vlan_rx_kill_vid,
+#ifdef CONFIG_NET_POLL_CONTROLLER
+ .ndo_netpoll_setup = bond_netpoll_setup,
+ .ndo_netpoll_xmit = bond_netpoll_xmit,
+ .ndo_netpoll_cleanup = bond_netpoll_cleanup,
+ .ndo_poll_controller = bond_poll_controller,
+#endif
};
static void bond_setup(struct net_device *bond_dev)
^ permalink raw reply
* [RFC Patch 2/3] bridge: make bridge support netpoll
From: Amerigo Wang @ 2010-03-22 8:17 UTC (permalink / raw)
To: linux-kernel
Cc: netdev, bridge, Andy Gospodarek, Neil Horman, Amerigo Wang,
Stephen Hemminger, bonding-devel, Jay Vosburgh, David Miller
In-Reply-To: <20100322082059.4967.63492.sendpatchset@localhost.localdomain>
Based on the previous patch, make bridge support netpoll by:
1) implement the 4 methods to support netpoll for bridge;
2) modify netpoll during forwarding packets in bridge;
3) disable netpoll support of bridge when a netpoll-unabled device
is added to bridge;
4) enable netpoll support when all underlying devices support netpoll.
Cc: David Miller <davem@davemloft.net>
Cc: Neil Horman <nhorman@tuxdriver.com>
Cc: Stephen Hemminger <shemminger@linux-foundation.org>
Signed-off-by: WANG Cong <amwang@redhat.com>
---
Index: linux-2.6/net/bridge/br_device.c
===================================================================
--- linux-2.6.orig/net/bridge/br_device.c
+++ linux-2.6/net/bridge/br_device.c
@@ -13,6 +13,7 @@
#include <linux/kernel.h>
#include <linux/netdevice.h>
+#include <linux/netpoll.h>
#include <linux/etherdevice.h>
#include <linux/ethtool.h>
@@ -162,6 +163,87 @@ static int br_set_tx_csum(struct net_dev
return 0;
}
+#ifdef CONFIG_NET_POLL_CONTROLLER
+bool br_devices_support_netpoll(struct net_bridge *br)
+{
+ struct net_bridge_port *p;
+ bool ret = true;
+ int count = 0;
+ unsigned long flags;
+
+ spin_lock_irqsave(&br->lock, flags);
+ list_for_each_entry(p, &br->port_list, list) {
+ count++;
+ if (p->dev->priv_flags & IFF_DISABLE_NETPOLL
+ || !p->dev->netdev_ops->ndo_poll_controller)
+ ret = false;
+ }
+ spin_unlock_irqrestore(&br->lock, flags);
+ return count != 0 && ret;
+}
+
+static void br_poll_controller(struct net_device *br_dev)
+{
+ struct net_bridge *br = netdev_priv(br_dev);
+ struct net_bridge_port *p;
+ unsigned long flags;
+
+ spin_lock_irqsave(&br->lock, flags);
+ list_for_each_entry(p, &br->port_list, list) {
+ if (p->dev->netdev_ops->ndo_poll_controller)
+ netpoll_poll_dev(p->dev);
+ }
+ spin_unlock_irqrestore(&br->lock, flags);
+}
+
+static void br_netpoll_setup(struct net_device *br_dev, struct netpoll_info *npinfo)
+{
+ struct net_bridge *br = netdev_priv(br_dev);
+ struct net_bridge_port *p;
+ unsigned long flags;
+
+ spin_lock_irqsave(&br->lock, flags);
+ list_for_each_entry(p, &br->port_list, list) {
+ if (p->dev)
+ p->dev->npinfo = npinfo;
+ }
+ spin_unlock_irqrestore(&br->lock, flags);
+}
+
+static void br_netpoll_cleanup(struct net_device *br_dev)
+{
+ struct net_bridge *br = netdev_priv(br_dev);
+ struct net_bridge_port *p;
+ const struct net_device_ops *ops;
+ unsigned long flags;
+
+ spin_lock_irqsave(&br->lock, flags);
+ br->dev->npinfo = NULL;
+ list_for_each_entry(p, &br->port_list, list) {
+ if (p->dev) {
+ ops = p->dev->netdev_ops;
+ if (ops->ndo_netpoll_cleanup)
+ ops->ndo_netpoll_cleanup(p->dev);
+ else
+ p->dev->npinfo = NULL;
+ }
+ }
+ spin_unlock_irqrestore(&br->lock, flags);
+}
+
+static int br_netpoll_xmit(struct netpoll *np, struct sk_buff *skb, struct net_device *dev)
+{
+ int ret;
+
+ dev->priv_flags |= IFF_IN_NETPOLL;
+ ret = dev->netdev_ops->ndo_start_xmit(skb, dev);
+ np->dev = dev;
+ dev->priv_flags &= ~IFF_IN_NETPOLL;
+ return ret;
+}
+
+#endif
+
static const struct ethtool_ops br_ethtool_ops = {
.get_drvinfo = br_getinfo,
.get_link = ethtool_op_get_link,
@@ -184,6 +266,12 @@ static const struct net_device_ops br_ne
.ndo_set_multicast_list = br_dev_set_multicast_list,
.ndo_change_mtu = br_change_mtu,
.ndo_do_ioctl = br_dev_ioctl,
+#ifdef CONFIG_NET_POLL_CONTROLLER
+ .ndo_netpoll_setup = br_netpoll_setup,
+ .ndo_netpoll_xmit = br_netpoll_xmit,
+ .ndo_netpoll_cleanup = br_netpoll_cleanup,
+ .ndo_poll_controller = br_poll_controller,
+#endif
};
void br_dev_setup(struct net_device *dev)
Index: linux-2.6/net/bridge/br_forward.c
===================================================================
--- linux-2.6.orig/net/bridge/br_forward.c
+++ linux-2.6/net/bridge/br_forward.c
@@ -14,6 +14,7 @@
#include <linux/err.h>
#include <linux/kernel.h>
#include <linux/netdevice.h>
+#include <linux/netpoll.h>
#include <linux/skbuff.h>
#include <linux/if_vlan.h>
#include <linux/netfilter_bridge.h>
@@ -44,7 +45,13 @@ int br_dev_queue_push_xmit(struct sk_buf
else {
skb_push(skb, ETH_HLEN);
- dev_queue_xmit(skb);
+#ifdef CONFIG_NET_POLL_CONTROLLER
+ if (skb->dev->priv_flags & IFF_IN_NETPOLL) {
+ netpoll_send_skb(skb->dev->npinfo->netpoll, skb);
+ skb->dev->priv_flags &= ~IFF_IN_NETPOLL;
+ } else
+#endif
+ dev_queue_xmit(skb);
}
}
@@ -60,6 +67,16 @@ int br_forward_finish(struct sk_buff *sk
static void __br_deliver(const struct net_bridge_port *to, struct sk_buff *skb)
{
+#ifdef CONFIG_NET_POLL_CONTROLLER
+ struct net_bridge *br = to->br;
+ if (br->dev->priv_flags & IFF_IN_NETPOLL) {
+ skb->dev->npinfo->netpoll->dev = to->dev;
+ if (!to->dev->npinfo)
+ to->dev->npinfo = skb->dev->npinfo;
+
+ to->dev->priv_flags |= IFF_IN_NETPOLL;
+ }
+#endif
skb->dev = to->dev;
NF_HOOK(PF_BRIDGE, NF_BR_LOCAL_OUT, skb, NULL, skb->dev,
br_forward_finish);
Index: linux-2.6/net/bridge/br_if.c
===================================================================
--- linux-2.6.orig/net/bridge/br_if.c
+++ linux-2.6/net/bridge/br_if.c
@@ -19,6 +19,7 @@
#include <linux/init.h>
#include <linux/rtnetlink.h>
#include <linux/if_ether.h>
+#include <linux/netpoll.h>
#include <net/sock.h>
#include "br_private.h"
@@ -152,6 +153,14 @@ static void del_nbp(struct net_bridge_po
kobject_uevent(&p->kobj, KOBJ_REMOVE);
kobject_del(&p->kobj);
+#ifdef CONFIG_NET_POLL_CONTROLLER
+ if (br_devices_support_netpoll(br))
+ br->dev->priv_flags &= ~IFF_DISABLE_NETPOLL;
+ if (br->dev->netdev_ops->ndo_netpoll_cleanup)
+ br->dev->netdev_ops->ndo_netpoll_cleanup(br->dev);
+ else
+ dev->npinfo = NULL;
+#endif
call_rcu(&p->rcu, destroy_nbp_rcu);
}
@@ -437,6 +446,20 @@ int br_add_if(struct net_bridge *br, str
kobject_uevent(&p->kobj, KOBJ_ADD);
+#ifdef CONFIG_NET_POLL_CONTROLLER
+ if (br_devices_support_netpoll(br)) {
+ br->dev->priv_flags &= ~IFF_DISABLE_NETPOLL;
+ if (br->dev->npinfo)
+ dev->npinfo = br->dev->npinfo;
+ } else if (!(br->dev->priv_flags & IFF_DISABLE_NETPOLL)) {
+ br->dev->priv_flags |= IFF_DISABLE_NETPOLL;
+ printk(KERN_INFO "New device %s does not support netpoll\n",
+ dev->name);
+ printk(KERN_INFO "Disabling netpoll for %s\n",
+ br->dev->name);
+ }
+#endif
+
return 0;
err2:
br_fdb_delete_by_port(br, p, 1);
Index: linux-2.6/net/bridge/br_private.h
===================================================================
--- linux-2.6.orig/net/bridge/br_private.h
+++ linux-2.6/net/bridge/br_private.h
@@ -225,6 +225,7 @@ static inline int br_is_root_bridge(cons
extern void br_dev_setup(struct net_device *dev);
extern netdev_tx_t br_dev_xmit(struct sk_buff *skb,
struct net_device *dev);
+extern bool br_devices_support_netpoll(struct net_bridge *br);
/* br_fdb.c */
extern int br_fdb_init(void);
^ permalink raw reply
* [RFC Patch 1/3] netpoll: add generic support for bridge and bonding devices
From: Amerigo Wang @ 2010-03-22 8:17 UTC (permalink / raw)
To: linux-kernel
Cc: netdev, bridge, Andy Gospodarek, Neil Horman, Amerigo Wang,
Stephen Hemminger, bonding-devel, Jay Vosburgh, David Miller
This whole patchset is for adding netpoll support to bridge and bonding
devices. I already tested it for bridge, bonding, bridge over bonding,
and bonding over bridge. It looks fine now.
Please comment.
To make bridge and bonding support netpoll, we need to adjust
some netpoll generic code. This patch does the following things:
1) introduce two new priv_flags for struct net_device:
IFF_IN_NETPOLL which identifies we are processing a netpoll;
IFF_DISABLE_NETPOLL is used to disable netpoll support for a device
at run-time;
2) introduce three new methods for netdev_ops:
->ndo_netpoll_setup() is used to setup netpoll for a device;
->ndo_netpoll_xmit() is used to transmit netpoll requests;
->ndo_netpoll_cleanup() is used to clean up netpoll when a device is
removed.
3) introduce netpoll_poll_dev() which takes a struct net_device * parameter;
4) export netpoll_send_skb() and netpoll_poll_dev() which will be used later;
5) hide a pointer to struct netpoll in struct netpoll_info, ditto.
Cc: David Miller <davem@davemloft.net>
Cc: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: WANG Cong <amwang@redhat.com>
---
Index: linux-2.6/include/linux/if.h
===================================================================
--- linux-2.6.orig/include/linux/if.h
+++ linux-2.6/include/linux/if.h
@@ -71,6 +71,8 @@
* release skb->dst
*/
#define IFF_DONT_BRIDGE 0x800 /* disallow bridging this ether dev */
+#define IFF_IN_NETPOLL 0x1000 /* whether we are processing netpoll */
+#define IFF_DISABLE_NETPOLL 0x2000 /* disable netpoll at run-time */
#define IF_GET_IFACE 0x0001 /* for querying only */
#define IF_GET_PROTO 0x0002
Index: linux-2.6/include/linux/netdevice.h
===================================================================
--- linux-2.6.orig/include/linux/netdevice.h
+++ linux-2.6/include/linux/netdevice.h
@@ -530,6 +530,8 @@ struct netdev_queue {
unsigned long tx_dropped;
} ____cacheline_aligned_in_smp;
+struct netpoll;
+struct netpoll_info;
/*
* This structure defines the management hooks for network devices.
@@ -667,6 +669,12 @@ struct net_device_ops {
unsigned short vid);
#ifdef CONFIG_NET_POLL_CONTROLLER
void (*ndo_poll_controller)(struct net_device *dev);
+ void (*ndo_netpoll_setup)(struct net_device *dev,
+ struct netpoll_info *npinfo);
+ int (*ndo_netpoll_xmit)(struct netpoll *np,
+ struct sk_buff *skb,
+ struct net_device *dev);
+ void (*ndo_netpoll_cleanup)(struct net_device *dev);
#endif
int (*ndo_set_vf_mac)(struct net_device *dev,
int queue, u8 *mac);
Index: linux-2.6/include/linux/netpoll.h
===================================================================
--- linux-2.6.orig/include/linux/netpoll.h
+++ linux-2.6/include/linux/netpoll.h
@@ -36,8 +36,11 @@ struct netpoll_info {
struct sk_buff_head txq;
struct delayed_work tx_work;
+
+ struct netpoll *netpoll;
};
+void netpoll_poll_dev(struct net_device *dev);
void netpoll_poll(struct netpoll *np);
void netpoll_send_udp(struct netpoll *np, const char *msg, int len);
void netpoll_print_options(struct netpoll *np);
@@ -47,6 +50,7 @@ int netpoll_trap(void);
void netpoll_set_trap(int trap);
void netpoll_cleanup(struct netpoll *np);
int __netpoll_rx(struct sk_buff *skb);
+void netpoll_send_skb(struct netpoll *np, struct sk_buff *skb);
#ifdef CONFIG_NETPOLL
Index: linux-2.6/net/core/netpoll.c
===================================================================
--- linux-2.6.orig/net/core/netpoll.c
+++ linux-2.6/net/core/netpoll.c
@@ -178,9 +178,8 @@ static void service_arp_queue(struct net
}
}
-void netpoll_poll(struct netpoll *np)
+void netpoll_poll_dev(struct net_device *dev)
{
- struct net_device *dev = np->dev;
const struct net_device_ops *ops;
if (!dev || !netif_running(dev))
@@ -200,6 +199,13 @@ void netpoll_poll(struct netpoll *np)
zap_completion_queue();
}
+void netpoll_poll(struct netpoll *np)
+{
+ if (!np->dev)
+ return;
+ netpoll_poll_dev(np->dev);
+}
+
static void refill_skbs(void)
{
struct sk_buff *skb;
@@ -281,7 +287,7 @@ static int netpoll_owner_active(struct n
return 0;
}
-static void netpoll_send_skb(struct netpoll *np, struct sk_buff *skb)
+void netpoll_send_skb(struct netpoll *np, struct sk_buff *skb)
{
int status = NETDEV_TX_BUSY;
unsigned long tries;
@@ -307,7 +313,10 @@ static void netpoll_send_skb(struct netp
tries > 0; --tries) {
if (__netif_tx_trylock(txq)) {
if (!netif_tx_queue_stopped(txq)) {
- status = ops->ndo_start_xmit(skb, dev);
+ if (ops->ndo_netpoll_xmit)
+ status = ops->ndo_netpoll_xmit(np, skb, dev);
+ else
+ status = ops->ndo_start_xmit(skb, dev);
if (status == NETDEV_TX_OK)
txq_trans_update(txq);
}
@@ -752,7 +761,10 @@ int netpoll_setup(struct netpoll *np)
atomic_inc(&npinfo->refcnt);
}
- if (!ndev->netdev_ops->ndo_poll_controller) {
+ npinfo->netpoll = np;
+
+ if (ndev->priv_flags & IFF_DISABLE_NETPOLL
+ || !ndev->netdev_ops->ndo_poll_controller) {
printk(KERN_ERR "%s: %s doesn't support polling, aborting.\n",
np->name, np->dev_name);
err = -ENOTSUPP;
@@ -830,6 +842,9 @@ int netpoll_setup(struct netpoll *np)
/* last thing to do is link it to the net device structure */
ndev->npinfo = npinfo;
+ if (ndev->netdev_ops->ndo_netpoll_setup)
+ ndev->netdev_ops->ndo_netpoll_setup(ndev, npinfo);
+
/* avoid racing with NAPI reading npinfo */
synchronize_rcu();
@@ -904,6 +919,7 @@ void netpoll_set_trap(int trap)
atomic_dec(&trapped);
}
+EXPORT_SYMBOL(netpoll_send_skb);
EXPORT_SYMBOL(netpoll_set_trap);
EXPORT_SYMBOL(netpoll_trap);
EXPORT_SYMBOL(netpoll_print_options);
@@ -911,4 +927,5 @@ EXPORT_SYMBOL(netpoll_parse_options);
EXPORT_SYMBOL(netpoll_setup);
EXPORT_SYMBOL(netpoll_cleanup);
EXPORT_SYMBOL(netpoll_send_udp);
+EXPORT_SYMBOL(netpoll_poll_dev);
EXPORT_SYMBOL(netpoll_poll);
^ permalink raw reply
* Re: why does there need to lock?
From: Eric Dumazet @ 2010-03-22 8:05 UTC (permalink / raw)
To: 杨硕; +Cc: netdev
In-Reply-To: <ffe582101003211741v59da3c56yaffdaa151a6821be@mail.gmail.com>
Le lundi 22 mars 2010 à 08:41 +0800, 杨硕 a écrit :
> Hi, i'm confused about why does "rcu_assign_pointer(dev->ip_ptr,
> in_dev);" need to rcu lock?
>
I am confused by your question
rcu_assign_pointer doesnt need rcu lock.
It only makes sure all previous memory changes are committed to memory
before the "dev->ip_ptr = in_dev;" assignement, so that concurrent
readers cannot find the new pointer and read previous values of
dev->ip_ptr->fields
> TIA :)
>
> static struct in_device *inetdev_init(struct net_device *dev)
> {
> struct in_device *in_dev;
>
> ASSERT_RTNL();
>
> in_dev = kzalloc(sizeof(*in_dev), GFP_KERNEL);
> if (!in_dev)
> goto out;
> memcpy(&in_dev->cnf, dev_net(dev)->ipv4.devconf_dflt,
> sizeof(in_dev->cnf));
> in_dev->cnf.sysctl = NULL;
> in_dev->dev = dev;
> if ((in_dev->arp_parms = neigh_parms_alloc(dev, &arp_tbl)) == NULL)
> goto out_kfree;
> if (IPV4_DEVCONF(in_dev->cnf, FORWARDING))
> dev_disable_lro(dev);
> /* Reference in_dev->dev */
> dev_hold(dev);
> /* Account for reference dev->ip_ptr (below) */
> in_dev_hold(in_dev);
>
> devinet_sysctl_register(in_dev);
> ip_mc_init_dev(in_dev);
> if (dev->flags & IFF_UP)
> ip_mc_up(in_dev);
>
> /* we can receive as soon as ip_ptr is set -- do this last */
> rcu_assign_pointer(dev->ip_ptr, in_dev);
> out:
> return in_dev;
> out_kfree:
> kfree(in_dev);
> in_dev = NULL;
> goto out;
> }
^ permalink raw reply
* Re: [PATCH] pktgen node allocation
From: Eric Dumazet @ 2010-03-22 7:43 UTC (permalink / raw)
To: Robert Olsson; +Cc: David Miller, netdev, olofh
In-Reply-To: <19367.3346.643084.604021@gargle.gargle.HOWL>
Le lundi 22 mars 2010 à 07:24 +0100, Robert Olsson a écrit :
> Eric Dumazet writes:
>
> > Well, you said "Tested this with 10 Intel 82599 ports w. TYAN S7025
> > E5520 CPU's. Was able to TX/DMA ~80 Gbit/s to Ethernet wires."
> >
> > I am interested to know what particular setup you did to maximize
> > throughput then, or are you saing you managed to reduce it ? :)
>
>
> Some notes from the experiment, It's getting
> complex and hairy. Anyway results from the first
> tests to give you an idea... My colleague Olof
> might have some comments/details
>
> pktgen sending on 10 * 10g interfaces.
>
> [From pktgen script]
> fn()
> {
> i=$1 #ifname
> c=$2 #queue / cpu core
> n=$3 # numa node
> PGDEV=/proc/net/pktgen/kpktgend_$c
> pgset "add_device eth$i@$c "
> PGDEV=/proc/net/pktgen/eth$i@$c
> pgset "node $n"
> pgset "$COUNT"
> pgset "flag NODE_ALLOC"
> pgset "$CLONE_SKB"
> pgset "$PKT_SIZE"
> pgset "$DELAY"
> pgset "dst 10.0.0.0"
> }
>
> remove_all
> # Setup
>
> # TYAN S7025 with two nodes.
> # Each node has own bus with it's own TYLERSBURG bridge
> # so eth0-eth3 is closest to node0 which in turn "owns"
> # CPU-cores 0-3 in this HW setup. So we setup so
> # pktgen according to this. clone_skb=1000000.
> # Used slots are PCIe-x16 except when PCIe-x8 is indicated.
>
> # eth0 queue=0(CPU) node=0
> fn 0 0 0
> fn 1 1 0
> fn 2 2 0
> fn 3 3 0
> fn 4 4 1
> fn 5 5 1
> fn 6 6 1
> fn 7 7 1
> fn 8 12 1
> fn 9 13 1
>
> Result "manually" tuned.
>
> eth0 9617.7 M bit/s 822 k pps
> eth1 9619.1 M bit/s 823 k pps
> eth2 9619.1 M bit/s 823 k pps
> eth3 9619.2 M bit/s 823 k pps
> eth4 5995.2 M bit/s 512 k pps <- PCIe-x8
> eth5 5995.3 M bit/s 512 k pps <- PCIe-x8
> eth6 9619.2 M bit/s 823 k pps
> eth7 9619.2 M bit/s 823 k pps
> eth8 9619.1 M bit/s 823 k pps
> eth9 9619.0 M bit/s 823 k pps
>
> > 90 Gbit/s
>
> Result "manually" mistuned by switching node 0 and 1.
>
> eth0 9613.6 M bit/s 822 k pps
> eth1 9614.9 M bit/s 822 k pps
> eth2 9615.0 M bit/s 822 k pps
> eth3 9615.1 M bit/s 822 k pps
> eth4 2918.5 M bit/s 249 k pps <- PCIe-x8
> eth5 2918.4 M bit/s 249 k pps <- PCIe-x8
> eth6 8597.0 M bit/s 735 k pps
> eth7 8597.0 M bit/s 735 k pps
> eth8 8568.3 M bit/s 733 k pps
> eth9 8568.3 M bit/s 733 k pps
>
> A lot things is to be investgated...
Sure :)
I wonder why eth0-eth3 results are unchanged after a node flip.
Thanks for sharing
^ permalink raw reply
* Re: [RFC] GTSM for IPv6
From: YOSHIFUJI Hideaki @ 2010-03-22 7:27 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Miller, netdev, YOSHIFUJI Hideaki
In-Reply-To: <20100319095640.42c8d82d@nehalam>
(2010/03/20 1:56), Stephen Hemminger wrote:
> Also RFC doesn't explicitly address GTSM on IPV6.
> Maybe the RFC editors think the problem will magically no longer exist
> in IPv6 world because everyone will be using IPsec.
> ---
> include/linux/in6.h | 3 +++
> include/linux/ipv6.h | 3 ++-
> net/ipv6/ipv6_sockglue.c | 12 ++++++++++++
> net/ipv6/tcp_ipv6.c | 17 ++++++++++++++---
> 4 files changed, 31 insertions(+), 4 deletions(-)
Why don't we have code for other protocols such as
UDP etc? We already have similar protection in NDP,
It seem to make sense.
And, as many other socket options (such as IPV6_UNICAST_HOPS
etc.) do, please accept value of -1 to set the system's
default (0 so far).
x < -1: return an error of EINVAL
x == -1: use kernel default
0 <= x <= 255: use x
x >= 256: return an error of EINVAL
We may also want to have sysctl for it.
Regrads,
--yoshfuji
^ permalink raw reply
* Re: [RFC] GTSM for IPv6
From: YOSHIFUJI Hideaki @ 2010-03-22 7:14 UTC (permalink / raw)
To: Pekka Savola; +Cc: Stephen Hemminger, David Miller, netdev
In-Reply-To: <alpine.LRH.2.00.1003191959050.31512@netcore.fi>
(2010/03/20 3:02), Pekka Savola wrote:
> On Fri, 19 Mar 2010, Stephen Hemminger wrote:
>> Also RFC doesn't explicitly address GTSM on IPV6.
>> Maybe the RFC editors think the problem will magically no longer exist
>> in IPv6 world because everyone will be using IPsec.
>
> Hmm. When I was editing the RFC, I seem to have put in some text about
> IPv6 (i.e. difference in TTL vs Hop Count naming). As far as I know,
> there is no other difference :-)
>
> In IPV6_MIN_HOPS hops would seem to point toward the "number of hops"
> which is logically the opposite: 255-$value. So maybe IPV6_MIN_HOPCOUNT
> is better. But I can live with it either way :-)
>
Or, how about IPV6_MAX_HOPS, then? :-)
--yoshfuji
^ permalink raw reply
* [PATCH] can: bfin_can: switch to common Blackfin can header
From: Mike Frysinger @ 2010-03-22 7:06 UTC (permalink / raw)
To: socketcan-core, Urs Thuermann, Oliver Hartkopp, netdev,
David S. Miller
Cc: uclinux-dist-devel
In-Reply-To: <1268150589-27123-1-git-send-email-vapier@gentoo.org>
The MMR bits are being moved to this header, so include it.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Acked-by: Wolfgang Grandegger <wg@grandegger.com>
---
drivers/net/can/bfin_can.c | 97 +++----------------------------------------
1 files changed, 7 insertions(+), 90 deletions(-)
diff --git a/drivers/net/can/bfin_can.c b/drivers/net/can/bfin_can.c
index 866905f..0348986 100644
--- a/drivers/net/can/bfin_can.c
+++ b/drivers/net/can/bfin_can.c
@@ -22,6 +22,7 @@
#include <linux/can/dev.h>
#include <linux/can/error.h>
+#include <asm/bfin_can.h>
#include <asm/portmux.h>
#define DRV_NAME "bfin_can"
@@ -29,90 +30,6 @@
#define TX_ECHO_SKB_MAX 1
/*
- * transmit and receive channels
- */
-#define TRANSMIT_CHL 24
-#define RECEIVE_STD_CHL 0
-#define RECEIVE_EXT_CHL 4
-#define RECEIVE_RTR_CHL 8
-#define RECEIVE_EXT_RTR_CHL 12
-#define MAX_CHL_NUMBER 32
-
-/*
- * bfin can registers layout
- */
-struct bfin_can_mask_regs {
- u16 aml;
- u16 dummy1;
- u16 amh;
- u16 dummy2;
-};
-
-struct bfin_can_channel_regs {
- u16 data[8];
- u16 dlc;
- u16 dummy1;
- u16 tsv;
- u16 dummy2;
- u16 id0;
- u16 dummy3;
- u16 id1;
- u16 dummy4;
-};
-
-struct bfin_can_regs {
- /*
- * global control and status registers
- */
- u16 mc1; /* offset 0 */
- u16 dummy1;
- u16 md1; /* offset 4 */
- u16 rsv1[13];
- u16 mbtif1; /* offset 0x20 */
- u16 dummy2;
- u16 mbrif1; /* offset 0x24 */
- u16 dummy3;
- u16 mbim1; /* offset 0x28 */
- u16 rsv2[11];
- u16 mc2; /* offset 0x40 */
- u16 dummy4;
- u16 md2; /* offset 0x44 */
- u16 dummy5;
- u16 trs2; /* offset 0x48 */
- u16 rsv3[11];
- u16 mbtif2; /* offset 0x60 */
- u16 dummy6;
- u16 mbrif2; /* offset 0x64 */
- u16 dummy7;
- u16 mbim2; /* offset 0x68 */
- u16 rsv4[11];
- u16 clk; /* offset 0x80 */
- u16 dummy8;
- u16 timing; /* offset 0x84 */
- u16 rsv5[3];
- u16 status; /* offset 0x8c */
- u16 dummy9;
- u16 cec; /* offset 0x90 */
- u16 dummy10;
- u16 gis; /* offset 0x94 */
- u16 dummy11;
- u16 gim; /* offset 0x98 */
- u16 rsv6[3];
- u16 ctrl; /* offset 0xa0 */
- u16 dummy12;
- u16 intr; /* offset 0xa4 */
- u16 rsv7[7];
- u16 esr; /* offset 0xb4 */
- u16 rsv8[37];
-
- /*
- * channel(mailbox) mask and message registers
- */
- struct bfin_can_mask_regs msk[MAX_CHL_NUMBER]; /* offset 0x100 */
- struct bfin_can_channel_regs chl[MAX_CHL_NUMBER]; /* offset 0x200 */
-};
-
-/*
* bfin can private data
*/
struct bfin_can_priv {
@@ -163,7 +80,7 @@ static int bfin_can_set_bittiming(struct net_device *dev)
if (priv->can.ctrlmode & CAN_CTRLMODE_3_SAMPLES)
timing |= SAM;
- bfin_write16(®->clk, clk);
+ bfin_write16(®->clock, clk);
bfin_write16(®->timing, timing);
dev_info(dev->dev.parent, "setting CLOCK=0x%04x TIMING=0x%04x\n",
@@ -185,11 +102,11 @@ static void bfin_can_set_reset_mode(struct net_device *dev)
bfin_write16(®->gim, 0);
/* reset can and enter configuration mode */
- bfin_write16(®->ctrl, SRS | CCR);
+ bfin_write16(®->control, SRS | CCR);
SSYNC();
- bfin_write16(®->ctrl, CCR);
+ bfin_write16(®->control, CCR);
SSYNC();
- while (!(bfin_read16(®->ctrl) & CCA)) {
+ while (!(bfin_read16(®->control) & CCA)) {
udelay(10);
if (--timeout == 0) {
dev_err(dev->dev.parent,
@@ -244,7 +161,7 @@ static void bfin_can_set_normal_mode(struct net_device *dev)
/*
* leave configuration mode
*/
- bfin_write16(®->ctrl, bfin_read16(®->ctrl) & ~CCR);
+ bfin_write16(®->control, bfin_read16(®->control) & ~CCR);
while (bfin_read16(®->status) & CCA) {
udelay(10);
@@ -726,7 +643,7 @@ static int bfin_can_suspend(struct platform_device *pdev, pm_message_t mesg)
if (netif_running(dev)) {
/* enter sleep mode */
- bfin_write16(®->ctrl, bfin_read16(®->ctrl) | SMR);
+ bfin_write16(®->control, bfin_read16(®->control) | SMR);
SSYNC();
while (!(bfin_read16(®->intr) & SMACK)) {
udelay(10);
--
1.7.0.2
^ permalink raw reply related
* Re: [Uclinux-dist-devel] [PATCH] can: bfin_can: switch to common Blackfin can header
From: Mike Frysinger @ 2010-03-22 7:04 UTC (permalink / raw)
To: David Miller
Cc: socketcan-core, netdev, uclinux-dist-devel, oliver.hartkopp,
urs.thuermann
In-Reply-To: <20100321.205818.63035686.davem@davemloft.net>
On Sun, Mar 21, 2010 at 23:58, David Miller wrote:
> From: Mike Frysinger <vapier.adi@gmail.com>
>> either you've deleted the thread or your mail client sucks ? the
>> patch in question started this thread you keep replying to ...
>
> You're an idiot and you don't care how much work you are
> making for me, so you are now set to ignore.
clearly this is the best way to work with people
> When I say "resubmit" I've deleted your patch from my inbox
> and marked it "changed requested" or similar in patchwork
> so it doesn't show up in the todo list any more.
i missed the relevance of your original "resubmit" because no other
maintainer ive worked with so far has exhibited this behavior, and
there wasnt any indication as to why a resubmission was necessary
considering no changes were made
-mike
^ permalink raw reply
* Re: RCU problems in fib_table_insert
From: Paul E. McKenney @ 2010-03-22 6:51 UTC (permalink / raw)
To: David Miller; +Cc: andi, robert.olsson, netdev
In-Reply-To: <20100321.180140.45887114.davem@davemloft.net>
On Sun, Mar 21, 2010 at 06:01:40PM -0700, David Miller wrote:
> From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
> Date: Sun, 21 Mar 2010 14:37:03 -0700
>
> > net: suppress lockdep-RCU false positive in FIB trie.
> >
> > Allow fib_find_node() to be called either under rcu_read_lock()
> > protection or with RTNL held.
> >
> > Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
>
> Thanks guys, I applied this copy and added Eric's signoff
> since the two patches were essentially identical :-)
Great minds thinking alike and all that. ;-)
Thanx, Paul
^ permalink raw reply
* Re: RCU problems in fib_table_insert
From: Paul E. McKenney @ 2010-03-22 6:51 UTC (permalink / raw)
To: Robert Olsson; +Cc: Andi Kleen, robert.olsson, netdev
In-Reply-To: <19367.3002.324694.563877@gargle.gargle.HOWL>
On Mon, Mar 22, 2010 at 07:18:34AM +0100, Robert Olsson wrote:
>
> Seems like Paul and Eric fixed this problem... We use fib_trie with
> major infrastructure but always disable preempt. It was unsafe w.
> preempt at least before Jareks P. patches about a year ago. I havn't
> tested w. preempt after that but maybe someone else have...
Well, if some code path fails either to do rcu_read_lock() or
to acquire RTNL, we will see lockdep splats.
Though I must admit that I would be surprised if there wasn't
more adjustment required in net/ipv4/fib_trie.c -- lots of
rcu_dereference()s in there.
Thanx, Paul
> Cheers
> --ro
>
> Andi Kleen writes:
> > Hi,
> >
> > I got the following warning at boot with a 2.6.34-rc2ish git kernel
> > with RCU debugging and preemption enabled.
> >
> > It seems the problem is that not all callers of fib_find_node
> > call it with rcu_read_lock() to stabilize access to the fib.
> >
> > I tried to fix it, but especially for fib_table_insert() that's rather
> > tricky: it does a lot of memory allocations and also route flushing and
> > other blocking operations while assuming the original fa is RCU stable.
> >
> > I first tried to move some allocations to the beginning and keep
> > preemption disabled in the rest, but it's difficult with all of them.
> > No patch because of that.
> >
> > Does the fa need an additional reference count for this problem?
> > Or perhaps some optimistic locking?
> >
> > -Andi
> >
> >
> > ==================================================
> > [ INFO: suspicious rcu_dereference_check() usage. ]
> > ---------------------------------------------------
> > /home/lsrc/git/linux-2.6/net/ipv4/fib_trie.c:964 invoked rcu_dereference_check() without protection!
> >
> > other info that might help us debug this:
> >
> >
> > rcu_scheduler_active = 1, debug_locks = 0
> > 2 locks held by ip/4521:
> > #0: (rtnl_mutex){+.+.+.}, at: [<ffffffff816466af>] rtnetlink_rcv+0x1f/0x40
> > #1: ((inetaddr_chain).rwsem){.+.+.+}, at: [<ffffffff8107cde7>] __blocking_notifier_call_chain+0x47/0x90
> >
> > stack backtrace:
> > Pid: 4521, comm: ip Not tainted 2.6.34-rc2 #5
> > Call Trace:
> > [<ffffffff8108b7e9>] lockdep_rcu_dereference+0xb9/0xc0
> > [<ffffffff81696a05>] fib_find_node+0x185/0x1b0
> > [<ffffffff8101155f>] ? save_stack_trace+0x2f/0x50
> > [<ffffffff81699b1c>] fib_table_insert+0xdc/0xa90
> > [<ffffffff8107cde7>] ? __blocking_notifier_call_chain+0x47/0x90
> > [<ffffffff8108edb5>] ? __lock_acquire+0x1485/0x1d50
> > [<ffffffff816926b0>] fib_magic+0xc0/0xd0
> > [<ffffffff81692738>] fib_add_ifaddr+0x78/0x1a0
> > [<ffffffff81692e60>] fib_inetaddr_event+0x50/0x2a0
> > [<ffffffff8173152d>] notifier_call_chain+0x6d/0xb0
> > [<ffffffff8107cdfd>] __blocking_notifier_call_chain+0x5d/0x90
> > [<ffffffff8107ce46>] blocking_notifier_call_chain+0x16/0x20
> > [<ffffffff81688c0a>] __inet_insert_ifa+0xea/0x180
> > [<ffffffff8168971d>] inetdev_event+0x43d/0x490
> > [<ffffffff8173152d>] notifier_call_chain+0x6d/0xb0
> > [<ffffffff8107cb06>] raw_notifier_call_chain+0x16/0x20
> > [<ffffffff81639f00>] __dev_notify_flags+0x40/0xa0
> > [<ffffffff81639fa5>] dev_change_flags+0x45/0x70
> > [<ffffffff81645c2c>] do_setlink+0x2fc/0x4a0
> > [<ffffffff81294176>] ? nla_parse+0x36/0x110
> > [<ffffffff81646d54>] rtnl_newlink+0x444/0x540
> > [<ffffffff8108c44d>] ? mark_held_locks+0x6d/0x90
> > [<ffffffff8172b8c5>] ? mutex_lock_nested+0x335/0x3c0
> > [<ffffffff8164685e>] rtnetlink_rcv_msg+0x18e/0x240
> > [<ffffffff816466d0>] ? rtnetlink_rcv_msg+0x0/0x240
> > [<ffffffff816520b9>] netlink_rcv_skb+0x89/0xb0
> > [<ffffffff816466be>] rtnetlink_rcv+0x2e/0x40
> > [<ffffffff81651b6b>] ? netlink_unicast+0x11b/0x2f0
> > [<ffffffff81651d2c>] netlink_unicast+0x2dc/0x2f0
> > [<ffffffff81630a3c>] ? memcpy_fromiovec+0x7c/0xa0
> > [<ffffffff81652643>] netlink_sendmsg+0x1d3/0x2e0
> > [<ffffffff81624e20>] sock_sendmsg+0xc0/0xf0
> > [<ffffffff8108f9cd>] ? lock_release_non_nested+0x9d/0x340
> > [<ffffffff810fa33b>] ? might_fault+0x7b/0xd0
> > [<ffffffff810fa33b>] ? might_fault+0x7b/0xd0
> > [<ffffffff810fa386>] ? might_fault+0xc6/0xd0
> > [<ffffffff810fa33b>] ? might_fault+0x7b/0xd0
> > [<ffffffff81630bfc>] ? verify_iovec+0x4c/0xe0
> > [<ffffffff81625c3e>] sys_sendmsg+0x1ae/0x360
> > [<ffffffff810fadf9>] ? __do_fault+0x3f9/0x550
> > [<ffffffff810fd143>] ? handle_mm_fault+0x1a3/0x790
> > [<ffffffff8112cc77>] ? fget_light+0xe7/0x2f0
> > [<ffffffff8108c735>] ? trace_hardirqs_on_caller+0x135/0x180
> > [<ffffffff8172ccc2>] ? trace_hardirqs_on_thunk+0x3a/0x3f
> > [<ffffffff810030db>] system_call_fastpath+0x16/0x1b
> >
> >
> >
> >
> >
> > --
> > ak@linux.intel.com -- Speaking for myself only.
^ permalink raw reply
* RE: [PATCH] netxen: The driver doesn't work on NX_P3_B1 so cause probe to fail.
From: Amit Salecha @ 2010-03-22 6:35 UTC (permalink / raw)
To: Amit Salecha, David Miller, ebiederm@xmission.com
Cc: netdev@vger.kernel.org, Ameen Rahman
In-Reply-To: <20100318.222126.27823381.davem@davemloft.net>
David,
After discussing this issues with my team, this is fine with Qlogic to remove support of NX_P3_B1.
You can go ahead with Eric's patch.
Sorry for all these hiccups.
-Amit Salecha
-----Original Message-----
From: Amit Salecha
Sent: Friday, March 19, 2010 5:33 PM
To: 'David Miller'; 'ebiederm@xmission.com'
Cc: 'netdev@vger.kernel.org'; Ameen Rahman
Subject: RE: [PATCH] netxen: The driver doesn't work on NX_P3_B1 so cause probe to fail.
David,
Eric's initial problem got resolved by using newer firmware (link problem).
He is facing another problem, mac address are all ff:ff:ff.
Though this problem goes away with driver reload.
We had asked for fw dump to analyze this problem in detail.
-Amit Salecha
-----Original Message-----
From: Amit Salecha
Sent: Friday, March 19, 2010 11:07 AM
To: 'David Miller'; ebiederm@xmission.com
Cc: netdev@vger.kernel.org; Ameen Rahman
Subject: RE: [PATCH] netxen: The driver doesn't work on NX_P3_B1 so cause probe to fail.
We are working on this problem, will let you know our decision by end of day.
-Thanks
-----Original Message-----
From: David Miller [mailto:davem@davemloft.net]
Sent: Friday, March 19, 2010 10:51 AM
To: ebiederm@xmission.com
Cc: Amit Salecha; netdev@vger.kernel.org; Ameen Rahman
Subject: Re: [PATCH] netxen: The driver doesn't work on NX_P3_B1 so cause probe to fail.
From: ebiederm@xmission.com (Eric W. Biederman)
Date: Thu, 18 Mar 2010 02:43:39 -0700
> Amit Salecha <amit.salecha@qlogic.com> writes:
>
>> Sorry for all the problem you faced.
>>
>> But you shouldn't add support of device which is not supported.
>> Netxen is now owned by Qlogic. You should first contact Qlogic to solve your problem.
>> Qlogic will take needed action based on problem.
>
> I'm not adding support. I am sending a patch removing support for cards
> that do not work with the current driver and have not worked since 2.6.31.
You qlogic folks better resolve this _FAST_ or else I'll
make an executive decision about how to handle this and
I guarentee I'll make a decision that you will not like.
Thanks. :-)
^ permalink raw reply
* Re: [PATCH] pktgen node allocation
From: Robert Olsson @ 2010-03-22 6:24 UTC (permalink / raw)
To: Eric Dumazet; +Cc: robert, David Miller, netdev, olofh
In-Reply-To: <1269006465.3048.39.camel@edumazet-laptop>
Eric Dumazet writes:
> Well, you said "Tested this with 10 Intel 82599 ports w. TYAN S7025
> E5520 CPU's. Was able to TX/DMA ~80 Gbit/s to Ethernet wires."
>
> I am interested to know what particular setup you did to maximize
> throughput then, or are you saing you managed to reduce it ? :)
Some notes from the experiment, It's getting
complex and hairy. Anyway results from the first
tests to give you an idea... My colleague Olof
might have some comments/details
pktgen sending on 10 * 10g interfaces.
[From pktgen script]
fn()
{
i=$1 #ifname
c=$2 #queue / cpu core
n=$3 # numa node
PGDEV=/proc/net/pktgen/kpktgend_$c
pgset "add_device eth$i@$c "
PGDEV=/proc/net/pktgen/eth$i@$c
pgset "node $n"
pgset "$COUNT"
pgset "flag NODE_ALLOC"
pgset "$CLONE_SKB"
pgset "$PKT_SIZE"
pgset "$DELAY"
pgset "dst 10.0.0.0"
}
remove_all
# Setup
# TYAN S7025 with two nodes.
# Each node has own bus with it's own TYLERSBURG bridge
# so eth0-eth3 is closest to node0 which in turn "owns"
# CPU-cores 0-3 in this HW setup. So we setup so
# pktgen according to this. clone_skb=1000000.
# Used slots are PCIe-x16 except when PCIe-x8 is indicated.
# eth0 queue=0(CPU) node=0
fn 0 0 0
fn 1 1 0
fn 2 2 0
fn 3 3 0
fn 4 4 1
fn 5 5 1
fn 6 6 1
fn 7 7 1
fn 8 12 1
fn 9 13 1
Result "manually" tuned.
eth0 9617.7 M bit/s 822 k pps
eth1 9619.1 M bit/s 823 k pps
eth2 9619.1 M bit/s 823 k pps
eth3 9619.2 M bit/s 823 k pps
eth4 5995.2 M bit/s 512 k pps <- PCIe-x8
eth5 5995.3 M bit/s 512 k pps <- PCIe-x8
eth6 9619.2 M bit/s 823 k pps
eth7 9619.2 M bit/s 823 k pps
eth8 9619.1 M bit/s 823 k pps
eth9 9619.0 M bit/s 823 k pps
> 90 Gbit/s
Result "manually" mistuned by switching node 0 and 1.
eth0 9613.6 M bit/s 822 k pps
eth1 9614.9 M bit/s 822 k pps
eth2 9615.0 M bit/s 822 k pps
eth3 9615.1 M bit/s 822 k pps
eth4 2918.5 M bit/s 249 k pps <- PCIe-x8
eth5 2918.4 M bit/s 249 k pps <- PCIe-x8
eth6 8597.0 M bit/s 735 k pps
eth7 8597.0 M bit/s 735 k pps
eth8 8568.3 M bit/s 733 k pps
eth9 8568.3 M bit/s 733 k pps
A lot things is to be investgated...
Cheers
--ro
^ 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