* Re: [PATCH][NET] several cleanups and bugfixes for fec.c: fix the .remove code
From: Shawn Guo @ 2011-12-07 13:28 UTC (permalink / raw)
To: Lothar Waßmann; +Cc: netdev, Shawn Guo, linux-kernel, linux-arm-kernel
In-Reply-To: <04c11563fee748562d7b53d5e5b3c5cf37fef200.1323163127.git.LW@KARO-electronics.de>
On Tue, Dec 06, 2011 at 11:27:15AM +0100, Lothar Waßmann wrote:
> The .remove code is broken in several ways.
> - mdiobus_unregister() is called twice for the same object in case of dual FEC
> - phy_disconnect() is being called when the PHY is already disconnected
> - the requested IRQ(s) are not freed
> - fec_stop() is being called with the inteface already stopped
>
> All of those lead to kernel crashes if the remove function is actually used.
>
> Signed-off-by: Lothar Waßmann <LW@KARO-electronics.de>
> ---
> drivers/net/ethernet/freescale/fec.c | 30 +++++++++++++++++++++---------
> 1 files changed, 21 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/net/ethernet/freescale/fec.c b/drivers/net/ethernet/freescale/fec.c
> index ab0afb5..70ec7ec 100644
> --- a/drivers/net/ethernet/freescale/fec.c
> +++ b/drivers/net/ethernet/freescale/fec.c
> @@ -235,6 +235,7 @@ struct fec_enet_private {
>
> /* Phylib and MDIO interface */
> struct mii_bus *mii_bus;
> + int mii_cnt;
> struct phy_device *phy_dev;
> int mii_timeout;
> uint phy_speed;
> @@ -1040,8 +1041,12 @@ static int fec_enet_mii_init(struct platform_device *pdev)
> */
> if ((id_entry->driver_data & FEC_QUIRK_ENET_MAC) && pdev->id > 0) {
> /* fec1 uses fec0 mii_bus */
> - fep->mii_bus = fec0_mii_bus;
> - return 0;
> + if (fep->mii_cnt && fec0_mii_bus) {
This seems broken. The second fec has its own fep and fep->mii_cnt is
always 0 here.
Regards,
Shawn
> + fep->mii_bus = fec0_mii_bus;
> + fep->mii_cnt++;
> + return 0;
> + }
> + return -ENOENT;
> }
>
> fep->mii_timeout = 0;
> @@ -1086,6 +1091,8 @@ static int fec_enet_mii_init(struct platform_device *pdev)
> if (mdiobus_register(fep->mii_bus))
> goto err_out_free_mdio_irq;
>
> + fep->mii_cnt++;
> +
> /* save fec0 mii_bus */
> if (id_entry->driver_data & FEC_QUIRK_ENET_MAC)
> fec0_mii_bus = fep->mii_bus;
> @@ -1102,11 +1109,11 @@ err_out:
>
> static void fec_enet_mii_remove(struct fec_enet_private *fep)
> {
> - if (fep->phy_dev)
> - phy_disconnect(fep->phy_dev);
> - mdiobus_unregister(fep->mii_bus);
> - kfree(fep->mii_bus->irq);
> - mdiobus_free(fep->mii_bus);
> + if (--fep->mii_cnt == 0) {
> + mdiobus_unregister(fep->mii_bus);
> + kfree(fep->mii_bus->irq);
> + mdiobus_free(fep->mii_bus);
> + }
> }
>
> static int fec_enet_get_settings(struct net_device *ndev,
> @@ -1646,13 +1653,18 @@ fec_drv_remove(struct platform_device *pdev)
> struct net_device *ndev = platform_get_drvdata(pdev);
> struct fec_enet_private *fep = netdev_priv(ndev);
> struct resource *r;
> + int i;
>
> - fec_stop(ndev);
> + unregister_netdev(ndev);
> fec_enet_mii_remove(fep);
> + for (i = 0; i < FEC_IRQ_NUM; i++) {
> + int irq = platform_get_irq(pdev, i);
> + if (irq > 0)
> + free_irq(irq, ndev);
> + }
> clk_disable(fep->clk);
> clk_put(fep->clk);
> iounmap(fep->hwp);
> - unregister_netdev(ndev);
> free_netdev(ndev);
>
> r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> --
> 1.5.6.5
^ permalink raw reply
* Re: Latency difference between fifo and pfifo_fast
From: Dave Taht @ 2011-12-07 13:27 UTC (permalink / raw)
To: Eric Dumazet; +Cc: John A. Sullivan III, netdev, Rick Jones
In-Reply-To: <1323263079.2312.22.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
On Wed, Dec 7, 2011 at 2:04 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le mardi 06 décembre 2011 à 14:44 -0500, John A. Sullivan III a écrit :
>> Interesting. Would that still be true if all the traffic is the same,
>> i.e., nothing but iSCSI packets on the network? Or would just dumping
>> packets with minimal processing be fastest? Thanks - John
>
> Dave focuses on fairness and latencies under ~20 ms (a typical (under)
> provisioned ADSL (up)link shared by many (hostile) flows, with various
> type of services)
True, that is my focus, but queuing theory applies at all time scales.
If it didn't, the universe, and not just the internet, would have melted
down long ago.
And I did ask specifically what sort of latencies he was trying to address.
If he's hovering at close to line rate (wow), and yet experiencing
serious delays on short traffic, perhaps what I describe below may apply.
> I doubt this is your concern ? You want high throughput more than low
> latencies ...
My assumption - is that your 'iSCSI' packets are TCP streams. If they aren't,
then some of what I say below does not apply, although I tend to be
a believer in FQ technologies for their effects on downstream buffering.
I freely confess to not grokking how iSCSI is deployed. My understanding
is that TCP is used to negotiate a virtual connection between two endpoints,
and there are usually very few - usually one - endpoints.
1) TCP grabs all the bandwidth it can. If you have no packet loss,
it will eat more bandwidth, as rapidly as it can ramp up. Until it eventually
has packet loss.
Q) John indicated he didn't want any packet loss, so I for starters questioned
my assumption he was using tcp, and secondly it was late, and I was
feeling snarky. I honestly should stay in the .2ms to 10000ms range I'm
comfortable in.
2) Once you have one stream so completely dominating a connection
it can starve other stream's attempts to ramp up.
> Your workload is probably under _one_ ms latencies, and dedicated link
> to address few targets.
That was my second question, basically, how many links are in use?
More than 1 introduces a head of line problem between flows.
> If you have to use a Qdisc (and expensive packet classification), then
> something is wrong in your iSCSI network connectivity :)
>
> Please note that with BQL, the NIC TX ring size doesn’t matter, and you
> could get "Virtual device ethX asks to queue packet!" warnings in your
> message log.
so his tx 4000 is 'about right', even without BQL?
>
> So before removing Qdisc, you also want to make sure BQL is disabled for
> your NIC device/queues.
> (BQL is scheduled for linux-3.3)
>
>
>
--
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
FR Tel: 0638645374
http://www.bufferbloat.net
^ permalink raw reply
* Re: [PATCH][NET] several cleanups and bugfixes for fec.c: fix the .remove code
From: Lothar Waßmann @ 2011-12-07 13:26 UTC (permalink / raw)
To: Shawn Guo; +Cc: netdev, Shawn Guo, linux-kernel, linux-arm-kernel
In-Reply-To: <20111207132828.GQ5550@S2100-06.ap.freescale.net>
Hi,
Shawn Guo writes:
> On Tue, Dec 06, 2011 at 11:27:15AM +0100, Lothar Waßmann wrote:
> > The .remove code is broken in several ways.
> > - mdiobus_unregister() is called twice for the same object in case of dual FEC
> > - phy_disconnect() is being called when the PHY is already disconnected
> > - the requested IRQ(s) are not freed
> > - fec_stop() is being called with the inteface already stopped
> >
> > All of those lead to kernel crashes if the remove function is actually used.
> >
> > Signed-off-by: Lothar Waßmann <LW@KARO-electronics.de>
> > ---
> > drivers/net/ethernet/freescale/fec.c | 30 +++++++++++++++++++++---------
> > 1 files changed, 21 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/freescale/fec.c b/drivers/net/ethernet/freescale/fec.c
> > index ab0afb5..70ec7ec 100644
> > --- a/drivers/net/ethernet/freescale/fec.c
> > +++ b/drivers/net/ethernet/freescale/fec.c
> > @@ -235,6 +235,7 @@ struct fec_enet_private {
> >
> > /* Phylib and MDIO interface */
> > struct mii_bus *mii_bus;
> > + int mii_cnt;
> > struct phy_device *phy_dev;
> > int mii_timeout;
> > uint phy_speed;
> > @@ -1040,8 +1041,12 @@ static int fec_enet_mii_init(struct platform_device *pdev)
> > */
> > if ((id_entry->driver_data & FEC_QUIRK_ENET_MAC) && pdev->id > 0) {
> > /* fec1 uses fec0 mii_bus */
> > - fep->mii_bus = fec0_mii_bus;
> > - return 0;
> > + if (fep->mii_cnt && fec0_mii_bus) {
>
> This seems broken. The second fec has its own fep and fep->mii_cnt is
> always 0 here.
>
I already noticed that myself.
Lothar Waßmann
--
___________________________________________________________
Ka-Ro electronics GmbH | Pascalstraße 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
Geschäftsführer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996
www.karo-electronics.de | info@karo-electronics.de
___________________________________________________________
^ permalink raw reply
* Re: Latency difference between fifo and pfifo_fast
From: Eric Dumazet @ 2011-12-07 13:04 UTC (permalink / raw)
To: John A. Sullivan III; +Cc: Dave Taht, netdev, Rick Jones
In-Reply-To: <9bf91034-a860-4144-858b-c9000964ea1d@jasiiieee>
Le mardi 06 décembre 2011 à 14:44 -0500, John A. Sullivan III a écrit :
> Interesting. Would that still be true if all the traffic is the same,
> i.e., nothing but iSCSI packets on the network? Or would just dumping
> packets with minimal processing be fastest? Thanks - John
Dave focuses on fairness and latencies under ~20 ms (a typical (under)
provisioned ADSL (up)link shared by many (hostile) flows, with various
type of services)
I doubt this is your concern ? You want high throughput more than low
latencies ...
Your workload is probably under _one_ ms latencies, and dedicated link
to address few targets.
If you have to use a Qdisc (and expensive packet classification), then
something is wrong in your iSCSI network connectivity :)
Please note that with BQL, the NIC TX ring size doesn’t matter, and you
could get "Virtual device ethX asks to queue packet!" warnings in your
message log.
So before removing Qdisc, you also want to make sure BQL is disabled for
your NIC device/queues.
(BQL is scheduled for linux-3.3)
^ permalink raw reply
* [PATCH 3/4] SUNRPC: use passed network namespace context in rpc_pton()
From: Stanislav Kinsbursky @ 2011-12-07 12:20 UTC (permalink / raw)
To: Trond.Myklebust
Cc: linux-nfs, xemul, neilb, netdev, linux-kernel, jbottomley,
bfields, davem, devel
In-Reply-To: <20111207111716.17273.63010.stgit@localhost6.localdomain6>
Use incomming network context in rpc_pton() instead of hard-coded "init_net".
Signed-off-by: Stanislav Kinsbursky <skinsbursky@parallels.com>
---
fs/nfs/dns_resolve.c | 4 ++--
fs/nfs/nfs4filelayoutdev.c | 2 +-
fs/nfs/nfs4namespace.c | 2 +-
fs/nfs/super.c | 4 ++--
fs/nfsd/nfsctl.c | 2 +-
include/linux/sunrpc/clnt.h | 2 +-
net/sunrpc/addr.c | 7 ++++---
net/sunrpc/svcauth_unix.c | 2 +-
8 files changed, 13 insertions(+), 12 deletions(-)
diff --git a/fs/nfs/dns_resolve.c b/fs/nfs/dns_resolve.c
index a6e711a..e698242 100644
--- a/fs/nfs/dns_resolve.c
+++ b/fs/nfs/dns_resolve.c
@@ -20,7 +20,7 @@ ssize_t nfs_dns_resolve_name(char *name, size_t namelen,
ip_len = dns_query(NULL, name, namelen, NULL, &ip_addr, NULL);
if (ip_len > 0)
- ret = rpc_pton(ip_addr, ip_len, sa, salen);
+ ret = rpc_pton(&init_net, ip_addr, ip_len, sa, salen);
else
ret = -ESRCH;
kfree(ip_addr);
@@ -224,7 +224,7 @@ static int nfs_dns_parse(struct cache_detail *cd, char *buf, int buflen)
len = qword_get(&buf, buf1, sizeof(buf1));
if (len <= 0)
goto out;
- key.addrlen = rpc_pton(buf1, len,
+ key.addrlen = rpc_pton(&init_net, buf1, len,
(struct sockaddr *)&key.addr,
sizeof(key.addr));
diff --git a/fs/nfs/nfs4filelayoutdev.c b/fs/nfs/nfs4filelayoutdev.c
index ed388aa..d6b5409 100644
--- a/fs/nfs/nfs4filelayoutdev.c
+++ b/fs/nfs/nfs4filelayoutdev.c
@@ -457,7 +457,7 @@ decode_ds_addr(struct xdr_stream *streamp, gfp_t gfp_flags)
INIT_LIST_HEAD(&da->da_node);
- if (!rpc_pton(buf, portstr-buf, (struct sockaddr *)&da->da_addr,
+ if (!rpc_pton(&init_net, buf, portstr-buf, (struct sockaddr *)&da->da_addr,
sizeof(da->da_addr))) {
dprintk("%s: error parsing address %s\n", __func__, buf);
goto out_free_da;
diff --git a/fs/nfs/nfs4namespace.c b/fs/nfs/nfs4namespace.c
index bb80c49..85aa3da 100644
--- a/fs/nfs/nfs4namespace.c
+++ b/fs/nfs/nfs4namespace.c
@@ -98,7 +98,7 @@ static size_t nfs_parse_server_name(char *string, size_t len,
{
ssize_t ret;
- ret = rpc_pton(string, len, sa, salen);
+ ret = rpc_pton(&init_net, string, len, sa, salen);
if (ret == 0) {
ret = nfs_dns_resolve_name(string, len, sa, salen);
if (ret < 0)
diff --git a/fs/nfs/super.c b/fs/nfs/super.c
index 1347774..b31bdf4 100644
--- a/fs/nfs/super.c
+++ b/fs/nfs/super.c
@@ -1392,7 +1392,7 @@ static int nfs_parse_mount_options(char *raw,
if (string == NULL)
goto out_nomem;
mnt->nfs_server.addrlen =
- rpc_pton(string, strlen(string),
+ rpc_pton(&init_net, string, strlen(string),
(struct sockaddr *)
&mnt->nfs_server.address,
sizeof(mnt->nfs_server.address));
@@ -1414,7 +1414,7 @@ static int nfs_parse_mount_options(char *raw,
if (string == NULL)
goto out_nomem;
mnt->mount_server.addrlen =
- rpc_pton(string, strlen(string),
+ rpc_pton(&init_net, string, strlen(string),
(struct sockaddr *)
&mnt->mount_server.address,
sizeof(mnt->mount_server.address));
diff --git a/fs/nfsd/nfsctl.c b/fs/nfsd/nfsctl.c
index c45a2ea..f9d0599 100644
--- a/fs/nfsd/nfsctl.c
+++ b/fs/nfsd/nfsctl.c
@@ -222,7 +222,7 @@ static ssize_t write_unlock_ip(struct file *file, char *buf, size_t size)
if (qword_get(&buf, fo_path, size) < 0)
return -EINVAL;
- if (rpc_pton(fo_path, size, sap, salen) == 0)
+ if (rpc_pton(&init_net, fo_path, size, sap, salen) == 0)
return -EINVAL;
return nlmsvc_unlock_all_by_ip(sap);
diff --git a/include/linux/sunrpc/clnt.h b/include/linux/sunrpc/clnt.h
index 3d8f9c4..877a466 100644
--- a/include/linux/sunrpc/clnt.h
+++ b/include/linux/sunrpc/clnt.h
@@ -162,7 +162,7 @@ size_t rpc_peeraddr(struct rpc_clnt *, struct sockaddr *, size_t);
const char *rpc_peeraddr2str(struct rpc_clnt *, enum rpc_display_format_t);
size_t rpc_ntop(const struct sockaddr *, char *, const size_t);
-size_t rpc_pton(const char *, const size_t,
+size_t rpc_pton(struct net *, const char *, const size_t,
struct sockaddr *, const size_t);
char * rpc_sockaddr2uaddr(const struct sockaddr *, gfp_t);
size_t rpc_uaddr2sockaddr(const char *, const size_t,
diff --git a/net/sunrpc/addr.c b/net/sunrpc/addr.c
index c13a521..982fac7 100644
--- a/net/sunrpc/addr.c
+++ b/net/sunrpc/addr.c
@@ -230,6 +230,7 @@ static size_t rpc_pton6(struct net *net, const char *buf, const size_t buflen,
/**
* rpc_pton - Construct a sockaddr in @sap
+ * @net: applicable network namespace
* @buf: C string containing presentation format IP address
* @buflen: length of presentation address in bytes
* @sap: buffer into which to plant socket address
@@ -242,14 +243,14 @@ static size_t rpc_pton6(struct net *net, const char *buf, const size_t buflen,
* socket address, if successful. Returns zero if an error
* occurred.
*/
-size_t rpc_pton(const char *buf, const size_t buflen,
+size_t rpc_pton(struct net *net, const char *buf, const size_t buflen,
struct sockaddr *sap, const size_t salen)
{
unsigned int i;
for (i = 0; i < buflen; i++)
if (buf[i] == ':')
- return rpc_pton6(&init_net, buf, buflen, sap, salen);
+ return rpc_pton6(net, buf, buflen, sap, salen);
return rpc_pton4(buf, buflen, sap, salen);
}
EXPORT_SYMBOL_GPL(rpc_pton);
@@ -340,7 +341,7 @@ size_t rpc_uaddr2sockaddr(const char *uaddr, const size_t uaddr_len,
port = (unsigned short)((porthi << 8) | portlo);
*c = '\0';
- if (rpc_pton(buf, strlen(buf), sap, salen) == 0)
+ if (rpc_pton(&init_net, buf, strlen(buf), sap, salen) == 0)
return 0;
switch (sap->sa_family) {
diff --git a/net/sunrpc/svcauth_unix.c b/net/sunrpc/svcauth_unix.c
index ce13632..a7d0141 100644
--- a/net/sunrpc/svcauth_unix.c
+++ b/net/sunrpc/svcauth_unix.c
@@ -211,7 +211,7 @@ static int ip_map_parse(struct cache_detail *cd,
len = qword_get(&mesg, buf, mlen);
if (len <= 0) return -EINVAL;
- if (rpc_pton(buf, len, &address.sa, sizeof(address)) == 0)
+ if (rpc_pton(&init_net, buf, len, &address.sa, sizeof(address)) == 0)
return -EINVAL;
switch (address.sa.sa_family) {
case AF_INET:
^ permalink raw reply related
* [PATCH 2/4] SUNRPC: use passed network namespace context in rpc_pton6()
From: Stanislav Kinsbursky @ 2011-12-07 12:20 UTC (permalink / raw)
To: Trond.Myklebust
Cc: linux-nfs, xemul, neilb, netdev, linux-kernel, jbottomley,
bfields, davem, devel
In-Reply-To: <20111207111716.17273.63010.stgit@localhost6.localdomain6>
Use incomming network context in rpc_pton6() instead of hard-coded "init_net".
Signed-off-by: Stanislav Kinsbursky <skinsbursky@parallels.com>
---
net/sunrpc/addr.c | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/net/sunrpc/addr.c b/net/sunrpc/addr.c
index 35eb188..c13a521 100644
--- a/net/sunrpc/addr.c
+++ b/net/sunrpc/addr.c
@@ -198,7 +198,7 @@ static int rpc_parse_scope_id(struct net *net, const char *buf,
return 0;
}
-static size_t rpc_pton6(const char *buf, const size_t buflen,
+static size_t rpc_pton6(struct net *net, const char *buf, const size_t buflen,
struct sockaddr *sap, const size_t salen)
{
struct sockaddr_in6 *sin6 = (struct sockaddr_in6 *)sap;
@@ -214,14 +214,14 @@ static size_t rpc_pton6(const char *buf, const size_t buflen,
if (in6_pton(buf, buflen, addr, IPV6_SCOPE_DELIMITER, &delim) == 0)
return 0;
- if (!rpc_parse_scope_id(&init_net, buf, buflen, delim, sin6))
+ if (!rpc_parse_scope_id(net, buf, buflen, delim, sin6))
return 0;
sin6->sin6_family = AF_INET6;
return sizeof(struct sockaddr_in6);
}
#else
-static size_t rpc_pton6(const char *buf, const size_t buflen,
+static size_t rpc_pton6(struct net *net, const char *buf, const size_t buflen,
struct sockaddr *sap, const size_t salen)
{
return 0;
@@ -249,7 +249,7 @@ size_t rpc_pton(const char *buf, const size_t buflen,
for (i = 0; i < buflen; i++)
if (buf[i] == ':')
- return rpc_pton6(buf, buflen, sap, salen);
+ return rpc_pton6(&init_net, buf, buflen, sap, salen);
return rpc_pton4(buf, buflen, sap, salen);
}
EXPORT_SYMBOL_GPL(rpc_pton);
^ permalink raw reply related
* [PATCH 1/4] SUNRPC: use passed network namespace context in rpc_parse_scope_id()
From: Stanislav Kinsbursky @ 2011-12-07 12:20 UTC (permalink / raw)
To: Trond.Myklebust
Cc: linux-nfs, xemul, neilb, netdev, linux-kernel, jbottomley,
bfields, davem, devel
In-Reply-To: <20111207111716.17273.63010.stgit@localhost6.localdomain6>
Use incomming network context in rpc_parse_scope_id() instead of hard-coded
"init_net".
Signed-off-by: Stanislav Kinsbursky <skinsbursky@parallels.com>
---
net/sunrpc/addr.c | 9 +++++----
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/net/sunrpc/addr.c b/net/sunrpc/addr.c
index 67a655e..35eb188 100644
--- a/net/sunrpc/addr.c
+++ b/net/sunrpc/addr.c
@@ -156,8 +156,9 @@ static size_t rpc_pton4(const char *buf, const size_t buflen,
}
#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
-static int rpc_parse_scope_id(const char *buf, const size_t buflen,
- const char *delim, struct sockaddr_in6 *sin6)
+static int rpc_parse_scope_id(struct net *net, const char *buf,
+ const size_t buflen, const char *delim,
+ struct sockaddr_in6 *sin6)
{
char *p;
size_t len;
@@ -177,7 +178,7 @@ static int rpc_parse_scope_id(const char *buf, const size_t buflen,
unsigned long scope_id = 0;
struct net_device *dev;
- dev = dev_get_by_name(&init_net, p);
+ dev = dev_get_by_name(net, p);
if (dev != NULL) {
scope_id = dev->ifindex;
dev_put(dev);
@@ -213,7 +214,7 @@ static size_t rpc_pton6(const char *buf, const size_t buflen,
if (in6_pton(buf, buflen, addr, IPV6_SCOPE_DELIMITER, &delim) == 0)
return 0;
- if (!rpc_parse_scope_id(buf, buflen, delim, sin6))
+ if (!rpc_parse_scope_id(&init_net, buf, buflen, delim, sin6))
return 0;
sin6->sin6_family = AF_INET6;
^ permalink raw reply related
* [PATCH 0/4] SUNRPC: pass network namespace context to sockaddr construction routines
From: Stanislav Kinsbursky @ 2011-12-07 12:20 UTC (permalink / raw)
To: Trond.Myklebust
Cc: linux-nfs, xemul, neilb, netdev, linux-kernel, jbottomley,
bfields, davem, devel
This is another precursor patch set aimed to remove hard-coded "init_net"
reference from SUNRPC sockaddr convertion and construction routines.
The following series consists of:
---
Stanislav Kinsbursky (4):
SUNRPC: use passed network namespace context in rpc_parse_scope_id()
SUNRPC: use passed network namespace context in rpc_pton6()
SUNRPC: use passed network namespace context in rpc_pton()
SUNRPC: use passed network namespace context in rpc_uaddr2sockaddr()
fs/nfs/dns_resolve.c | 4 ++--
fs/nfs/nfs4filelayoutdev.c | 2 +-
fs/nfs/nfs4namespace.c | 2 +-
fs/nfs/super.c | 4 ++--
fs/nfsd/nfs4state.c | 2 +-
fs/nfsd/nfsctl.c | 2 +-
include/linux/sunrpc/clnt.h | 4 ++--
net/sunrpc/addr.c | 24 +++++++++++++-----------
net/sunrpc/rpcb_clnt.c | 2 +-
net/sunrpc/svcauth_unix.c | 2 +-
10 files changed, 25 insertions(+), 23 deletions(-)
--
Signature
^ permalink raw reply
* Re: [net-next RFC PATCH 5/5] virtio-net: flow director support
From: Jason Wang @ 2011-12-07 12:10 UTC (permalink / raw)
To: Stefan Hajnoczi
Cc: krkumar2, kvm, mst, netdev, virtualization, levinsasha928,
bhutchings
In-Reply-To: <CAJSP0QUGWCf5WHEeCXzqZeF2CvpycxrGo-uPSfpWD1rWD3zeSg@mail.gmail.com>
On 12/07/2011 05:08 PM, Stefan Hajnoczi wrote:
[...]
>> > Consider the complexity of the host nic each with their own steering
>> > features, this series make the first step with minimal effort to try to let
>> > guest driver and host tap/macvtap co-operate like what physical nic does.
>> > There may be other method, but performance numbers is also needed to give
>> > the answer.
> I agree that performance results for this need to be shown.
>
> My original point is really that it's not a good idea to take
> individual steps without a good big picture because this will change
> the virtio-net device specification. If this turns out to be a dead
> end then hosts will need to continue to support the interface forever
> (legacy guests could still try to use it). So please first explain
> what the full stack picture is going to look like and how you think it
> will lead to better performance. You don't need to have all the code
> or evidence, but just enough explanation so we see where this is all
> going.
I think I mention too little in the cover message.
There's no much changes with Krishna's series except the method that
choosing a rx virtqueue. Since original series use different hash
methods in host (rxhash) and guest (txhash), a different virtqueue were
chose for a flow which could lead packets of a flow to be handled by
different vhost thread and vcpu. This may damage the performance.
This series tries to let one vhost thread to process the packets of a
flow and also let the packets to be sent directly to a vcpu local to the
thread process the data. This is done by letting guest tell the desired
queue form which it want to receive the pakcet of a dedicated flow.
So passing the hash from host to guest is needed to get the same hash in
the two sides. Then a guest programmable hash to queue table were
introduced and guest co-operate with the host through accelerate RFS in
guest.
^ permalink raw reply
* Re: [Bloat] Time in Queue, bufferbloat, and... our accidentally interplanetary network
From: Eric Dumazet @ 2011-12-07 11:53 UTC (permalink / raw)
To: Hagen Paul Pfeifer; +Cc: Dave Taht, linux-wireless, netdev, bloat-devel, bloat
In-Reply-To: <9dfc3c5eb811f2774b378fce0158b3e7@localhost>
Le mercredi 07 décembre 2011 à 11:15 +0100, Hagen Paul Pfeifer a écrit :
> On Mon, 05 Dec 2011 11:59:34 +0100, Eric Dumazet wrote:
>
>
> > Adding a time limit is possible, all we need is a proper design and
> > implementation :)
> >
> > Here is my suggestion :
> >
> > Design a new tfifo/tred qdisc, with following properties :
> >
> > Adaptative RED, (ECN enabled + head drop), but instead of using
> > bytes/packet qlen average, use time_in_queue average.
>
> Question one: is anything wrong with sfb or choke as the basis, instead of
> RED?
>
RED is the module to bring EWMA stuff, it seems natural to start with
it. Please note that choke has a RED module too.
Then later, we can add time limit stuff to other Qdisc if needed, its a
plug anyway. But is there any meaning to compute a global EWMA after
SFB/SFQ packet classification ?
> Question two: I submitted pfast_head_drop to drop more outdated data
> instead of new data. Back in time I thought TCP _may_ experience benefits
> because more up-to-date SACK data packets are saved. Are there any other
> TCP advantages with head drop policy?
>
Note that head drop is a consequence of time limit idea on top of FIFO,
since only at dequeue time, we compute the delta between current time
and enqueue time, and we drop/mark the (head) packet if time exceeds our
current limit.
In general, being able to drop/mark firsts packets in queue instead of
last ones can let TCP sender be notified of congestion much earlier than
a tail drop. (We gain the time to transmit whole packets in queue before
receiver can report in its ACK the congestion back to sender)
^ permalink raw reply
* *****HELLO==P/T 2011***OFFER ****
From: m.montel2011 @ 2011-12-07 11:24 UTC (permalink / raw)
You have been selected for an assignment as a M.y.s.tery S.h.o.pper
SURVEY.You will be earning $200 as a secret shopper for on each assignment
you carry out.
You would be given stores to evaluates.e.g.Victoria Secret, Amazon, E
bay,Rogers, Macy's, Gap, Lego, Wal Mart , Western Union outlet while you
conduct a simple survey
Your employment packet will include funds for the shopping and a training
assignment which will be sent to you after you receive payment for the
assignment. We will be responsible for all the finance required for
this survey as you are not required to drop and upfront money.
Note: You are to follow all instructions given to you to the fullest.
KINDLY SEND YOUR INFORMATION BELOW TO [ M.montel@blumail.org ].
ON FIRST ASSIGNMENT TO
Your Full Name:
Your Address (NOT P.O Box):
City, State, Zip:
Phone Number(s): Age:
Have you been to a wal-Mart® store before?
Email me back with the above details via the below email address;
Email: M.montel@blumail.org
Inc Copyright (c) 2011
All Rights Reserved.
Copyright 2011®
^ permalink raw reply
* Re: [net-next RFC PATCH 0/5] Series short description
From: Jason Wang @ 2011-12-07 11:31 UTC (permalink / raw)
To: Rusty Russell
Cc: krkumar2, kvm, mst, netdev, virtualization, levinsasha928,
bhutchings
In-Reply-To: <87ty5cj0sw.fsf@rustcorp.com.au>
On 12/07/2011 03:30 PM, Rusty Russell wrote:
> On Mon, 05 Dec 2011 16:58:37 +0800, Jason Wang<jasowang@redhat.com> wrote:
>> multiple queue virtio-net: flow steering through host/guest cooperation
>>
>> Hello all:
>>
>> This is a rough series adds the guest/host cooperation of flow
>> steering support based on Krish Kumar's multiple queue virtio-net
>> driver patch 3/3 (http://lwn.net/Articles/467283/).
> Is there a real (physical) device which does this kind of thing? How do
> they do it? Can we copy them?
>
> Cheers,
> Rusty.
As far as I see, ixgbe and sfc have similar but much more sophisticated
mechanism.
The idea was originally suggested by Ben and it was just borrowed form
those real physical nic cards who can dispatch packets based on their
hash. All of theses cards can filter the flow based on the hash of
L2/L3/L4 header and the stack would tell the card which queue should
this flow goes.
So in host, a simple hash to queue table were introduced in tap/macvtap
and in guest, the guest driver would tell the desired queue of a flow
through changing this table.
^ permalink raw reply
* Re: [PATCH] IPVS: Modify the SH scheduler to use weights
From: Pablo Neira Ayuso @ 2011-12-07 11:30 UTC (permalink / raw)
To: Simon Horman
Cc: Patrick McHardy, lvs-devel, netdev, netfilter-devel,
Wensong Zhang, Julian Anastasov, Michael Maxim
In-Reply-To: <1323245223-13646-2-git-send-email-horms@verge.net.au>
On Wed, Dec 07, 2011 at 05:07:03PM +0900, Simon Horman wrote:
> From: Michael Maxim <mike@okcupid.com>
>
> Modify the algorithm to build the source hashing hash table to add
> extra slots for destinations with higher weight. This has the effect
> of allowing an IPVS SH user to give more connections to hosts that
> have been configured to have a higher weight.
>
> Signed-off-by: Michael Maxim <mike@okcupid.com>
> Signed-off-by: Simon Horman <horms@verge.net.au>
> ---
> net/netfilter/ipvs/Kconfig | 15 +++++++++++++++
> net/netfilter/ipvs/ip_vs_sh.c | 20 ++++++++++++++++++--
> 2 files changed, 33 insertions(+), 2 deletions(-)
>
> diff --git a/net/netfilter/ipvs/Kconfig b/net/netfilter/ipvs/Kconfig
> index 70bd1d0..af4c0b8 100644
> --- a/net/netfilter/ipvs/Kconfig
> +++ b/net/netfilter/ipvs/Kconfig
> @@ -232,6 +232,21 @@ config IP_VS_NQ
> If you want to compile it in kernel, say Y. To compile it as a
> module, choose M here. If unsure, say N.
>
> +comment 'IPVS SH scheduler'
> +
> +config IP_VS_SH_TAB_BITS
> + int "IPVS source hashing table size (the Nth power of 2)"
> + range 4 20
> + default 8
> + ---help---
> + The source hashing scheduler maps source IPs to destinations
> + stored in a hash table. This table is tiled by each destination
> + until all slots in the table are filled. When using weights to
> + allow destinations to receive more connections, the table is
> + tiled an amount proportional to the weights specified. The table
> + needs to be large enough to effectively fit all the destinations
> + multiplied by their respective weights.
Hm, does this really belong to this patch?
> +
> comment 'IPVS application helper'
>
> config IP_VS_FTP
> diff --git a/net/netfilter/ipvs/ip_vs_sh.c b/net/netfilter/ipvs/ip_vs_sh.c
> index 33815f4..e0ca520 100644
> --- a/net/netfilter/ipvs/ip_vs_sh.c
> +++ b/net/netfilter/ipvs/ip_vs_sh.c
> @@ -30,6 +30,11 @@
> * server is dead or overloaded, the load balancer can bypass the cache
> * server and send requests to the original server directly.
> *
> + * The weight destination attribute can be used to control the
> + * distribution of connections to the destinations in servernode. The
> + * greater the weight, the more connections the destination
> + * will receive.
> + *
> */
>
> #define KMSG_COMPONENT "IPVS"
> @@ -99,9 +104,11 @@ ip_vs_sh_assign(struct ip_vs_sh_bucket *tbl, struct ip_vs_service *svc)
> struct ip_vs_sh_bucket *b;
> struct list_head *p;
> struct ip_vs_dest *dest;
> + int d_count;
>
> b = tbl;
> p = &svc->destinations;
> + d_count = 0;
> for (i=0; i<IP_VS_SH_TAB_SIZE; i++) {
> if (list_empty(p)) {
> b->dest = NULL;
> @@ -113,14 +120,23 @@ ip_vs_sh_assign(struct ip_vs_sh_bucket *tbl, struct ip_vs_service *svc)
> atomic_inc(&dest->refcnt);
> b->dest = dest;
>
> - p = p->next;
> + IP_VS_DBG_BUF(6, "assigned i: %d dest: %s weight: %d\n",
> + i, IP_VS_DBG_ADDR(svc->af, &dest->addr),
> + atomic_read(&dest->weight));
> +
> + /* Don't move to next dest until filling weight */
> + if (++d_count >= atomic_read(&dest->weight)) {
> + p = p->next;
> + d_count = 0;
> + }
> +
> }
> b++;
> }
> +
> return 0;
> }
>
> -
While at it, would you remove this unnecessary deletions/additions.
Thanks!
^ permalink raw reply
* [PATCH 4/4] SUNRPC: use passed network namespace context in rpc_uaddr2sockaddr()
From: Stanislav Kinsbursky @ 2011-12-07 12:20 UTC (permalink / raw)
To: Trond.Myklebust
Cc: linux-nfs, xemul, neilb, netdev, linux-kernel, jbottomley,
bfields, davem, devel
In-Reply-To: <20111207111716.17273.63010.stgit@localhost6.localdomain6>
Use incomming network context in rpc_uaddr2sockaddr() instead of hard-coded
"init_net".
Signed-off-by: Stanislav Kinsbursky <skinsbursky@parallels.com>
---
fs/nfsd/nfs4state.c | 2 +-
include/linux/sunrpc/clnt.h | 2 +-
net/sunrpc/addr.c | 8 +++++---
net/sunrpc/rpcb_clnt.c | 2 +-
4 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c
index 47e94e3..e18f46f 100644
--- a/fs/nfsd/nfs4state.c
+++ b/fs/nfsd/nfs4state.c
@@ -1301,7 +1301,7 @@ gen_callback(struct nfs4_client *clp, struct nfsd4_setclientid *se, struct svc_r
else
goto out_err;
- conn->cb_addrlen = rpc_uaddr2sockaddr(se->se_callback_addr_val,
+ conn->cb_addrlen = rpc_uaddr2sockaddr(&init_net, se->se_callback_addr_val,
se->se_callback_addr_len,
(struct sockaddr *)&conn->cb_addr,
sizeof(conn->cb_addr));
diff --git a/include/linux/sunrpc/clnt.h b/include/linux/sunrpc/clnt.h
index 877a466..029fb48 100644
--- a/include/linux/sunrpc/clnt.h
+++ b/include/linux/sunrpc/clnt.h
@@ -165,7 +165,7 @@ size_t rpc_ntop(const struct sockaddr *, char *, const size_t);
size_t rpc_pton(struct net *, const char *, const size_t,
struct sockaddr *, const size_t);
char * rpc_sockaddr2uaddr(const struct sockaddr *, gfp_t);
-size_t rpc_uaddr2sockaddr(const char *, const size_t,
+size_t rpc_uaddr2sockaddr(struct net *, const char *, const size_t,
struct sockaddr *, const size_t);
static inline unsigned short rpc_get_port(const struct sockaddr *sap)
diff --git a/net/sunrpc/addr.c b/net/sunrpc/addr.c
index 982fac7..bad31da 100644
--- a/net/sunrpc/addr.c
+++ b/net/sunrpc/addr.c
@@ -297,6 +297,7 @@ char *rpc_sockaddr2uaddr(const struct sockaddr *sap, gfp_t gfp_flags)
/**
* rpc_uaddr2sockaddr - convert a universal address to a socket address.
+ * @net: applicable network namespace
* @uaddr: C string containing universal address to convert
* @uaddr_len: length of universal address string
* @sap: buffer into which to plant socket address
@@ -308,8 +309,9 @@ char *rpc_sockaddr2uaddr(const struct sockaddr *sap, gfp_t gfp_flags)
* Returns the size of the socket address if successful; otherwise
* zero is returned.
*/
-size_t rpc_uaddr2sockaddr(const char *uaddr, const size_t uaddr_len,
- struct sockaddr *sap, const size_t salen)
+size_t rpc_uaddr2sockaddr(struct net *net, const char *uaddr,
+ const size_t uaddr_len, struct sockaddr *sap,
+ const size_t salen)
{
char *c, buf[RPCBIND_MAXUADDRLEN + sizeof('\0')];
unsigned long portlo, porthi;
@@ -341,7 +343,7 @@ size_t rpc_uaddr2sockaddr(const char *uaddr, const size_t uaddr_len,
port = (unsigned short)((porthi << 8) | portlo);
*c = '\0';
- if (rpc_pton(&init_net, buf, strlen(buf), sap, salen) == 0)
+ if (rpc_pton(net, buf, strlen(buf), sap, salen) == 0)
return 0;
switch (sap->sa_family) {
diff --git a/net/sunrpc/rpcb_clnt.c b/net/sunrpc/rpcb_clnt.c
index 8761bf8..42e1b2e 100644
--- a/net/sunrpc/rpcb_clnt.c
+++ b/net/sunrpc/rpcb_clnt.c
@@ -925,7 +925,7 @@ static int rpcb_dec_getaddr(struct rpc_rqst *req, struct xdr_stream *xdr,
dprintk("RPC: %5u RPCB_%s reply: %s\n", task->tk_pid,
task->tk_msg.rpc_proc->p_name, (char *)p);
- if (rpc_uaddr2sockaddr((char *)p, len, sap, sizeof(address)) == 0)
+ if (rpc_uaddr2sockaddr(&init_net, (char *)p, len, sap, sizeof(address)) == 0)
goto out_fail;
rpcb->r_port = rpc_get_port(sap);
^ permalink raw reply related
* Re: [PATCH][NET] several cleanups and bugfixes for fec.c: preserve MII/RMII setting in fec_stop()
From: Shawn Guo @ 2011-12-07 11:15 UTC (permalink / raw)
To: Lothar Waßmann; +Cc: netdev, Shawn Guo, linux-kernel, linux-arm-kernel
In-Reply-To: <20191.17573.87285.411253@ipc1.ka-ro>
On Wed, Dec 07, 2011 at 11:49:09AM +0100, Lothar Waßmann wrote:
> Hi,
>
> Shawn Guo writes:
> > On Wed, Dec 07, 2011 at 11:42:28AM +0100, Lothar Waßmann wrote:
> > > Hi,
> > >
> > > Shawn Guo writes:
> > > > On Tue, Dec 06, 2011 at 11:27:14AM +0100, Lothar Waßmann wrote:
> > > > > Additionally to setting the ETHER_EN bit in FEC_ECNTRL the MII/RMII
> > > > > setting in FEC_R_CNTRL needs to be preserved to keep the MII interface
> > > >
> > > > s/MII/RMII? From what I see from imx28 and imx6q RM, the reset state
> > > > for this setting is MII mode.
> > > >
> > > > > functional.
> > > > >
> > > > > Signed-off-by: Lothar Waßmann <LW@KARO-electronics.de>
> > > > > ---
> > > > > drivers/net/ethernet/freescale/fec.c | 5 ++++-
> > > > > 1 files changed, 4 insertions(+), 1 deletions(-)
> > > >
> > > > I assume this is fixing a problem you are seeing on imx28 only.
> > > > Do you see the problem on imx53/51?
> > > >
> > > No. i.MX53 uses the RMII gasket which is not affected by resetting the
> > > controller. And imMX51 does not support RMII at all.
> > >
> > > > >
> > > > > diff --git a/drivers/net/ethernet/freescale/fec.c b/drivers/net/ethernet/freescale/fec.c
> > > > > index 11534b9..ab0afb5 100644
> > > > > --- a/drivers/net/ethernet/freescale/fec.c
> > > > > +++ b/drivers/net/ethernet/freescale/fec.c
> > > > > @@ -515,6 +515,7 @@ fec_stop(struct net_device *ndev)
> > > > > struct fec_enet_private *fep = netdev_priv(ndev);
> > > > > const struct platform_device_id *id_entry =
> > > > > platform_get_device_id(fep->pdev);
> > > > > + u32 rmii_mode = readl(fep->hwp + FEC_R_CNTRL) & (1 << 8);
> > > >
> > > > This bit is only available on ENET (imx28 and imx6q). Do we want to
> > > > do the same thing for FEC (imx25/27/35/51/53)?
> > > >
> > > No. AFAICT that's not necessary there.
> > >
> > So you need to check it's actually running on ENET before accessing
> > the bit.
> >
> That's done in the place where the register is being written:
> | if (id_entry->driver_data & FEC_QUIRK_ENET_MAC) {
> | writel(2, fep->hwp + FEC_ECNTRL);
> | writel(rmii_mode, fep->hwp + FEC_R_CNTRL);
> | }
>
> We could save one register read by doing the check also for the read,
> but that would further complicate the code.
>
Ok. Will have a test and then get back to you.
--
Regards,
Shawn
^ permalink raw reply
* Re: [PATCH v8 0/9] per-cgroup tcp memory pressure controls
From: Glauber Costa @ 2011-12-07 11:06 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: lizf-BthXqXjhjHXQFUHtdCDX3A,
kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A,
ebiederm-aS9lmoZGLiVWk0Htik3J/w, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
gthelen-hpIqsD4AKlfQT0dZR+AlfA, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-mm-Bw31MaZKKs3YtjvyW6yDsg, kirill-oKw7cIdHH8eLwutG50LtGA,
avagin-bzQdu9zFT3WakBO8gow8eQ, devel-GEFAQzZX7r8dnm+yROfE0A,
eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w,
cgroups-u79uwXL29TY76Z2rM5mHXA, hannes-druUgvl0LCNAfugRpC6u6w,
mhocko-AlSwsSmVLrQ
In-Reply-To: <1323120903-2831-1-git-send-email-glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
On 12/05/2011 07:34 PM, Glauber Costa wrote:
> Hi,
>
> This is my new attempt to fix all the concerns that were raised during
> the last iteration.
>
> I should highlight:
> 1) proc information is kept intact. (although I kept the wrapper functions)
> it will be submitted as a follow up patch so it can get the attention it
> deserves
> 2) sockets now hold a reference to memcg. sockets can be alive even after the
> task is gone, so we don't bother with between cgroups movements.
> To be able to release resources more easily in this cenario, the parent
> pointer in struct cg_proto was replaced by a memcg object. We then iterate
> through its pointer (which is cleaner anyway)
>
> The rest should be mostly the same except for small fixes and style changes.
>
Kame,
Does this one address your previous concerns?
Thanks
--
To unsubscribe from this list: send the line "unsubscribe cgroups" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [net-next RFC PATCH 5/5] virtio-net: flow director support
From: Jason Wang @ 2011-12-07 11:05 UTC (permalink / raw)
To: Sridhar Samudrala
Cc: krkumar2, xma, kvm, Michael S. Tsirkin, virtualization,
levinsasha928, netdev, bhutchings
In-Reply-To: <4EDEA0E1.6020501@us.ibm.com>
On 12/07/2011 07:10 AM, Sridhar Samudrala wrote:
> On 12/6/2011 8:14 AM, Michael S. Tsirkin wrote:
>> On Tue, Dec 06, 2011 at 07:42:54AM -0800, Sridhar Samudrala wrote:
>>> On 12/6/2011 5:15 AM, Stefan Hajnoczi wrote:
>>>> On Tue, Dec 6, 2011 at 10:21 AM, Jason Wang<jasowang@redhat.com>
>>>> wrote:
>>>>> On 12/06/2011 05:18 PM, Stefan Hajnoczi wrote:
>>>>>> On Tue, Dec 6, 2011 at 6:33 AM, Jason
>>>>>> Wang<jasowang@redhat.com> wrote:
>>>>>>> On 12/05/2011 06:55 PM, Stefan Hajnoczi wrote:
>>>>>>>> On Mon, Dec 5, 2011 at 8:59 AM, Jason Wang<jasowang@redhat.com>
>>>>>>>> wrote:
>>>>>> The vcpus are just threads and may not be bound to physical CPUs, so
>>>>>> what is the big picture here? Is the guest even in the position to
>>>>>> set the best queue mappings today?
>>>>> Not sure it could publish the best mapping but the idea is to make
>>>>> sure the
>>>>> packets of a flow were handled by the same guest vcpu and may be
>>>>> the same
>>>>> vhost thread in order to eliminate the packet reordering and lock
>>>>> contention. But this assumption does not take the bouncing of
>>>>> vhost or vcpu
>>>>> threads which would also affect the result.
>>>> Okay, this is why I'd like to know what the big picture here is. What
>>>> solution are you proposing? How are we going to have everything from
>>>> guest application, guest kernel, host threads, and host NIC driver
>>>> play along so we get the right steering up the entire stack. I think
>>>> there needs to be an answer to that before changing virtio-net to add
>>>> any steering mechanism.
>>>>
>>>>
>>> Yes. Also the current model of a vhost thread per VM's interface
>>> doesn't help with packet steering
>>> all the way from the guest to the host physical NIC.
>>>
>>> I think we need to have vhost thread(s) per-CPU that can handle
>>> packets to/from physical NIC's
>>> TX/RX queues.
>>> Currently we have a single vhost thread for a VM's i/f
>>> that handles all the packets from
>>> various flows coming from a multi-queue physical NIC.
>>>
>>> Thanks
>>> Sridhar
>> It's not hard to try that:
>> 1. revert c23f3445e68e1db0e74099f264bc5ff5d55ebdeb
>> this will convert our thread to a workqueue
>> 2. convert the workqueue to a per-cpu one
>>
>> It didn't work that well in the past, but YMMV
> Yes. I tried this before we went ahead with per-interface vhost
> threading model.
> At that time, per-cpu vhost showed a regression with a single-VM and
> per-vq vhost showed good performance improvements upto 8 VMs.
>
> So just making it per-cpu would not be enough. I think we may need a way
> to schedule vcpu threads on the same cpu-socket as vhost.
>
> Another aspect we need to look into is the splitting of vhost thread
> into separate
> threads for TX and RX. Shirley is doing some work in this area and she
> is seeing
> perf. improvements as long as TX and RX threads are on the same
> cpu-socket.
I emulated this through my multi-queue series in the past, looks like it
damages the performance of single stream especially guest tx.
>>
>> On the surface I'd say a single thread makes some sense
>> as long as guest uses a single queue.
>>
> But this may not be scalable long term when we want to support a large
> number of VMs each
> having multiple virtio-net interfaces with multiple queues.
>
> Thanks
> Sridhar
>
^ permalink raw reply
* Re: [net-next RFC PATCH 5/5] virtio-net: flow director support
From: Jason Wang @ 2011-12-07 11:02 UTC (permalink / raw)
To: Sridhar Samudrala
Cc: krkumar2, kvm, mst, virtualization, levinsasha928, netdev,
bhutchings
In-Reply-To: <4EDE37FE.5090409@us.ibm.com>
On 12/06/2011 11:42 PM, Sridhar Samudrala wrote:
> On 12/6/2011 5:15 AM, Stefan Hajnoczi wrote:
>> On Tue, Dec 6, 2011 at 10:21 AM, Jason Wang<jasowang@redhat.com> wrote:
>>> On 12/06/2011 05:18 PM, Stefan Hajnoczi wrote:
>>>> On Tue, Dec 6, 2011 at 6:33 AM, Jason Wang<jasowang@redhat.com>
>>>> wrote:
>>>>> On 12/05/2011 06:55 PM, Stefan Hajnoczi wrote:
>>>>>> On Mon, Dec 5, 2011 at 8:59 AM, Jason Wang<jasowang@redhat.com>
>>>>>> wrote:
>>>> The vcpus are just threads and may not be bound to physical CPUs, so
>>>> what is the big picture here? Is the guest even in the position to
>>>> set the best queue mappings today?
>>>
>>> Not sure it could publish the best mapping but the idea is to make
>>> sure the
>>> packets of a flow were handled by the same guest vcpu and may be the
>>> same
>>> vhost thread in order to eliminate the packet reordering and lock
>>> contention. But this assumption does not take the bouncing of vhost
>>> or vcpu
>>> threads which would also affect the result.
>> Okay, this is why I'd like to know what the big picture here is. What
>> solution are you proposing? How are we going to have everything from
>> guest application, guest kernel, host threads, and host NIC driver
>> play along so we get the right steering up the entire stack. I think
>> there needs to be an answer to that before changing virtio-net to add
>> any steering mechanism.
>>
>>
> Yes. Also the current model of a vhost thread per VM's interface
> doesn't help with packet steering
> all the way from the guest to the host physical NIC.
>
> I think we need to have vhost thread(s) per-CPU that can handle
> packets to/from physical NIC's
> TX/RX queues. Currently we have a single vhost thread for a VM's i/f
> that handles all the packets from
> various flows coming from a multi-queue physical NIC.
Even if we have per-cpu workthread, only one socket is used to queue the
packet then, so a multiple queue(sockets) tap/macvtap is still needed.
>
> Thanks
> Sridhar
>
^ permalink raw reply
* Re: [PATCH][NET] several cleanups and bugfixes for fec.c: preserve MII/RMII setting in fec_stop()
From: Shawn Guo @ 2011-12-07 10:58 UTC (permalink / raw)
To: Lothar Waßmann; +Cc: netdev, Shawn Guo, linux-kernel, linux-arm-kernel
In-Reply-To: <20191.17172.493079.722098@ipc1.ka-ro>
On Wed, Dec 07, 2011 at 11:42:28AM +0100, Lothar Waßmann wrote:
> Hi,
>
> Shawn Guo writes:
> > On Tue, Dec 06, 2011 at 11:27:14AM +0100, Lothar Waßmann wrote:
> > > Additionally to setting the ETHER_EN bit in FEC_ECNTRL the MII/RMII
> > > setting in FEC_R_CNTRL needs to be preserved to keep the MII interface
> >
> > s/MII/RMII? From what I see from imx28 and imx6q RM, the reset state
> > for this setting is MII mode.
> >
> > > functional.
> > >
> > > Signed-off-by: Lothar Waßmann <LW@KARO-electronics.de>
> > > ---
> > > drivers/net/ethernet/freescale/fec.c | 5 ++++-
> > > 1 files changed, 4 insertions(+), 1 deletions(-)
> >
> > I assume this is fixing a problem you are seeing on imx28 only.
> > Do you see the problem on imx53/51?
> >
> No. i.MX53 uses the RMII gasket which is not affected by resetting the
> controller. And imMX51 does not support RMII at all.
>
> > >
> > > diff --git a/drivers/net/ethernet/freescale/fec.c b/drivers/net/ethernet/freescale/fec.c
> > > index 11534b9..ab0afb5 100644
> > > --- a/drivers/net/ethernet/freescale/fec.c
> > > +++ b/drivers/net/ethernet/freescale/fec.c
> > > @@ -515,6 +515,7 @@ fec_stop(struct net_device *ndev)
> > > struct fec_enet_private *fep = netdev_priv(ndev);
> > > const struct platform_device_id *id_entry =
> > > platform_get_device_id(fep->pdev);
> > > + u32 rmii_mode = readl(fep->hwp + FEC_R_CNTRL) & (1 << 8);
> >
> > This bit is only available on ENET (imx28 and imx6q). Do we want to
> > do the same thing for FEC (imx25/27/35/51/53)?
> >
> No. AFAICT that's not necessary there.
>
So you need to check it's actually running on ENET before accessing
the bit.
--
Regards,
Shawn
^ permalink raw reply
* Re: [PATCH][NET] several cleanups and bugfixes for fec.c: preserve MII/RMII setting in fec_stop()
From: Lothar Waßmann @ 2011-12-07 10:49 UTC (permalink / raw)
To: Shawn Guo; +Cc: netdev, Shawn Guo, linux-kernel, linux-arm-kernel
In-Reply-To: <20111207105816.GH5550@S2100-06.ap.freescale.net>
Hi,
Shawn Guo writes:
> On Wed, Dec 07, 2011 at 11:42:28AM +0100, Lothar Waßmann wrote:
> > Hi,
> >
> > Shawn Guo writes:
> > > On Tue, Dec 06, 2011 at 11:27:14AM +0100, Lothar Waßmann wrote:
> > > > Additionally to setting the ETHER_EN bit in FEC_ECNTRL the MII/RMII
> > > > setting in FEC_R_CNTRL needs to be preserved to keep the MII interface
> > >
> > > s/MII/RMII? From what I see from imx28 and imx6q RM, the reset state
> > > for this setting is MII mode.
> > >
> > > > functional.
> > > >
> > > > Signed-off-by: Lothar Waßmann <LW@KARO-electronics.de>
> > > > ---
> > > > drivers/net/ethernet/freescale/fec.c | 5 ++++-
> > > > 1 files changed, 4 insertions(+), 1 deletions(-)
> > >
> > > I assume this is fixing a problem you are seeing on imx28 only.
> > > Do you see the problem on imx53/51?
> > >
> > No. i.MX53 uses the RMII gasket which is not affected by resetting the
> > controller. And imMX51 does not support RMII at all.
> >
> > > >
> > > > diff --git a/drivers/net/ethernet/freescale/fec.c b/drivers/net/ethernet/freescale/fec.c
> > > > index 11534b9..ab0afb5 100644
> > > > --- a/drivers/net/ethernet/freescale/fec.c
> > > > +++ b/drivers/net/ethernet/freescale/fec.c
> > > > @@ -515,6 +515,7 @@ fec_stop(struct net_device *ndev)
> > > > struct fec_enet_private *fep = netdev_priv(ndev);
> > > > const struct platform_device_id *id_entry =
> > > > platform_get_device_id(fep->pdev);
> > > > + u32 rmii_mode = readl(fep->hwp + FEC_R_CNTRL) & (1 << 8);
> > >
> > > This bit is only available on ENET (imx28 and imx6q). Do we want to
> > > do the same thing for FEC (imx25/27/35/51/53)?
> > >
> > No. AFAICT that's not necessary there.
> >
> So you need to check it's actually running on ENET before accessing
> the bit.
>
That's done in the place where the register is being written:
| if (id_entry->driver_data & FEC_QUIRK_ENET_MAC) {
| writel(2, fep->hwp + FEC_ECNTRL);
| writel(rmii_mode, fep->hwp + FEC_R_CNTRL);
| }
We could save one register read by doing the check also for the read,
but that would further complicate the code.
Lothar Waßmann
--
___________________________________________________________
Ka-Ro electronics GmbH | Pascalstraße 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
Geschäftsführer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996
www.karo-electronics.de | info@karo-electronics.de
___________________________________________________________
^ permalink raw reply
* Re: [PATCH][NET] several cleanups and bugfixes for fec.c: preserve MII/RMII setting in fec_stop()
From: Lothar Waßmann @ 2011-12-07 10:42 UTC (permalink / raw)
To: Shawn Guo; +Cc: netdev, Shawn Guo, linux-kernel, linux-arm-kernel
In-Reply-To: <20111207094146.GG5550@S2100-06.ap.freescale.net>
Hi,
Shawn Guo writes:
> On Tue, Dec 06, 2011 at 11:27:14AM +0100, Lothar Waßmann wrote:
> > Additionally to setting the ETHER_EN bit in FEC_ECNTRL the MII/RMII
> > setting in FEC_R_CNTRL needs to be preserved to keep the MII interface
>
> s/MII/RMII? From what I see from imx28 and imx6q RM, the reset state
> for this setting is MII mode.
>
> > functional.
> >
> > Signed-off-by: Lothar Waßmann <LW@KARO-electronics.de>
> > ---
> > drivers/net/ethernet/freescale/fec.c | 5 ++++-
> > 1 files changed, 4 insertions(+), 1 deletions(-)
>
> I assume this is fixing a problem you are seeing on imx28 only.
> Do you see the problem on imx53/51?
>
No. i.MX53 uses the RMII gasket which is not affected by resetting the
controller. And imMX51 does not support RMII at all.
> >
> > diff --git a/drivers/net/ethernet/freescale/fec.c b/drivers/net/ethernet/freescale/fec.c
> > index 11534b9..ab0afb5 100644
> > --- a/drivers/net/ethernet/freescale/fec.c
> > +++ b/drivers/net/ethernet/freescale/fec.c
> > @@ -515,6 +515,7 @@ fec_stop(struct net_device *ndev)
> > struct fec_enet_private *fep = netdev_priv(ndev);
> > const struct platform_device_id *id_entry =
> > platform_get_device_id(fep->pdev);
> > + u32 rmii_mode = readl(fep->hwp + FEC_R_CNTRL) & (1 << 8);
>
> This bit is only available on ENET (imx28 and imx6q). Do we want to
> do the same thing for FEC (imx25/27/35/51/53)?
>
No. AFAICT that's not necessary there.
> > /* We cannot expect a graceful transmit stop without link !!! */
> > if (fep->link) {
> > @@ -531,8 +532,10 @@ fec_stop(struct net_device *ndev)
> > writel(FEC_DEFAULT_IMASK, fep->hwp + FEC_IMASK);
> >
> > /* We have to keep ENET enabled to have MII interrupt stay working */
> > - if (id_entry->driver_data & FEC_QUIRK_ENET_MAC)
> > + if (id_entry->driver_data & FEC_QUIRK_ENET_MAC) {
> > writel(2, fep->hwp + FEC_ECNTRL);
> > + writel(rmii_mode, fep->hwp + FEC_R_CNTRL);
> > + }
> > }
>
> On imx6q, we have two bits, bit 6 and 8 of FEC_R_CNTRL, to select MII
> interface among MII, RMII and RGMII modes. I'm not sure if we will
> run into the same problem for RGMII mode. What's your test setup?
> I would try to reproduce it here.
>
I'm using a TX28 which has the Ethernet PHY connected in RMII
mode. You should see the problem, if you unplug the ethernet cable on
a configured link. Without this patch the kernel will not detect when
the cable is plugged back in.
Lothar Waßmann
--
___________________________________________________________
Ka-Ro electronics GmbH | Pascalstraße 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
Geschäftsführer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996
www.karo-electronics.de | info@karo-electronics.de
___________________________________________________________
^ permalink raw reply
* Re: [net-next RFC PATCH 0/5] Series short description
From: Rusty Russell @ 2011-12-07 7:30 UTC (permalink / raw)
To: Jason Wang, krkumar2, kvm, mst, netdev, virtualization,
levinsasha928, bhutchings
In-Reply-To: <20111205085603.6116.65101.stgit@dhcp-8-146.nay.redhat.com>
On Mon, 05 Dec 2011 16:58:37 +0800, Jason Wang <jasowang@redhat.com> wrote:
> multiple queue virtio-net: flow steering through host/guest cooperation
>
> Hello all:
>
> This is a rough series adds the guest/host cooperation of flow
> steering support based on Krish Kumar's multiple queue virtio-net
> driver patch 3/3 (http://lwn.net/Articles/467283/).
Is there a real (physical) device which does this kind of thing? How do
they do it? Can we copy them?
Cheers,
Rusty.
^ permalink raw reply
* Re: atl1c: WARNING: at net/sched/sch_generic.c:255 dev_watchdog
From: Timur Irmatov @ 2011-12-07 10:25 UTC (permalink / raw)
To: netdev
In-Reply-To: <CA+5PVA7bM8ZGaCiyZdHcMVccJYh2=bk-gsHLo9ZmBP_SYT208w@mail.gmail.com>
On Wed, Dec 7, 2011 at 5:12 AM, Josh Boyer <jwboyer@gmail.com> wrote:
> Matthew Garrett has a patch to the atl1c driver that changed it's ASPM
> behavior that seemed to help. Dave Miller applied it, but I don't see
> it in linux-next for some reason.
>
> http://comments.gmane.org/gmane.linux.kernel/1214694
May be this is the reason?
http://article.gmane.org/gmane.linux.kernel/1215132/
I'm also having this issue and can test patches.
--
Timur Irmatov, xmpp:irmatov@jabber.ru
^ permalink raw reply
* Re: Time in Queue, bufferbloat, and... our accidentally interplanetary network
From: Hagen Paul Pfeifer @ 2011-12-07 10:19 UTC (permalink / raw)
To: Hagen Paul Pfeifer
Cc: linux-wireless, netdev-u79uwXL29TY76Z2rM5mHXA, bloat-devel, bloat
In-Reply-To: <9dfc3c5eb811f2774b378fce0158b3e7@localhost>
On Wed, 07 Dec 2011 11:15:38 +0100, Hagen Paul Pfeifer <hagen-GvnIQ6b/HdU@public.gmane.org>
wrote:
> Question two: I submitted pfast_head_drop to drop more outdated data
> instead of new data. Back in time I thought TCP _may_ experience
benefits
> because more up-to-date SACK data packets are saved. Are there any other
> TCP advantages with head drop policy?
Small comment: pfast_head_drop was intended for UDP. E.g. OLSR messages,
regular GPS reporting and the like. TCP was not the focus at that time.
HGN
^ permalink raw reply
* Re: Time in Queue, bufferbloat, and... our accidentally interplanetary network
From: Hagen Paul Pfeifer @ 2011-12-07 10:15 UTC (permalink / raw)
To: Eric Dumazet
Cc: bloat-devel, netdev-u79uwXL29TY76Z2rM5mHXA, linux-wireless, bloat
In-Reply-To: <1323082774.2670.40.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
On Mon, 05 Dec 2011 11:59:34 +0100, Eric Dumazet wrote:
> Adding a time limit is possible, all we need is a proper design and
> implementation :)
>
> Here is my suggestion :
>
> Design a new tfifo/tred qdisc, with following properties :
>
> Adaptative RED, (ECN enabled + head drop), but instead of using
> bytes/packet qlen average, use time_in_queue average.
Question one: is anything wrong with sfb or choke as the basis, instead of
RED?
Question two: I submitted pfast_head_drop to drop more outdated data
instead of new data. Back in time I thought TCP _may_ experience benefits
because more up-to-date SACK data packets are saved. Are there any other
TCP advantages with head drop policy?
Hagen
^ 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