* [PATCH 6/7] drivers/net/ethernet/broadcom/cnic.c: remove invalid reference to list iterator variable
From: Julia Lawall @ 2012-07-08 11:37 UTC (permalink / raw)
To: netdev; +Cc: kernel-janitors, linux-kernel
In-Reply-To: <1341747464-1772-1-git-send-email-Julia.Lawall@lip6.fr>
From: Julia Lawall <Julia.Lawall@lip6.fr>
If list_for_each_entry, etc complete a traversal of the list, the iterator
variable ends up pointing to an address at an offset from the list head,
and not a meaningful structure. Thus this value should not be used after
the end of the iterator. There does not seem to be a meaningful value to
provide to netdev_warn. Replace with pr_warn, since pr_err is used
elsewhere.
This problem was found using Coccinelle (http://coccinelle.lip6.fr/).
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
---
drivers/net/ethernet/broadcom/cnic.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/broadcom/cnic.c b/drivers/net/ethernet/broadcom/cnic.c
index 22ad7b6..6eaca60 100644
--- a/drivers/net/ethernet/broadcom/cnic.c
+++ b/drivers/net/ethernet/broadcom/cnic.c
@@ -542,7 +542,8 @@ int cnic_unregister_driver(int ulp_type)
}
if (atomic_read(&ulp_ops->ref_count) != 0)
- netdev_warn(dev->netdev, "Failed waiting for ref count to go to zero\n");
+ pr_warn("%s: Failed waiting for ref count to go to zero\n",
+ __func__);
return 0;
out_unlock:
^ permalink raw reply related
* Re: [net-next patch] bnx2x: Add run-time CNIC support
From: David Miller @ 2012-07-08 12:15 UTC (permalink / raw)
To: meravs; +Cc: netdev, eilong, dmitry
In-Reply-To: <1341745239.27284.13.camel@lb-tlvb-meravs.il.broadcom.com>
From: "Merav Sicron" <meravs@broadcom.com>
Date: Sun, 8 Jul 2012 14:00:39 +0300
> static int set_is_cnic_enabled(bool is_vf)
> {
> if (is_vf)
> return 0;
> #if defined(CONFIG_CNIC) || defined(CONFIG_CNIC_MODULE)
> return 1;
> #else
> return 0;
> #endif
> }
I still think this is beyond ugly.
This ifdef just wants to die completely. It serves no real
purpose as every distribution vendor that turns on your driver
will turn CNIC on as well.
And you have to address the lost of const'ness of the netdevice ops.
If you absolutely must have runtime method choices, you must use
multiple instances of netdevice ops and assign the appropriate one.
^ permalink raw reply
* Re: [PATCH v5 4/7] ARM: davinci: net: davinci_emac: add OF support
From: Sekhar Nori @ 2012-07-08 14:26 UTC (permalink / raw)
To: Heiko Schocher
Cc: davinci-linux-open-source-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/,
Wolfgang Denk, netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ, Anatoly Sivov,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1338373143-7467-5-git-send-email-hs-ynQEQJNshbs@public.gmane.org>
Hi Heiko,
On 5/30/2012 3:49 PM, Heiko Schocher wrote:
> add of support for the davinci_emac driver.
>
> Signed-off-by: Heiko Schocher <hs-ynQEQJNshbs@public.gmane.org>
> Cc: davinci-linux-open-source-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/@public.gmane.org
> Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
> Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Cc: Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
> Cc: Sekhar Nori <nsekhar-l0cyMroinI0@public.gmane.org>
> Cc: Wolfgang Denk <wd-ynQEQJNshbs@public.gmane.org>
> Cc: Anatoly Sivov <mm05-JGs/UdohzUI@public.gmane.org>
>
> ---
> +#ifdef CONFIG_OF
> +static struct emac_platform_data
> + *davinci_emac_of_get_pdata(struct platform_device *pdev,
> + struct emac_priv *priv)
> +{
> + struct device_node *np;
> + struct emac_platform_data *pdata = NULL;
> + const u8 *mac_addr;
> + u32 data;
> + int ret;
> +
> + pdata = pdev->dev.platform_data;
> + if (!pdata) {
> + pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);
> + if (!pdata)
> + goto nodata;
> + }
> +
> + np = pdev->dev.of_node;
> + if (!np)
> + goto nodata;
> + else
> + pdata->version = EMAC_VERSION_2;
> +
> + mac_addr = of_get_mac_address(np);
> + if (mac_addr)
> + memcpy(pdata->mac_addr, mac_addr, ETH_ALEN);
I suspect that even in the DT case, many boards will continue to
read mac address from on-board EEPROMs or from an on-chip eFUSE.
To take care of such cases, I propose use mac address in DT data
only if no valid address is passed through platform data. The
attached patch does this change.
If you are OK with this modification, can you please merge it and
repost just this patch for review? Please CC David Miller
(davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org) on your next post as he is the netdev maintainer
and this patch needs to be merged through him or at least needs his ack.
With this modification, you can add my:
Acked-by: Sekhar Nori <nsekhar-l0cyMroinI0@public.gmane.org>
Thanks,
Sekhar
---8<----
diff --git a/drivers/net/ethernet/ti/davinci_emac.c b/drivers/net/ethernet/ti/davinci_emac.c
index 645618d..6b4b0fe 100644
--- a/drivers/net/ethernet/ti/davinci_emac.c
+++ b/drivers/net/ethernet/ti/davinci_emac.c
@@ -1795,9 +1795,11 @@ static struct emac_platform_data
else
pdata->version = EMAC_VERSION_2;
- mac_addr = of_get_mac_address(np);
- if (mac_addr)
- memcpy(pdata->mac_addr, mac_addr, ETH_ALEN);
+ if (!is_valid_ether_addr(pdata->mac_addr)) {
+ mac_addr = of_get_mac_address(np);
+ if (mac_addr)
+ memcpy(pdata->mac_addr, mac_addr, ETH_ALEN);
+ }
ret = of_property_read_u32(np, "ti,davinci-ctrl-reg-offset", &data);
if (!ret)
^ permalink raw reply related
* Re: [PATCH 4/4] asix: Add a new driver for the AX88172A
From: Ben Hutchings @ 2012-07-08 15:50 UTC (permalink / raw)
To: michael
Cc: Christian Riesch, netdev, Oliver Neukum, Eric Dumazet, Allan Chou,
Mark Lord, Grant Grundler, Ming Lei
In-Reply-To: <1341761975.2038.28.camel@schesaplana>
On Sun, 2012-07-08 at 17:39 +0200, Michael Riesch wrote:
> On Fri, 2012-07-06 at 18:37 +0100, Ben Hutchings wrote:
> > > + priv->mdio->priv = (void *)dev;
> > > + priv->mdio->read = &asix_mdio_bus_read;
> > > + priv->mdio->write = &asix_mdio_bus_write;
> > > + priv->mdio->name = "Asix MDIO Bus";
> > > + snprintf(priv->mdio->id, MII_BUS_ID_SIZE, "asix-%s",
> > > + dev_name(dev->net->dev.parent));
> > [...]
> >
> > I think you need to ensure that the bus identifier is unique throughout
> > its lifetime, but net devices can be renamed and that could lead to a
> > collision. Perhaps you could use the ifindex or the USB device path
>
> Ben,
>
> the dev_name function in the code above returns the sysfs filename of
> the USB device (e.g. 1-0:1.0).
[...]
Sorry, I didn't read that carefully enough.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH 4/4] asix: Add a new driver for the AX88172A
From: Michael Riesch @ 2012-07-08 15:39 UTC (permalink / raw)
To: Ben Hutchings
Cc: Christian Riesch, netdev, Oliver Neukum, Eric Dumazet, Allan Chou,
Mark Lord, Grant Grundler, Ming Lei
In-Reply-To: <1341596255.2923.7.camel@bwh-desktop.uk.solarflarecom.com>
On Fri, 2012-07-06 at 18:37 +0100, Ben Hutchings wrote:
> > + priv->mdio->priv = (void *)dev;
> > + priv->mdio->read = &asix_mdio_bus_read;
> > + priv->mdio->write = &asix_mdio_bus_write;
> > + priv->mdio->name = "Asix MDIO Bus";
> > + snprintf(priv->mdio->id, MII_BUS_ID_SIZE, "asix-%s",
> > + dev_name(dev->net->dev.parent));
> [...]
>
> I think you need to ensure that the bus identifier is unique throughout
> its lifetime, but net devices can be renamed and that could lead to a
> collision. Perhaps you could use the ifindex or the USB device path
Ben,
the dev_name function in the code above returns the sysfs filename of
the USB device (e.g. 1-0:1.0).
> (though that might be too long).
This may be a problem. The bus identifier may be 17 characters long, so
if we leave the endpoint/configuration part (:1.0) and the prefix away
it should be fine in any "normal" system. However, on a system with a
more-than-9-root-hubs 5-tier 127-devices-each USB infrastructure it
results in collisions. So is this approach acceptable?
Using the ifindex sounds good to me,
snprintf(priv->mdio->id, MII_BUS_ID_SIZE, "asix-%d",
dev->net->ifindex);
works on any system with less than 10^12 network interfaces.
Regards,
Michael
^ permalink raw reply
* [PATCH] r6040: use module_pci_driver macro
From: Devendra Naga @ 2012-07-08 15:57 UTC (permalink / raw)
To: Florian Fainelli, netdev; +Cc: Devendra Naga
as the manual of module_pci_driver says that
it can be used when the init and exit functions of
the module does nothing but the pci_register_driver
and pci_unregister_driver.
use it for rdc's r6040 driver, as the init and exit
paths does as above, and also this reduces a little
amount of code.
Signed-off-by: Devendra Naga <devendra.aaru@gmail.com>
---
drivers/net/ethernet/rdc/r6040.c | 15 +--------------
1 file changed, 1 insertion(+), 14 deletions(-)
diff --git a/drivers/net/ethernet/rdc/r6040.c b/drivers/net/ethernet/rdc/r6040.c
index 9acc026..557a265 100644
--- a/drivers/net/ethernet/rdc/r6040.c
+++ b/drivers/net/ethernet/rdc/r6040.c
@@ -1277,17 +1277,4 @@ static struct pci_driver r6040_driver = {
.remove = __devexit_p(r6040_remove_one),
};
-
-static int __init r6040_init(void)
-{
- return pci_register_driver(&r6040_driver);
-}
-
-
-static void __exit r6040_cleanup(void)
-{
- pci_unregister_driver(&r6040_driver);
-}
-
-module_init(r6040_init);
-module_exit(r6040_cleanup);
+module_pci_driver(r6040_driver);
--
1.7.9.5
^ permalink raw reply related
* Re: BISECTED: Re: REGRESSION: 3.4.0->3.5.0-rc2 kernel WARNING on cable plug on Acer Aspire One, no network
From: Alex Villacís Lasso @ 2012-07-08 17:14 UTC (permalink / raw)
To: Marek Szyprowski; +Cc: 'Francois Romieu', netdev
In-Reply-To: <012601cd5a7b$886fd4c0$994f7e40$%szyprowski@samsung.com>
El 05/07/12 01:58, Marek Szyprowski escribió:
> Hello,
>
> On Thursday, July 05, 2012 6:15 AM Alex Villacís Lasso wrote:
>
>> El 04/07/12 02:02, Marek Szyprowski escribió:
>>> Hello,
>>>
>>> On Tuesday, July 03, 2012 4:27 PM Alex Villací¬s Lasso wrote:
>>>
>>>> El 03/07/12 00:40, Marek Szyprowski escribió:
>>>>> Hi Alex,
>>>>>
>>>>> On Tuesday, July 03, 2012 4:45 AM Alex Villacís Lasso wrote:
>>>>>
>>>>>> -------- Mensaje original --------
>>>>>> Asunto: BISECTED: Re: REGRESSION: 3.4.0->3.5.0-rc2 kernel WARNING on cable
>>>>>> plug on Acer Aspire One, no network Fecha: Mon, 02 Jul 2012 21:33:41 -0500 De:
>>>>>> Alex Villacís Lasso <a_villacis@palosanto.com> Para: Francois Romieu
>>>>>> <romieu@fr.zoreil.com> CC: netdev@vger.kernel.org
>>>>>> El 01/07/12 08:50, Alex Villacís Lasso escribió:
>>>>>>> El 11/06/12 16:38, Francois Romieu escribió:
>>>>>>>> Alex Villacís Lasso <a_villacis@palosanto.com> :
>>>>>>>> [...]
>>>>>>>>> $ grep XID dmesg-3.5.0-rc2.txt
>>>>>>>>> [ 15.873858] r8169 0000:02:00.0: eth0: RTL8102e at 0xf7c0e000,
>>>>>>>>> 00:1e:68:e5:5d:b1, XID 04a00000 IRQ 44
>>>>>>>> The 8102e has not been touched by that many suspect patches but I do
>>>>>>>> not see where the problem is :o(
>>>>>>>>
>>>>>>>> Can you peel off the r8169 patches between 3.4.0 and 3.5-rc ?
>>>>>>>>
>>>>>>> Still present in 3.5-rc5. Bisection still in progress.
>>>>>>>
>>>>>>> --
>>>>>>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>>>>>>> the body of a message to majordomo@vger.kernel.org
>>>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>>> My full bisection points to this commit:
>>>>>>
>>>>>> commit 0a2b9a6ea93650b8a00f9fd5ee8fdd25671e2df6
>>>>>> Author: Marek Szyprowski <m.szyprowski@samsung.com>
>>>>>> Date: Thu Dec 29 13:09:51 2011 +0100
>>>>>>
>>>>>> X86: integrate CMA with DMA-mapping subsystem
>>>>>>
>>>>>> This patch adds support for CMA to dma-mapping subsystem for x86
>>>>>> architecture that uses common pci-dma/pci-nommu implementation. This
>>>>>> allows to test CMA on KVM/QEMU and a lot of common x86 boxes.
>>>>>>
>>>>>> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
>>>>>> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
>>>>>> CC: Michal Nazarewicz <mina86@mina86.com>
>>>>>> Acked-by: Arnd Bergmann <arnd@arndb.de>
>>>>>>
>>>>>> Is this commit somehow messing with the network card DMA?
>>>>> This commit in fact touches DMA-mapping subsystem and introduces a bug,
>>>>> which has been finally fixed by commit c080e26edc3a2a3 merged to v3.5-rc3.
>>>>> After applying it the DMA-mapping subsystem should work exactly the same was
>>>>> as in v3.4. Could you please check if it fixes this issue?
>>>>>
>>>>> Best regards
>>>> No. It still fails in 3.5-rc5, as mentioned before.
>>> Hmm. I was a bit confused, because both the subject and git bisect log pointed to v3.5-rc2,
>>> which had that bug. Maybe there is one some other issue present in v3.5-rc5 not related to
>>> my patches?
>>>
>>> Could you check with v3.5-rc5 if reverting patch c080e26edc3a2a3cdfa4c430c663ee1c3bbd8fae
>>> and 0a2b9a6ea93650b8a00f9fd5ee8fdd25671e2df6 fixes the problems with rtl driver?
>>>
>>> Best regards
>> Reverting the two patches indeed fixes the bug on -rc5.
> That's really strange. Could you check if you have CMA disabled in the config? After preparing
> a c080e26edc3a2a3cdfa4c430c663ee1c3bbd8fae fixup patch, I was really convinced that there are
> no functional changes in x86 dma mapping code when CMA is disabled. I will provide some
> patches to revert different parts of my changes, so we will find which line causes issues.
>
> Best regards
I checked out v3.5-rc6 from git, without reverting any patches. I then
compiled this release with my old config and verified the bug is
currently fixed.
^ permalink raw reply
* Re: [PATCH 04/16] mm: allow PF_MEMALLOC from softirq context
From: Sebastian Andrzej Siewior @ 2012-07-08 18:12 UTC (permalink / raw)
To: Mel Gorman
Cc: Andrew Morton, Linux-MM, Linux-Netdev, LKML, David Miller,
Neil Brown, Peter Zijlstra, Mike Christie, Eric B Munson,
Eric Dumazet
In-Reply-To: <20120627082614.GE8271@suse.de>
On Wed, Jun 27, 2012 at 09:26:14AM +0100, Mel Gorman wrote:
> > > diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> > > index b6c0727..5c6d9c6 100644
> > > --- a/mm/page_alloc.c
> > > +++ b/mm/page_alloc.c
> > > @@ -2265,7 +2265,11 @@ gfp_to_alloc_flags(gfp_t gfp_mask)
> > > if (likely(!(gfp_mask & __GFP_NOMEMALLOC))) {
> > > if (gfp_mask & __GFP_MEMALLOC)
> > > alloc_flags |= ALLOC_NO_WATERMARKS;
> > > - else if (likely(!(gfp_mask & __GFP_NOMEMALLOC)) && !in_interrupt())
> > > + else if (in_serving_softirq() && (current->flags & PF_MEMALLOC))
> > > + alloc_flags |= ALLOC_NO_WATERMARKS;
> > > + else if (!in_interrupt() &&
> > > + ((current->flags & PF_MEMALLOC) ||
> > > + unlikely(test_thread_flag(TIF_MEMDIE))))
> > > alloc_flags |= ALLOC_NO_WATERMARKS;
> > > }
> >
> > You allocate in RX path with __GFP_MEMALLOC and your sk->sk_allocation has
> > also __GFP_MEMALLOC set. That means you should get ALLOC_NO_WATERMARKS in
> > alloc_flags.
>
> In the cases where they are annotated correctly, yes. It is recordeed if
> the page gets allocated from the PFMEMALLOC reserves. If the received
> packet is not SOCK_MEMALLOC and the page was allocated from PFMEMALLOC
> reserves it is then discarded and the packet must be retransmitted.
Let me try again:
- lets assume your allocation happens with alloc_page(), without
__GFP_MEMALLOC in GFP_FLAGS and with PF_MEMALLOC in current->flags. Now
you may get memory which you wouldn't receive otherwise (without
PF_MEMALLOC). Okay, understood. So you don't have to annotate each page
allocation in your receive path for instance as long as the process has the
flag set.
- lets assume your allocation happens with kmalloc() without __GFP_MEMALLOC
and current->flags has PF_MEMALLOC ORed and your SLAB pool is empty. This
forces SLAB to allocate more pages from the buddy allocator with it will
receive more likely (due to ->current->flags + PF_MEMALLOC) but SLAB will
drop this extra memory because the page has ->pf_memory (or something like
that) set and the GFP_FLAGS do not have __GFP_MEMALLOC set.
Is there something I missed?
Sebastian
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH v2] cgroup: fix panic in netprio_cgroup
From: Eric Dumazet @ 2012-07-08 19:50 UTC (permalink / raw)
To: Gao feng, nhorman; +Cc: davem, netdev, linux-kernel, tj, lizefan
In-Reply-To: <1341480520-25081-1-git-send-email-gaofeng@cn.fujitsu.com>
On Thu, 2012-07-05 at 17:28 +0800, Gao feng wrote:
> we set max_prioidx to the first zero bit index of prioidx_map in
> function get_prioidx.
>
> So when we delete the low index netprio cgroup and adding a new
> netprio cgroup again,the max_prioidx will be set to the low index.
>
> when we set the high index cgroup's net_prio.ifpriomap,the function
> write_priomap will call update_netdev_tables to alloc memory which
> size is sizeof(struct netprio_map) + sizeof(u32) * (max_prioidx + 1),
> so the size of array that map->priomap point to is max_prioidx +1,
> which is low than what we actually need.
>
> fix this by adding check in get_prioidx,only set max_prioidx when
> max_prioidx low than the new prioidx.
>
> Signed-off-by: Gao feng <gaofeng@cn.fujitsu.com>
> ---
> net/core/netprio_cgroup.c | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/net/core/netprio_cgroup.c b/net/core/netprio_cgroup.c
> index 5b8aa2f..aa907ed 100644
> --- a/net/core/netprio_cgroup.c
> +++ b/net/core/netprio_cgroup.c
> @@ -49,8 +49,9 @@ static int get_prioidx(u32 *prio)
> return -ENOSPC;
> }
> set_bit(prioidx, prioidx_map);
> + if (atomic_read(&max_prioidx) < prioidx)
> + atomic_set(&max_prioidx, prioidx);
> spin_unlock_irqrestore(&prioidx_map_lock, flags);
> - atomic_set(&max_prioidx, prioidx);
> *prio = prioidx;
> return 0;
> }
This patch seems fine to me.
Acked-by: Eric Dumazet <edumazet@google.com>
Neil, looking at this file, I believe something is wrong.
dev->priomap is allocated by extend_netdev_table() called from
update_netdev_tables(). And this is only called if write_priomap() is
called.
But if write_priomap() is not called, it seems we can have out of bounds
accesses in cgrp_destroy() and read_priomap()
What do you think of following patch ?
diff --git a/net/core/netprio_cgroup.c b/net/core/netprio_cgroup.c
index 5b8aa2f..80150d2 100644
--- a/net/core/netprio_cgroup.c
+++ b/net/core/netprio_cgroup.c
@@ -141,7 +141,7 @@ static void cgrp_destroy(struct cgroup *cgrp)
rtnl_lock();
for_each_netdev(&init_net, dev) {
map = rtnl_dereference(dev->priomap);
- if (map)
+ if (map && cs->prioidx < map->priomap_len)
map->priomap[cs->prioidx] = 0;
}
rtnl_unlock();
@@ -165,7 +165,7 @@ static int read_priomap(struct cgroup *cont, struct cftype *cft,
rcu_read_lock();
for_each_netdev_rcu(&init_net, dev) {
map = rcu_dereference(dev->priomap);
- priority = map ? map->priomap[prioidx] : 0;
+ priority = (map && prioidx < map->priomap_len) ? map->priomap[prioidx] : 0;
cb->fill(cb, dev->name, priority);
}
rcu_read_unlock();
^ permalink raw reply related
* Re: [PATCH] r6040: use module_pci_driver macro
From: Florian Fainelli @ 2012-07-08 21:39 UTC (permalink / raw)
To: Devendra Naga; +Cc: netdev
In-Reply-To: <1341763077-938-1-git-send-email-devendra.aaru@gmail.com>
Le dimanche 08 juillet 2012 17:57:57, Devendra Naga a écrit :
> as the manual of module_pci_driver says that
> it can be used when the init and exit functions of
> the module does nothing but the pci_register_driver
> and pci_unregister_driver.
>
> use it for rdc's r6040 driver, as the init and exit
> paths does as above, and also this reduces a little
> amount of code.
>
> Signed-off-by: Devendra Naga <devendra.aaru@gmail.com>
Acked-by: Florian Fainelli <florian@openwrt.org>
> ---
> drivers/net/ethernet/rdc/r6040.c | 15 +--------------
> 1 file changed, 1 insertion(+), 14 deletions(-)
>
> diff --git a/drivers/net/ethernet/rdc/r6040.c
> b/drivers/net/ethernet/rdc/r6040.c index 9acc026..557a265 100644
> --- a/drivers/net/ethernet/rdc/r6040.c
> +++ b/drivers/net/ethernet/rdc/r6040.c
> @@ -1277,17 +1277,4 @@ static struct pci_driver r6040_driver = {
> .remove = __devexit_p(r6040_remove_one),
> };
>
> -
> -static int __init r6040_init(void)
> -{
> - return pci_register_driver(&r6040_driver);
> -}
> -
> -
> -static void __exit r6040_cleanup(void)
> -{
> - pci_unregister_driver(&r6040_driver);
> -}
> -
> -module_init(r6040_init);
> -module_exit(r6040_cleanup);
> +module_pci_driver(r6040_driver);
--
Florian
^ permalink raw reply
* [RFC PATCH] ppp: add support for L2 multihop / tunnel switching
From: Benjamin LaHaise @ 2012-07-08 21:49 UTC (permalink / raw)
To: netdev, linux-ppp
Hello folks,
Below is a first cut at implementing multihop L2TP, also known as tunnel
switching. The feature is similar in scope to how PPPoE relaying works --
L2 packets that are received on one PPP interface are forwarded to another.
This feature is typically used for traffic aggregation and backhaul for
ISPs, with incoming sessions (often PPPoE) being partially authenticated
by a LAC, and then forwarded over an L2TP session to an LNS (selected by the
user's domain) which then provides network access to the client.
This is an RFC primarily to get some feedback on the implementation
approach being used. At present, this code is intercepting packets as soon
as they are received on a PPP channel. The packets are then modified to
use a fake ETH_P_PPP protocol type and sent out over another PPP device
via dev_queue_xmit(). In theory this enables forwarding of any type of PPP
session, although I've only tested L2TPv2 so far.
The reasoning behind using dev_queue_xmit() rather than outputting directly
to another PPP channel is to enable the use of the traffic shaping and
queuing features of the kernel on multihop sessions.
Comments / thoughts? A sample test program is available at
http://www.kvack.org/~bcrl/pppol2tp/multihop.c . I am in the process of
updating the Babylon PPP implementation to use this functionality, and
expect to be ready to make those changes available later this week. I
have not yet finished testing this code, so I'm sure that there are bugs
lurking within.
-ben
Not-signed-off-yet-by: Benjamin LaHaise <bcrl@kvack.org>
---
drivers/net/ppp/ppp_generic.c | 53 +++++++++++++++++++++++++++++++++++++++++-
include/linux/if_ether.h | 1
include/linux/ppp-ioctl.h | 1
3 files changed, 54 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ppp/ppp_generic.c b/drivers/net/ppp/ppp_generic.c
index 5c05572..9c12712 100644
--- a/drivers/net/ppp/ppp_generic.c
+++ b/drivers/net/ppp/ppp_generic.c
@@ -121,6 +121,7 @@ struct ppp {
unsigned long last_xmit; /* jiffies when last pkt sent 9c */
unsigned long last_recv; /* jiffies when last pkt rcvd a0 */
struct net_device *dev; /* network interface device a4 */
+ struct net_device *multihop_if; /* if to forward incoming frames to */
int closing; /* is device closing down? a8 */
#ifdef CONFIG_PPP_MULTILINK
int nxchan; /* next channel to send something on */
@@ -738,6 +739,30 @@ static long ppp_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
err = 0;
break;
+ case PPPIOCSMULTIHOP_IF:
+ {
+ struct net_device *multihop_if;
+ if (get_user(val, p))
+ break;
+ err = 0;
+ if (ppp->multihop_if && (val == -1)) {
+ struct net_device *dev = ppp->multihop_if;
+ ppp->multihop_if = NULL;
+ dev_put(dev);
+ break;
+ }
+ err = -EBUSY;
+ if (ppp->multihop_if)
+ break;
+ multihop_if = dev_get_by_index(&init_net, val);
+ err = -ENOENT;
+ if (!multihop_if)
+ break;
+ ppp->multihop_if = multihop_if;
+ err = 0;
+ break;
+ }
+
#ifdef CONFIG_PPP_FILTER
case PPPIOCSPASS:
{
@@ -942,6 +967,9 @@ ppp_start_xmit(struct sk_buff *skb, struct net_device *dev)
int npi, proto;
unsigned char *pp;
+ if (skb->protocol == htons(ETH_P_PPP))
+ goto queue;
+
npi = ethertype_to_npindex(ntohs(skb->protocol));
if (npi < 0)
goto outf;
@@ -968,6 +996,7 @@ ppp_start_xmit(struct sk_buff *skb, struct net_device *dev)
proto = npindex_to_proto[npi];
put_unaligned_be16(proto, pp);
+queue:
skb_queue_tail(&ppp->file.xq, skb);
ppp_xmit_process(ppp);
return NETDEV_TX_OK;
@@ -1131,6 +1160,9 @@ ppp_send_frame(struct ppp *ppp, struct sk_buff *skb)
int len;
unsigned char *cp;
+ if (skb->protocol == htons(ETH_P_PPP))
+ goto xmit;
+
if (proto < 0x8000) {
#ifdef CONFIG_PPP_FILTER
/* check if we should pass this packet */
@@ -1228,6 +1260,7 @@ ppp_send_frame(struct ppp *ppp, struct sk_buff *skb)
return;
}
+xmit:
ppp->xmit_pending = skb;
ppp_push(ppp);
return;
@@ -1259,7 +1292,8 @@ ppp_push(struct ppp *ppp)
return;
}
- if ((ppp->flags & SC_MULTILINK) == 0) {
+ if (((ppp->flags & SC_MULTILINK) == 0) ||
+ (skb->protocol == htons(ETH_P_PPP))) {
/* not doing multilink: send it down the first channel */
list = list->next;
pch = list_entry(list, struct channel, clist);
@@ -1599,6 +1633,14 @@ ppp_input(struct ppp_channel *chan, struct sk_buff *skb)
goto done;
}
+ if (pch->ppp && pch->ppp->multihop_if) {
+ skb->protocol = htons(ETH_P_PPP);
+ skb->dev = pch->ppp->multihop_if;
+ skb->ip_summed = CHECKSUM_NONE;
+ dev_queue_xmit(skb);
+ goto done;
+ }
+
proto = PPP_PROTO(skb);
if (!pch->ppp || proto >= 0xc000 || proto == PPP_CCPFRAG) {
/* put it on the channel queue */
@@ -2715,8 +2757,12 @@ static void ppp_shutdown_interface(struct ppp *ppp)
/* This will call dev_close() for us. */
ppp_lock(ppp);
if (!ppp->closing) {
+ struct net_device *multihop_if = ppp->multihop_if;
ppp->closing = 1;
+ ppp->multihop_if = NULL;
ppp_unlock(ppp);
+ if (multihop_if)
+ dev_put(multihop_if);
unregister_netdev(ppp->dev);
unit_put(&pn->units_idr, ppp->file.index);
} else
@@ -2764,6 +2810,11 @@ static void ppp_destroy_interface(struct ppp *ppp)
#endif /* CONFIG_PPP_FILTER */
kfree_skb(ppp->xmit_pending);
+ printk("ppp_destroy_interface(%p): multihop_if = %p\n", ppp,
+ ppp->multihop_if);
+ if (ppp->multihop_if)
+ dev_put(ppp->multihop_if);
+ ppp->multihop_if = NULL;
free_netdev(ppp->dev);
}
diff --git a/include/linux/if_ether.h b/include/linux/if_ether.h
index 167ce5b..fe47a70 100644
--- a/include/linux/if_ether.h
+++ b/include/linux/if_ether.h
@@ -120,6 +120,7 @@
#define ETH_P_PHONET 0x00F5 /* Nokia Phonet frames */
#define ETH_P_IEEE802154 0x00F6 /* IEEE802.15.4 frame */
#define ETH_P_CAIF 0x00F7 /* ST-Ericsson CAIF protocol */
+#define ETH_P_PPP 0x00F8 /* Dummy type for PPP multihop */
/*
* This is an Ethernet frame header.
diff --git a/include/linux/ppp-ioctl.h b/include/linux/ppp-ioctl.h
index 2d9a885..5571375 100644
--- a/include/linux/ppp-ioctl.h
+++ b/include/linux/ppp-ioctl.h
@@ -81,6 +81,7 @@ struct pppol2tp_ioc_stats {
* Ioctl definitions.
*/
+#define PPPIOCSMULTIHOP_IF _IOWR('t', 91, int) /* set multihop if */
#define PPPIOCGFLAGS _IOR('t', 90, int) /* get configuration flags */
#define PPPIOCSFLAGS _IOW('t', 89, int) /* set configuration flags */
#define PPPIOCGASYNCMAP _IOR('t', 88, int) /* get async map */
--
"Thought is the essence of where you are now."
^ permalink raw reply related
* Re: [PATCH v2] cgroup: fix panic in netprio_cgroup
From: Gao feng @ 2012-07-09 0:16 UTC (permalink / raw)
To: Eric Dumazet; +Cc: nhorman, davem, netdev, linux-kernel, tj, lizefan
In-Reply-To: <1341777043.3265.1786.camel@edumazet-glaptop>
于 2012年07月09日 03:50, Eric Dumazet 写道:
> On Thu, 2012-07-05 at 17:28 +0800, Gao feng wrote:
>> we set max_prioidx to the first zero bit index of prioidx_map in
>> function get_prioidx.
>>
>> So when we delete the low index netprio cgroup and adding a new
>> netprio cgroup again,the max_prioidx will be set to the low index.
>>
>> when we set the high index cgroup's net_prio.ifpriomap,the function
>> write_priomap will call update_netdev_tables to alloc memory which
>> size is sizeof(struct netprio_map) + sizeof(u32) * (max_prioidx + 1),
>> so the size of array that map->priomap point to is max_prioidx +1,
>> which is low than what we actually need.
>>
>> fix this by adding check in get_prioidx,only set max_prioidx when
>> max_prioidx low than the new prioidx.
>>
>> Signed-off-by: Gao feng <gaofeng@cn.fujitsu.com>
>> ---
>> net/core/netprio_cgroup.c | 3 ++-
>> 1 files changed, 2 insertions(+), 1 deletions(-)
>>
>> diff --git a/net/core/netprio_cgroup.c b/net/core/netprio_cgroup.c
>> index 5b8aa2f..aa907ed 100644
>> --- a/net/core/netprio_cgroup.c
>> +++ b/net/core/netprio_cgroup.c
>> @@ -49,8 +49,9 @@ static int get_prioidx(u32 *prio)
>> return -ENOSPC;
>> }
>> set_bit(prioidx, prioidx_map);
>> + if (atomic_read(&max_prioidx) < prioidx)
>> + atomic_set(&max_prioidx, prioidx);
>> spin_unlock_irqrestore(&prioidx_map_lock, flags);
>> - atomic_set(&max_prioidx, prioidx);
>> *prio = prioidx;
>> return 0;
>> }
>
> This patch seems fine to me.
>
> Acked-by: Eric Dumazet <edumazet@google.com>
>
> Neil, looking at this file, I believe something is wrong.
>
> dev->priomap is allocated by extend_netdev_table() called from
> update_netdev_tables(). And this is only called if write_priomap() is
> called.
>
> But if write_priomap() is not called, it seems we can have out of bounds
> accesses in cgrp_destroy() and read_priomap()
Agree,and the function skb_update_prio has the same problem.
^ permalink raw reply
* [PATCH firmware 2/4] rtl_nic: update firmware for RTL8411
From: Hayes Wang @ 2012-07-09 3:11 UTC (permalink / raw)
To: dwmw2, ben; +Cc: romieu, netdev, linux-kernel, Hayes Wang
In-Reply-To: <1341803512-1309-1-git-send-email-hayeswang@realtek.com>
File: rtl_nic/rtl8411-1.fw
Version: 0.0.3
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
---
WHENCE | 2 +-
rtl_nic/rtl8411-1.fw | Bin 1840 -> 2112 bytes
2 files changed, 1 insertion(+), 1 deletion(-)
diff --git a/WHENCE b/WHENCE
index 676ebb1..c7a3e98 100644
--- a/WHENCE
+++ b/WHENCE
@@ -1808,7 +1808,7 @@ File: rtl_nic/rtl8168f-2.fw
Version: 0.0.4
File: rtl_nic/rtl8411-1.fw
-Version: 0.0.2
+Version: 0.0.3
File: rtl_nic/rtl8402-1.fw
Version: 0.0.1
diff --git a/rtl_nic/rtl8411-1.fw b/rtl_nic/rtl8411-1.fw
index 1bd9e7cdd5605e34e0322c0df185c53e46d6a34b..72772dbc8343c8cef8eac61f704377fc3fb6c7b3 100644
GIT binary patch
delta 430
zcmZ{fze@sP7{~8U`4Wj`Q4Iy9WLe;k_wMStjzDN>X^@6!a}JuKp{*}UOVSiH7DS^R
zg*4kA(2!HBf)TW|m6Sx!NkK~wyga|3@8`W9xQi7uvE98Lcfm9>W>IBT){ZMDXSzAl
z3VMMBL!Y{)O=uhIj-}k9rA$jX%FSAF)Akl^&s^4yFO$LSP2pZ2E7w6|1x$FL-T-@f
zzGfMly5W~<N1^`E!D<=w4DdApew~8hF4*jVhZS)4N@4{%P4O+TwFKs+9-9KE&%jC>
ztmeT;Tr{c@N5R1vFeR}+B-+E^Z5oXFU`aImXQ}mpk5UUsEp6a{-50PE7Jv_FZVP|_
zHAS#B0*;CgAR4k%p9I%3|HGza?ja{PBC_L(;Fi37FnKPZ!95GKf8fUjz8wRtijefg
X=D>LwO211kzk2%3-~Q$&7btxL90!Z?
delta 157
zcmX>guz@dt0SJmpax6>?4RsCU4fG83j1&xv^^MH+4UIr@AOKRdg^_{5mLbT;%*enZ
z-pIhv$iUdhP{Gj5%EZjd)PSLPi3&(%_y3InXBfqr_OmrGtz&CYv|?*uyvWu7=5O3=
o#1zKJRHL)Gi<yg=Z%Y$fgB257!+S-xhJVv0?_+P`0hs^;0L0HE{{R30
--
1.7.10.2
^ permalink raw reply related
* [PATCH firmware 1/4] rtl_nic: update firmware for RTL8168F
From: Hayes Wang @ 2012-07-09 3:11 UTC (permalink / raw)
To: dwmw2, ben; +Cc: romieu, netdev, linux-kernel, Hayes Wang
File: rtl_nic/rtl8168f-1.fw
Version: 0.0.5
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
---
WHENCE | 2 +-
rtl_nic/rtl8168f-1.fw | Bin 3136 -> 3424 bytes
2 files changed, 1 insertion(+), 1 deletion(-)
diff --git a/WHENCE b/WHENCE
index 13cbcab..676ebb1 100644
--- a/WHENCE
+++ b/WHENCE
@@ -1802,7 +1802,7 @@ File: rtl_nic/rtl8168e-3.fw
Version: 0.0.4
File: rtl_nic/rtl8168f-1.fw
-Version: 0.0.4
+Version: 0.0.5
File: rtl_nic/rtl8168f-2.fw
Version: 0.0.4
diff --git a/rtl_nic/rtl8168f-1.fw b/rtl_nic/rtl8168f-1.fw
index 41822b54ef44c37400db3ddac26d0e6655e1faa7..bf7883163e3dbed22420dec369ed51a3ee8247d4 100644
GIT binary patch
delta 487
zcmZuuJxc>Y6uex*5QyRjDq^7#zab`j7d#Ie(Z)hSv9hxh0;$A8M9Cne3RVFdK??;z
zG${E2T3MUY$_vCgor;J!CkhrWEbqP9dGls>?|Os26-#S#EAKm=zcJ~oo3u$!C5@MH
z{EXv<hgu<NK5AKcYjw$UT{E}t8pk!B@zZY7$<9n=XN+SV9EIGQmAKt;Rs?+;tnGof
z5%9d6vrkbJV)s-#qfaq&1@8G^q$a2dwzPxS9boH+8Wb=73RtSEgYm^^;ra(|O84^+
zjENq+fyELyD#^frUZ7Y9>(k(@@b&?4=ol<Dz{^=Mkpu@XmA8UzBjA|wibmR<;6h3k
zD$<kF%CfLHm=hKima<Xc$1eC51Do$U%z=3s3N*0Z1$HZjCTeQB?FS##7(T*(X2-;P
z$Vejr?t9v6+S}mpiHwGNE|~o>-zW18y^mXx;P<d`a6+Wit7_fq`L}-gTbFkd_p$It
Fz5vSno%R3#
delta 196
zcmaDLbwDD30SJmpax4tZEYfrh;|=r-^h^{CjP;Go^$m?cl0X1b^qYx+VJ<_EkC~B?
zfn&UpfuWIsv5}#Ip_!G5nU#?xL+=t5kkSbo12~uj#ah`KEST6DF4nR&>}O<aker;!
zw3tl?D8j_IS%~>Qi-9~_L#+i{1LH-Y(0jH99s#z74T5Y9ynlcifV2#<0SrL?W<?Hf
TW<DjT@Oz-S|E5iz#&Zk+TtzbT
--
1.7.10.2
^ permalink raw reply related
* =? ?q?=5BPATCH=20firmware=203/4=5D=20rtl=5Fnic=3A=20add=20new=20firmware=20for=20RTL8106E?=
From: Hayes Wang @ 2012-07-09 3:11 UTC (permalink / raw)
To: dwmw2, ben; +Cc: romieu, netdev, linux-kernel, Hayes Wang
In-Reply-To: <1341803512-1309-1-git-send-email-hayeswang@realtek.com>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="\"\"", Size: 2104 bytes --]
File: rtl_nic/rtl8106e-1.fw
Version: 0.0.1
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
---
WHENCE | 3 +++
rtl_nic/rtl8106e-1.fw | Bin 0 -> 1856 bytes
2 files changed, 3 insertions(+)
create mode 100644 rtl_nic/rtl8106e-1.fw
diff --git a/WHENCE b/WHENCE
index c7a3e98..8f2b610 100644
--- a/WHENCE
+++ b/WHENCE
@@ -1813,6 +1813,9 @@ Version: 0.0.3
File: rtl_nic/rtl8402-1.fw
Version: 0.0.1
+File: rtl_nic/rtl8106e-1.fw
+Version: 0.0.1
+
Licence:
* Copyright © 2011, Realtek Semiconductor Corporation
*
diff --git a/rtl_nic/rtl8106e-1.fw b/rtl_nic/rtl8106e-1.fw
new file mode 100644
index 0000000000000000000000000000000000000000..85694cb6bf5f0a1807356392497703a779b5148e
GIT binary patch
literal 1856
zcmZ{lYlxIp7{||CawkZ3{NN2d?SMi<kiIk6ZtjOz!(u_ZfSV}_Gv%%qTtXJ{lWtFC
zAmnxtFA!a(8Y+@B(#j}t>x&;G)KF7QP>}FL6lNbnrS12B-}AD=L<0}cdCz&C|MPz?
z=ZtgCjcgfys1kJ#Jy5Ad^P~BdQq;Ymx@bYA%9(z3<m-%cXWa8^w+z>0TdPKuYSdkM
zur@fdaqG}XsnXLME$m&`<Hnlv<P+2zdDmr<&6{VNn=;4Tes5P^@aC3z>*zx-LHfOQ
zZA<ow%h7dYgSUs*qg^6h&v?6C^OpbA+sf7KJ?m{o<ZY0(VSno*Z<l`YHXZxv-*}t$
zrMFFIymj*3d4%<8Z&O)M`NCU9u~vd5y~bM+9PMSoUY<Q+k0O5|?^P1cbvWnX<+dXm
zy_JU0U`ld_hzqA)?DyBPhwnY$?LrLR_qF7xT#I129o{0=CG3y4oo6`D9`&{yyaF}_
z#SO8F^5^^1d2HDG#}a;qkIqy(`ADZebNQaT#@oI9leHF)tbC~X#Eag(Csy2>$GuhC
z?8G<5gzK@Ux5F2SOKjPfuy>=#bJQ?kjI;O7>A;Wr%g)$S>Sn;Z|<xZ;CzK7FTu1
z?VZHe9DGYX?+SBZ>IHRwi@5PD@U3|`@FQ~qzcKU*^d|TYpc`<yAbk>C^l#?vV|<Sw
z;&_F4?YS31?u9zBUWPmKrP<gJd>Z6cUdI`DlEw;pzX}b{CUNrYiHCZ1$C5aW6mxLW
zFP<yvlKU#@W3f)J$fxUR>K$@6>ZjS&9r&5}>9=zKzZr{X0xab>PTV+7OI+1+UR&Ms
zvU>?1#Ty7dE%UCLrM-4fOy1@A{*puM-R-1j6M_F~-G|V#4(`?Z@U5QZ_7Eq`(TCLQ
zy7Tr5`d762cMW}QA2x0H@eIP@GH3Z$!+m)QyaQooS!eJWZJD=im%RNBp89o_y7b}S
zLk(sv@pfWyQY-ECh5U6_G>fVJ;dT1^leeY#=XZO1q`};fkKPO6)$x5Byz*lSmcGm6
zrtcK9{T;ea+!R06pAcs;Z`S?bFAMKb1FS53vT*H3_7Eqvm(Ia6?Pmw;Kfs+p-VAoy
zlif_T-k`r<OL86~);V(Ne4iejrFP_I=e!+7XFs4<#E<VUF}2=-%}vgvZ=jWXe23td
z=C~8vQ^Zcs#yPv$#`kV`6dp}Dd=7_M)b${EP4v6yogr_-H@%x_FQ(yJCWhkm4bUTW
z>pQNR9&Yj$1&q>@|DB(7KK0+C`P6&z8TRpP*1i4t9hl^%|1p=HW0C&LwC49OflNUk
literal 0
HcmV?d00001
--
1.7.10.2
^ permalink raw reply related
* =? ?q?=5BPATCH=20firmware=204/4=5D=20rtl=5Fnic=3A=20add=20new=20firmware=20for=20RTL8168G?=
From: Hayes Wang @ 2012-07-09 3:11 UTC (permalink / raw)
To: dwmw2, ben; +Cc: romieu, netdev, linux-kernel, Hayes Wang
In-Reply-To: <1341803512-1309-1-git-send-email-hayeswang@realtek.com>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="\"\"", Size: 3800 bytes --]
File: rtl_nic/rtl8168g-1.fw
Version: 0.0.1
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
---
WHENCE | 3 +++
rtl_nic/rtl8168g-1.fw | Bin 0 -> 4272 bytes
2 files changed, 3 insertions(+)
create mode 100644 rtl_nic/rtl8168g-1.fw
diff --git a/WHENCE b/WHENCE
index 8f2b610..1fb7951 100644
--- a/WHENCE
+++ b/WHENCE
@@ -1816,6 +1816,9 @@ Version: 0.0.1
File: rtl_nic/rtl8106e-1.fw
Version: 0.0.1
+File: rtl_nic/rtl8168g-1.fw
+Version: 0.0.1
+
Licence:
* Copyright © 2011, Realtek Semiconductor Corporation
*
diff --git a/rtl_nic/rtl8168g-1.fw b/rtl_nic/rtl8168g-1.fw
new file mode 100644
index 0000000000000000000000000000000000000000..dace1ea98c66de08107ee0857d8a8680d57d7898
GIT binary patch
literal 4272
zcma)=4Q!QH8OP6kds{wM$}K%Y`H<dLC`AQsTT|vXp)D<277}sMEg(r-8Eiyx70{Tt
zg@+5Q`*4D8GRDSMM{zKrWJV2H7`HfNer#-IQFJ8p!hjiry~bsQF`)jQd(PWlnweNQ
zdCqyx^YK6b^PF?u))-^ftozoD)pa-CGpo8KF*`B4I-aPTQ}e|+)iuoNPb;lBYRsMH
zjzx7fHMI>bYuZ+~EWhvW6)o*;>z3c!QeBg%P1LolUbS|4yt?kDnlJF*JodEuCT}Pc
zV`BWv{_m0O*tAECNvo>fn0UPjI`1}St1<bB1*6Mk;f4}1pRp1@SR%2&it4n#mHxO+
z=8P4KjDFtAWZDW^!7M9NPg?m&y_M+8RyHN9^iQ$!ChZ;CK)03P0BsBXA6bbUx6+=r
zV#d-(A3;A3|9`X$*+sBBi|>DCSXug(l^wlSMq#t1)yg*+Kf-uAxewES$oEGwzeX_}
zu`-vr@6nI>{&(mHzTZwi;`?8p;NotrwNkUp%B}dRPGddZ=H_;S>rs4kjg77N{%Xi(
zE#pJXFU0R(l~&}JRvPxe-xK8SaQ+t>t*pjw#0e{lvCBgakniR@t$eq}%3b$csmCuM
z?#;y5hOLeZ{P<+Gl~!+4<aIG*@Q|}BdcyfB_sV&&*Ge&1o9n?tKac%*X$iKw!Txh_
zF}HxZn78XBU+o`he*!zYAAoUy@c`p;#)03jSk8W}oPeG^>Og9|XNaNvbgj4Y2L5Nj
z5%qrYVSZ8kny^>9IG92_FEbvS24g<8fPdtmi`iOl<*1L_hhA+0ZxeW%wokB$VxzI2
zYP}xYdiLJ@*2?^&aPvBOUck=dC?!tpDcWW@uX4HmSDcY>`N01ft8ymi1FlX{&!&gw
z{miTM!C`(!J7(p`YslZzz-2~~-|s_2_u*l5f1sf=?2XPxS-(o<UOA0!cjHf5x7vm4
z+&+vGU9Zk--DtgB*8SsLYn;Q_wx-#uQLes{?33nOj@@k&Ig3?J|H@1-?!kW-+-{<N
zHgJxT@cTTi$HnTz=Tl>>s4V=Fi?fKm{mp0bBS#Q8yRGEZ9Q*uSAu$xokB8}th@U23
zSVudD&Bs|+-aS@kv6gv18^U4gIkVX6-8H`pJ#+CMm!q8XHV=$FU@RDhF?)u*U4$56
zz3%=rHOije3r<~sob`uws&j$&(Y(q@jQMhM=IY}cIIpy=*b8$v(dw~HfG_6#PlM^u
zXvfVDJvYL9!sk_<3*l*6gIi0y&FyIwYr2oMtYW<p_GkrC`BXfmX)py=E|E{b74^A>
zbCl0~6?k&z4{czr<W|ga<_=*~@BKrpDu?r^b)q<%8o>i!8dGaeaXt%9#U?FIHws-R
zx-O6Xaisd^;>fM-9j({bPFUNM{QFga{0kgLksppA7V`B1xImt|$U1V~zRry$vXM9H
zz&<MnH(J+!!^+$AqXE7<tnB4nY@&bQYgVox<NML)@y0#K9{c_))M171_e{1jftbO2
zRxV;wN<Z=q>KF{S!RIZEFRkJXe#Cxd;Gqw@n3H8C<n86&P2vAfD@z*blQZ>wE3bBd
z5#HXaV6M>09n7h3CwNspdfdqm@z?QQ-XWEv-*z(gZzs2WU}XdPsSzh{zro4-iK+Va
z<KT)I`hC#%Yu;Z$QiBhxY~ro<<EQ=j8I><s*^NAb42+ePMOHTBpWz+5whi8{qK{hn
zHua}m2H5?Ae1+OSiXHti+8@a~HOA?q)WqdWj-%vh?ut29CUFNP)AXldTMp;l4rl*e
zd`~c*mV|4tHz|LtU-^q+GmhB(i>#c(e-1Vpqn{X|&o=hq$~E>S%AC(t%AGZstHMep
zakAJi5SRTP%=2fLrzo6%*UC=jHBLX6&k^UkoWxR`(JQ>8)Ic%3RZ}}B^1<x6i^A7O
ztUYs?x}jFoMr$p#jQe^4-zfncJjpj&6>q(+^@x=x8#!P5uwnmR%dv@KW2k`<;446G
zK0tlnPF!kO<5p_i>8zpI#XUpZwVIE8nA?vHat^Ybx(;4+e99U2YaQ!@^T~6qyof9z
zUO<lEb5@GL7ktIl!C3m4T|;%C91qrh+RA?L*3R(jIGnSNQM{La9s9vl&N`ZPtxKFu
z$9r%#Kz;)kU@s;{2b`za$5S0{En~1v6<c}Nk28$JdQ=?BZ!i3&h!Ogvuo-Tzd)3j$
zn?gR75nn6e{xl@@egPYM`1j4MA08rpymS)0D=#{Rqw|b&>n-FWTa(nM*5pj$Nt$(W
zF9a2Q>*BBT7g?ju&tN{g?<J0la_Tob9`DA*oTu`sUN_O{#(7=xyp`wSb+qv{N=!W$
z8nZFX)8z6rp<5Wh5BlkTFEZ>!3Jg>HxRCKw_E2?YxjL|^t}0h&o$e*#YYk_8!F(RO
zMsg+l;H|;&a}|!2_rW`W^>;3`k`L|&@$G(uF?VWS#L7g*8P=(LJKU#VIgJnFlzd+e
z*Q%T{pIyJ!7yJyKr3&iY<3GnbZv~^Cv0m&`d7LRf*GJ7PWbQQBG)@)gC3y~v#O@_m
zidqY8yRq%%o=Z_Hp)QS1xsG4N?<^SLr<=8A`9S8@OIULy!absAcZ!wwI~<>SPD(f@
z9cj3MJLO8>k8bXuPHHJ1uCn7>IR9Wskh4;;k~5PS;xEnJ)685&h^N`%$<{t`b2$z^
z<~{-AV#UJQKMNMU8+Cv6Ea_O^6CLY1vvGaSz{l13?3?$#yGxVc?+4G>N{2DSxeNDJ
z@5SSsTjk+n&aV2M+y!^6b>d%Xf1|xaJB7^%xcsS$IiG$Mn+wmO_wlYBb8nMjf12UO
zJb+|h%`)O*Yu@Axss781RnME!F$&3@pOxfOyROr`&B&v1=En1FsJ`Gd?N(+V<Zax}
zH!$@&Z;zEdi@ERSSvhuy@2LvzPB1if;R`1H&KZ9cJ$CwgL@D1YAHdrrWbXvd9CB$X
t=MA}%J=AZRGUoO7cw^k}@8RDC2CkYoe+TFp{JkGc;aq0G&6%8^{{jgy%S-?O
literal 0
HcmV?d00001
--
1.7.10.2
^ permalink raw reply related
* RE: [PATCH 0/4] Add a driver for the ASIX AX88172A
From: ASIX Allan Email [office] @ 2012-07-09 2:38 UTC (permalink / raw)
To: 'Christian Riesch', netdev
Cc: 'Oliver Neukum', 'Eric Dumazet',
'Mark Lord', 'Grant Grundler', 'Ming Lei',
'Michael Riesch', ASIX Louis [蘇威陸],
ASIX Freddy [辛恆豐]
In-Reply-To: <1341574388-7464-1-git-send-email-christian.riesch@omicron.at>
Dear All,
Thanks a lot for your great efforts to support AX88172A on Linux kernel mainline source.
The following information might be useful for you to implement AX88172A Linux driver in Linux kernel mainline source. Most of AX88172A customers' applications will implement their target applications through the MII interface in MAC mode or through the Rev-MII/Rev-RMII in PHY mode, such as AX88172A (MAC mode) + external fiber PHY, AX88172A (PHY mode or Dual-PHY mode) + external MAC controller, etc. ASIX uses AX88172A EEPROM offset 17h (as Software Field setting, the AX88172A drivers will check this field value to identify the exact applications for different driver initialization procedures) to identify different customers' applications.
For the AX88172A (PHY mode or Dual-PHY mode) + external MAC controller customers' applications that are embedded applications with AX88172A on-board design, customers should have implemented ASIX's AX88172A Linux driver source on their own embedded Linux kernel platform directly.
For the AX88172A (MAC mode) + external fiber PHY applications that might be USB to Fiber dongle applications, users might plug the USB to Fiber dongle on any Linux kernel platforms. You can consider referring to ASIX's AX88172A Linux driver source that can be downloaded from AX88172A Driver Download web page (http://www.asix.com.tw/download.php?sub=driverdetail&PItemID=96) to support these kinds of known dongle solutions on Linux kernel mainline source if necessary. Please feel free to let us know if you need more information. Thanks a lot.
---
Best regards,
Allan Chou
Technical Support Division
ASIX Electronics Corporation
TEL: 886-3-5799500 ext.228
FAX: 886-3-5799558
E-mail: allan@asix.com.tw
http://www.asix.com.tw/
-----Original Message-----
From: Christian Riesch [mailto:christian.riesch@omicron.at]
Sent: Friday, July 06, 2012 7:33 PM
To: netdev@vger.kernel.org
Cc: Oliver Neukum; Eric Dumazet; Allan Chou; Mark Lord; Grant Grundler; Ming Lei; Michael Riesch; Christian Riesch
Subject: [PATCH 0/4] Add a driver for the ASIX AX88172A
Hi,
this patch adds a driver for the ASIX AX88172A USB 2.0 to 10/100M
Fast Ethernet Controller.
Although this chip is already supported by the AX88772 code in
drivers/net/usb/asix.c, I submit a new driver since the existing
driver lacks an important feature: It only supports an
Ethernet connection using the internal PHY embedded in the AX88172A.
The driver for the AX88172A is based on drivers/net/usb/asix.c
and the work of Michael Riesch <michael@riesch.at>.
The first patch in the patchset fixes checkpatch warnings in asix.c.
The second and the third patch factor out common code which is shared
between the existing drivers and the new driver for the AX88172A.
The fourth patch finally adds support for the AX88172A.
The patchset applies on top of net-next.
I have a few questions:
1) Is it ok to factor out the common code like I did? Or should
it go into a separate kernel module?
2) phylib/usbnet: Currently I have an empty .status function
in my const struct driver_info ax88172a_info. I think this
notifies me of a link change, right? I don't know
what I should do in this function. Trigger the phy state machine
like a phy interrupt would do, since link changes are handled
by the phy state machine?
I have tested the patch with the ASIX AX88172A demo board (using the
internal PHY) and a custom board (AX88172A and National DP83640 PHY).
I am looking forward to your comments. Since this is my first submission
of a larger patchset to a kernel mailing list, I would like to thank you
in advance for your patience :-) The patch is in an early state and
certainly needs improvement!
Regards, Christian
Christian Riesch (4):
asix: Fix checkpatch warnings
asix: Rename asix.c to asix_devices.c
asix: Factor out common code
asix: Add a new driver for the AX88172A
drivers/net/usb/Makefile | 1 +
drivers/net/usb/asix.c | 1660 ----------------------------------------
drivers/net/usb/asix.h | 211 +++++
drivers/net/usb/asix_common.c | 525 +++++++++++++
drivers/net/usb/asix_devices.c | 1033 +++++++++++++++++++++++++
drivers/net/usb/ax88172a.c | 407 ++++++++++
6 files changed, 2177 insertions(+), 1660 deletions(-)
delete mode 100644 drivers/net/usb/asix.c
create mode 100644 drivers/net/usb/asix.h
create mode 100644 drivers/net/usb/asix_common.c
create mode 100644 drivers/net/usb/asix_devices.c
create mode 100644 drivers/net/usb/ax88172a.c
^ permalink raw reply
* Re: [net-next RFC V5 0/5] Multiqueue virtio-net
From: Jason Wang @ 2012-07-09 3:23 UTC (permalink / raw)
To: Rick Jones
Cc: krkumar2, habanero, mashirle, kvm, mst, netdev, linux-kernel,
virtualization, edumazet, tahm, jwhan, davem, sri
In-Reply-To: <4FF710FD.2090100@hp.com>
On 07/07/2012 12:23 AM, Rick Jones wrote:
> On 07/06/2012 12:42 AM, Jason Wang wrote:
>> I'm not expert of tcp, but looks like the changes are reasonable:
>> - we can do full-sized TSO check in tcp_tso_should_defer() only for
>> westwood, according to tcp westwood
>> - run tcp_tso_should_defer for tso_segs = 1 when tso is enabled.
>
> I'm sure Eric and David will weigh-in on the TCP change. My initial
> inclination would have been to say "well, if multiqueue is draining
> faster, that means ACKs come-back faster, which means the "race"
> between more data being queued by netperf and ACKs will go more to the
> ACKs which means the segments being sent will be smaller - as
> TCP_NODELAY is not set, the Nagle algorithm is in force, which means
> once there is data outstanding on the connection, no more will be sent
> until either the outstanding data is ACKed, or there is an
> accumulation of > MSS worth of data to send.
>
>>> Also, how are you combining the concurrent netperf results? Are you
>>> taking sums of what netperf reports, or are you gathering statistics
>>> outside of netperf?
>>>
>>
>> The throughput were just sumed from netperf result like what netperf
>> manual suggests. The cpu utilization were measured by mpstat.
>
> Which mechanism to address skew error? The netperf manual describes
> more than one:
This mechanism is missed in my test, I would add them to my test scripts.
>
> http://www.netperf.org/svn/netperf2/trunk/doc/netperf.html#Using-Netperf-to-Measure-Aggregate-Performance
>
>
> Personally, my preference these days is to use the "demo mode" method
> of aggregate results as it can be rather faster than (ab)using the
> confidence intervals mechanism, which I suspect may not really scale
> all that well to large numbers of concurrent netperfs.
During my test, the confidence interval would even hard to achieved in
RR test when I pin vhost/vcpus in the processors, so I didn't use it.
>
> I also tend to use the --enable-burst configure option to allow me to
> minimize the number of concurrent netperfs in the first place. Set
> TCP_NODELAY (the test-specific -D option) and then have several
> transactions outstanding at one time (test-specific -b option with a
> number of additional in-flight transactions).
>
> This is expressed in the runemomniaggdemo.sh script:
>
> http://www.netperf.org/svn/netperf2/trunk/doc/examples/runemomniaggdemo.sh
>
>
> which uses the find_max_burst.sh script:
>
> http://www.netperf.org/svn/netperf2/trunk/doc/examples/find_max_burst.sh
>
> to pick the burst size to use in the concurrent netperfs, the results
> of which can be post-processed with:
>
> http://www.netperf.org/svn/netperf2/trunk/doc/examples/post_proc.py
>
> The nice feature of using the "demo mode" mechanism is when it is
> coupled with systems with reasonably synchronized clocks (eg NTP) it
> can be used for many-to-many testing in addition to one-to-many
> testing (which cannot be dealt with by the confidence interval method
> of dealing with skew error)
>
Yes, looks "demo mode" is helpful. I would have a look at these scripts,
Thanks.
>>> A single instance TCP_RR test would help confirm/refute any
>>> non-trivial change in (effective) path length between the two cases.
>>>
>>
>> Yes, I would test this thanks.
>
> Excellent.
>
> happy benchmarking,
>
> rick jones
>
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net-next 04/15] security: Add Linux Security Modules hook for AF_BUS sockets
From: James Morris @ 2012-07-09 3:32 UTC (permalink / raw)
To: Vincent Sanders
Cc: netdev, linux-kernel, David S. Miller, Javier Martinez Canillas,
Paul Moore
In-Reply-To: <1340988354-26981-5-git-send-email-vincent.sanders@collabora.co.uk>
On Fri, 29 Jun 2012, Vincent Sanders wrote:
> From: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
>
> AF_BUS implements a security hook bus_connect() to be used by LSM to
> enforce connectivity security policies.
Nack.
Changes to LSM should be cc'd the LSM list and Paul Moore.
- James
--
James Morris
<jmorris@namei.org>
^ permalink raw reply
* Re: [RFC] Introduce to batch variants of accept() and epoll_ctl() syscall
From: Li Yu @ 2012-07-09 3:36 UTC (permalink / raw)
To: Eric Dumazet
Cc: Changli Gao, Linux Netdev List, Linux Kernel Mailing List,
davidel
In-Reply-To: <4FF6B20E.7000402@gmail.com>
于 2012年07月06日 17:38, Li Yu 写道:
> 于 2012年06月15日 16:51, Eric Dumazet 写道:
>> On Fri, 2012-06-15 at 13:37 +0800, Li Yu wrote:
>>
>>> Of course, I think that implementing them should not be a hard work :)
>>>
>>> Em. I really do not know whether it is necessary to introduce to a new
>>> syscall here. An alternative solution to add new socket option to handle
>>> such batch requirement, so applications also can detect if kernel has
>>> this extended ability with a easy getsockopt() call.
>>>
>>> Any way, I am going to try to write a prototype first.
>>
>> Before that, could you post the result of "perf top", or "perf
>> record ...;perf report"
>>
>
> Sorry for I just have time to write a benchmark to reproduce this
> problem on my test bed, below are results of "perf record -g -C 0".
> kernel is 3.4.0:
>
> Events: 7K cycles
> + 54.87% swapper [kernel.kallsyms] [k] poll_idle
> - 3.10% :22984 [kernel.kallsyms] [k] _raw_spin_lock
> - _raw_spin_lock
> - 64.62% sch_direct_xmit
> dev_queue_xmit
> ip_finish_output
> ip_output
> - ip_local_out
> + 49.48% ip_queue_xmit
> + 37.48% ip_build_and_send_pkt
> + 13.04% ip_send_skb
>
> I can not reproduce complete same high CPU usage on my testing
> environment, but top show that it has similar ratio of sys% and
> si% on one CPU:
>
> Tasks: 125 total, 2 running, 123 sleeping, 0 stopped, 0 zombie
> Cpu0 : 1.0%us, 30.7%sy, 0.0%ni, 18.8%id, 0.0%wa, 0.0%hi, 49.5%si,
> 0.0%st
>
> Well, it seem that I must acknowledge I was wrong here. however,
> I recall that I indeed ever encountered this in another benchmarking a
> small packets performance.
>
> I guess, this is since TX softirq and syscall context contend same lock
> in sch_direct_xmit(), is this right?
>
Em, do we have some means to decrease the lock contention here?
> thanks
>
> Yu
>
>>> The top shows the kernel is most cpu hog, the testing is simple,
>>> just a accept() -> epoll_ctl(ADD) loop, the ratio of cpu util sys% to
>>> si% is about 2:5.
>>
>> This ratio is not meaningful, if we dont know where time is spent.
>>
>>
>> I doubt epoll_ctl(ADD) is a problem here...
>>
>> If it is, batching the fds wont speed the thing anyway...
>>
>> I believe accept() is the problem here, because it contends with the
>> softirq processing the tcp session handshake.
>>
>>
>>
>>
>
>
^ permalink raw reply
* Re: TCP transmit performance regression
From: Ming Lei @ 2012-07-09 5:13 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Network Development, David Miller
In-Reply-To: <1341551764.3265.47.camel@edumazet-glaptop>
On Fri, Jul 6, 2012 at 1:16 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Fri, 2012-07-06 at 06:58 +0200, Eric Dumazet wrote:
>> On Fri, 2012-07-06 at 08:45 +0800, Ming Lei wrote:
>>
>> > Unfortunately, the patch still hasn't any improvement on the transmit
>> > performance of beagle-xm.
>>
>> Ah yes, I need to change usbnet as well to be able to fully recycle the
>> big skbs allocated in turbo mode.
>>
>> Right now they are constantly allocated/freed and this sucks if SLAB
>> wants to check poison bytes in debug mode.
>
> In the mean time, you also can use the following patch I have to polish,
> but this should give you a nice boost, since the big skb skb->head wont
> be checked by SLAB debug :
Unfortunately, the patch makes the result of the same test worsen than
without the patch, :-(
Thanks,
--
Ming Lei
^ permalink raw reply
* Re: [PATCH 2/2] ksz884x: fix Endian
From: RongQing Li @ 2012-07-09 5:26 UTC (permalink / raw)
To: Ben Hutchings; +Cc: netdev, Tristram.Ha
In-Reply-To: <1341614416.2923.12.camel@bwh-desktop.uk.solarflarecom.com>
2012/7/7, Ben Hutchings <bhutchings@solarflare.com>:
> On Thu, 2012-07-05 at 10:06 +0800, roy.qing.li@gmail.com wrote:
>> From: Li RongQing <roy.qing.li@gmail.com>
>>
>> ETH_P_IP is host Endian, skb->protocol is big Endian, when
>> compare them, we should change skb->protocol from big endian
>> to host endian, ntohs, not htons.
>>
>> CC: Tristram Ha <Tristram.Ha@micrel.com>
>> Signed-off-by: Li RongQing <roy.qing.li@gmail.com>
>> ---
>> drivers/net/ethernet/micrel/ksz884x.c | 2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/micrel/ksz884x.c
>> b/drivers/net/ethernet/micrel/ksz884x.c
>> index eaf9ff0..d9727f7 100644
>> --- a/drivers/net/ethernet/micrel/ksz884x.c
>> +++ b/drivers/net/ethernet/micrel/ksz884x.c
>> @@ -4882,7 +4882,7 @@ static netdev_tx_t netdev_tx(struct sk_buff *skb,
>> struct net_device *dev)
>> if (left) {
>> if (left < num ||
>> ((CHECKSUM_PARTIAL == skb->ip_summed) &&
>> - (ETH_P_IPV6 == htons(skb->protocol)))) {
>> + (ETH_P_IPV6 == ntohs(skb->protocol)))) {
>
> This should really be changed to the idiomatic 'skb->protocol ==
> htons(ETH_P_IPV6)'. For the current code, the compiler will probably
> generate a run-time byte-swap for little-endian systems.
>
> Ben.
>
>> struct sk_buff *org_skb = skb;
>>
>> skb = netdev_alloc_skb(dev, org_skb->len);
>
> --
> Ben Hutchings, Staff Engineer, Solarflare
> Not speaking for my employer; that's the marketing department's job.
> They asked us to note that Solarflare product names are trademarked.
>
>
>
^ permalink raw reply
* Re: [PATCH 2/2] ksz884x: fix Endian
From: RongQing Li @ 2012-07-09 5:30 UTC (permalink / raw)
To: Ben Hutchings; +Cc: netdev, Tristram.Ha
In-Reply-To: <CAJFZqHzm7=-PpsiNZJ9TgkDY2bt5WW7XwY6nBOa_E4eerRh1pg@mail.gmail.com>
Please ignore the first reply.
OK, I will change it as Ben's suggestion.
Thanks
-Roy
^ permalink raw reply
* Re: [net-next RFC V5 0/5] Multiqueue virtio-net
From: Jason Wang @ 2012-07-09 5:35 UTC (permalink / raw)
To: Ronen Hod
Cc: krkumar2, habanero, mashirle, kvm, mst, netdev, linux-kernel,
virtualization, edumazet, tahm, jwhan, davem, sri
In-Reply-To: <4FF9429A.8020508@redhat.com>
On 07/08/2012 04:19 PM, Ronen Hod wrote:
> On 07/05/2012 01:29 PM, Jason Wang wrote:
>> Hello All:
>>
>> This series is an update version of multiqueue virtio-net driver
>> based on
>> Krishna Kumar's work to let virtio-net use multiple rx/tx queues to
>> do the
>> packets reception and transmission. Please review and comments.
>>
>> Test Environment:
>> - Intel(R) Xeon(R) CPU E5620 @ 2.40GHz, 8 cores 2 numa nodes
>> - Two directed connected 82599
>>
>> Test Summary:
>>
>> - Highlights: huge improvements on TCP_RR test
>
> Hi Jason,
>
> It might be that the good TCP_RR results are due to the large number
> of sessions (50-250). Can you test it also with small number of sessions?
Sure, I would test them.
>
>> - Lowlights: regression on small packet transmission, higher cpu
>> utilization
>> than single queue, need further optimization
>>
>> Analysis of the performance result:
>>
>> - I count the number of packets sending/receiving during the test, and
>> multiqueue show much more ability in terms of packets per second.
>>
>> - For the tx regression, multiqueue send about 1-2 times of more packets
>> compared to single queue, and the packets size were much smaller
>> than single
>> queue does. I suspect tcp does less batching in multiqueue, so I
>> hack the
>> tcp_write_xmit() to forece more batching, multiqueue works as well as
>> singlequeue for both small transmission and throughput
>
> Could it be that since the CPUs are not busy they are available for
> immediate handling of the packets (little batching)? In such scenario
> the CPU utilization is not really interesting. What will happen on a
> busy machine?
>
The regression happnes when test guest transmission in stream test, the
cpu utilization is 100% in this situation.
> Ronen.
>
>>
>> - I didn't pack the accelerate RFS with virtio-net in this sereis as
>> it still
>> need further shaping, for the one that interested in this please see:
>> http://www.mail-archive.com/kvm@vger.kernel.org/msg64111.html
>>
>> Changes from V4:
>> - Add ability to negotiate the number of queues through control
>> virtqueue
>> - Ethtool -{L|l} support and default the tx/rx queue number to 1
>> - Expose the API to set irq affinity instead of irq itself
>>
>> Changes from V3:
>>
>> - Rebase to the net-next
>> - Let queue 2 to be the control virtqueue to obey the spec
>> - Prodives irq affinity
>> - Choose txq based on processor id
>>
>> References:
>>
>> - V4: https://lkml.org/lkml/2012/6/25/120
>> - V3: http://lwn.net/Articles/467283/
>>
>> Test result:
>>
>> 1) 1 vm 2 vcpu 1q vs 2q, 1 - 1q, 2 - 2q, no pinning
>>
>> - Guest to External Host TCP STREAM
>> sessions size throughput1 throughput2 norm1 norm2
>> 1 64 650.55 655.61 100% 24.88 24.86 99%
>> 2 64 1446.81 1309.44 90% 30.49 27.16 89%
>> 4 64 1430.52 1305.59 91% 30.78 26.80 87%
>> 8 64 1450.89 1270.82 87% 30.83 25.95 84%
>> 1 256 1699.45 1779.58 104% 56.75 59.08 104%
>> 2 256 4902.71 3446.59 70% 98.53 62.78 63%
>> 4 256 4803.76 2980.76 62% 97.44 54.68 56%
>> 8 256 5128.88 3158.74 61% 104.68 58.61 55%
>> 1 512 2837.98 2838.42 100% 89.76 90.41 100%
>> 2 512 6742.59 5495.83 81% 155.03 99.07 63%
>> 4 512 9193.70 5900.17 64% 202.84 106.44 52%
>> 8 512 9287.51 7107.79 76% 202.18 129.08 63%
>> 1 1024 4166.42 4224.98 101% 128.55 129.86 101%
>> 2 1024 6196.94 7823.08 126% 181.80 168.81 92%
>> 4 1024 9113.62 9219.49 101% 235.15 190.93 81%
>> 8 1024 9324.25 9402.66 100% 239.10 179.99 75%
>> 1 2048 7441.63 6534.04 87% 248.01 215.63 86%
>> 2 2048 7024.61 7414.90 105% 225.79 219.62 97%
>> 4 2048 8971.49 9269.00 103% 278.94 220.84 79%
>> 8 2048 9314.20 9359.96 100% 268.36 192.23 71%
>> 1 4096 8282.60 8990.08 108% 277.45 320.05 115%
>> 2 4096 9194.80 9293.78 101% 317.02 248.76 78%
>> 4 4096 9340.73 9313.19 99% 300.34 230.35 76%
>> 8 4096 9148.23 9347.95 102% 279.49 199.43 71%
>> 1 16384 8787.89 8766.31 99% 312.38 316.53 101%
>> 2 16384 9306.35 9156.14 98% 319.53 279.83 87%
>> 4 16384 9177.81 9307.50 101% 312.69 230.07 73%
>> 8 16384 9035.82 9188.00 101% 298.32 199.17 66%
>> - TCP RR
>> sessions size throughput1 throughput2 norm1 norm2
>> 50 1 54695.41 84164.98 153% 1957.33 1901.31 97%
>> 100 1 60141.88 88598.94 147% 2157.90 2000.45 92%
>> 250 1 74763.56 135584.22 181% 2541.94 2628.59 103%
>> 50 64 51628.38 82867.50 160% 1872.55 1812.16 96%
>> 100 64 60367.73 84080.60 139% 2215.69 1867.69 84%
>> 250 64 68502.70 124910.59 182% 2321.43 2495.76 107%
>> 50 128 53477.08 77625.07 145% 1905.10 1870.99 98%
>> 100 128 59697.56 74902.37 125% 2230.66 1751.03 78%
>> 250 128 71248.74 133963.55 188% 2453.12 2711.72 110%
>> 50 256 47663.86 67742.63 142% 1880.45 1735.30 92%
>> 100 256 54051.84 68738.57 127% 2123.03 1778.59 83%
>> 250 256 68250.06 124487.90 182% 2321.89 2598.60 111%
>> - External Host to Guest TCP STRAM
>> sessions size throughput1 throughput2 norm1 norm2
>> 1 64 847.71 864.83 102% 57.99 57.93 99%
>> 2 64 1690.82 1544.94 91% 80.13 55.09 68%
>> 4 64 3434.98 3455.53 100% 127.17 89.00 69%
>> 8 64 5890.19 6557.35 111% 194.70 146.52 75%
>> 1 256 2094.04 2109.14 100% 130.73 127.14 97%
>> 2 256 5218.13 3731.97 71% 219.15 114.02 52%
>> 4 256 6734.51 9213.47 136% 227.87 208.31 91%
>> 8 256 6452.86 9402.78 145% 224.83 207.77 92%
>> 1 512 3945.07 4203.68 106% 279.72 273.30 97%
>> 2 512 7878.96 8122.55 103% 278.25 231.71 83%
>> 4 512 7645.89 9402.13 122% 252.10 217.42 86%
>> 8 512 6657.06 9403.71 141% 239.81 214.89 89%
>> 1 1024 5729.06 5111.21 89% 289.38 303.09 104%
>> 2 1024 8097.27 8159.67 100% 269.29 242.97 90%
>> 4 1024 7778.93 8919.02 114% 261.28 205.50 78%
>> 8 1024 6458.02 9360.02 144% 221.26 208.09 94%
>> 1 2048 6426.94 5195.59 80% 292.52 307.47 105%
>> 2 2048 8221.90 9025.66 109% 283.80 242.25 85%
>> 4 2048 7364.72 8527.79 115% 248.10 198.36 79%
>> 8 2048 6760.63 9161.07 135% 230.53 205.12 88%
>> 1 4096 7247.02 6874.21 94% 276.23 287.68 104%
>> 2 4096 8346.04 8818.65 105% 281.49 254.81 90%
>> 4 4096 6710.00 9354.59 139% 216.41 210.13 97%
>> 8 4096 6265.69 9406.87 150% 206.69 210.92 102%
>> 1 16384 8159.50 8048.79 98% 266.94 283.11 106%
>> 2 16384 8525.66 8552.41 100% 294.36 239.27 81%
>> 4 16384 6042.24 8447.86 139% 200.21 196.40 98%
>> 8 16384 6432.63 9403.49 146% 211.48 206.13 97%
>>
>> 2) 1 vm 4 vcpu 1q vs 4q, 1 - 1q, 2 - 4q, no pinning
>>
>> - Guest to External Host TCP STREAM
>> sessions size throughput1 throughput2 norm1 norm2
>> 1 64 636.93 657.69 103% 23.55 24.42 103%
>> 2 64 1457.46 1268.78 87% 30.97 26.02 84%
>> 4 64 3062.86 2302.43 75% 41.00 29.64 72%
>> 8 64 3107.68 2308.32 74% 41.62 29.07 69%
>> 1 256 1743.50 1750.11 100% 59.00 56.63 95%
>> 2 256 4582.61 2870.31 62% 92.47 51.97 56%
>> 4 256 8440.96 4795.37 56% 135.10 56.39 41%
>> 8 256 9240.31 6654.82 72% 144.76 74.89 51%
>> 1 512 2918.25 2735.26 93% 91.08 86.47 94%
>> 2 512 8978.32 5107.95 56% 200.00 94.97 47%
>> 4 512 8850.39 6864.37 77% 190.32 101.09 53%
>> 8 512 9270.30 8483.01 91% 193.44 118.73 61%
>> 1 1024 4416.10 3679.70 83% 135.54 110.63 81%
>> 2 1024 9085.20 8770.48 96% 242.23 175.59 72%
>> 4 1024 9158.57 9011.56 98% 234.39 159.17 67%
>> 8 1024 9345.89 9067.43 97% 233.35 138.73 59%
>> 1 2048 8455.19 6077.94 71% 338.52 190.16 56%
>> 2 2048 9223.32 8237.73 89% 270.00 198.27 73%
>> 4 2048 9080.75 9257.63 101% 261.30 172.80 66%
>> 8 2048 9177.39 8977.10 97% 256.89 147.50 57%
>> 1 4096 8665.35 8394.78 96% 289.63 289.85 100%
>> 2 4096 7850.73 8857.86 112% 253.33 252.62 99%
>> 4 4096 9332.55 8508.37 91% 289.19 151.29 52%
>> 8 4096 8482.30 9146.80 107% 255.41 156.02 61%
>> 1 16384 8825.72 8778.26 99% 314.60 308.89 98%
>> 2 16384 9283.85 8927.40 96% 316.48 246.98 78%
>> 4 16384 7766.95 8708.06 112% 265.25 155.59 58%
>> 8 16384 8945.55 8940.23 99% 298.45 151.32 50%
>> - TCP_RR
>> sessions size throughput1 throughput2 norm1 norm2
>> 50 1 60848.70 81719.39 134% 2196.86 1551.05 70%
>> 100 1 61886.19 81425.02 131% 2215.76 1517.52 68%
>> 250 1 72058.41 162597.84 225% 2441.84 2278.14 93%
>> 50 64 51646.93 74160.10 143% 1861.07 1322.22 71%
>> 100 64 57574.86 83488.26 145% 2076.54 1479.79 71%
>> 250 64 67583.35 138482.15 204% 2314.46 2022.83 87%
>> 50 128 59931.51 71633.03 119% 2244.60 1309.18 58%
>> 100 128 58329.80 73104.90 125% 2202.98 1329.52 60%
>> 250 128 71021.55 161067.73 226% 2469.11 2205.28 89%
>> 50 256 47509.24 64330.24 135% 1915.75 1269.90 66%
>> 100 256 49293.03 68507.94 138% 1939.75 1263.64 65%
>> 250 256 63169.07 138390.68 219% 2255.47 2098.13 93%
>> - External Host to Guest TCP STREAM
>> sessions size throughput1 throughput2 norm1 norm2
>> 1 64 850.18 854.96 100% 56.94 58.25 102%
>> 2 64 1659.12 1730.25 104% 81.65 67.57 82%
>> 4 64 3254.70 3397.17 104% 118.57 76.21 64%
>> 8 64 6251.97 6389.29 102% 207.68 104.21 50%
>> 1 256 2029.14 2105.18 103% 116.45 119.69 102%
>> 2 256 5412.02 4260.32 78% 240.87 139.73 58%
>> 4 256 7777.28 8743.12 112% 263.20 174.65 66%
>> 8 256 6459.51 9388.93 145% 218.94 158.37 72%
>> 1 512 4566.31 4269.30 93% 274.74 289.83 105%
>> 2 512 7444.52 8240.64 110% 286.24 243.74 85%
>> 4 512 7722.29 9391.16 121% 261.96 180.36 68%
>> 8 512 6228.50 9134.52 146% 209.17 161.00 76%
>> 1 1024 4965.50 4953.68 99% 307.64 280.48 91%
>> 2 1024 8270.08 7733.71 93% 288.32 197.04 68%
>> 4 1024 7551.04 9394.58 124% 268.41 206.62 76%
>> 8 1024 6307.78 9179.03 145% 216.67 159.63 73%
>> 1 2048 5741.12 5948.80 103% 290.34 268.66 92%
>> 2 2048 7932.79 8766.05 110% 262.96 215.90 82%
>> 4 2048 6907.55 9255.97 133% 233.56 203.96 87%
>> 8 2048 6037.22 9399.41 155% 197.14 164.09 83%
>> 1 4096 7131.70 7535.10 105% 279.43 275.12 98%
>> 2 4096 8109.17 9348.04 115% 274.29 211.49 77%
>> 4 4096 6878.92 9319.13 135% 244.21 192.06 78%
>> 8 4096 6265.92 9408.35 150% 211.85 159.26 75%
>> 1 16384 8288.01 8596.39 103% 272.85 290.22 106%
>> 2 16384 8166.29 9280.12 113% 277.04 236.61 85%
>> 4 16384 6446.97 9382.22 145% 222.91 187.24 83%
>> 8 16384 6066.98 9405.51 155% 198.98 157.09 78%
>>
>> 3) 2 vms each with 2 vcpus, 1q vs 2q - pin vhost/vcpu in the same node
>>
>> - 2 Guests to External Hosts TCP STREAM
>> sessions size throughput1 throughput2 norm1 norm2
>> 1 64 1442.07 1475.11 102% 30.82 31.21 101%
>> 2 64 3124.87 2900.93 92% 40.29 35.95 89%
>> 4 64 3166.52 2864.04 90% 40.70 35.47 87%
>> 8 64 3141.45 2848.94 90% 40.38 35.34 87%
>> 1 256 3628.54 3711.73 102% 68.47 70.22 102%
>> 2 256 7806.95 7586.69 97% 111.23 84.38 75%
>> 4 256 8823.65 7612.74 86% 132.92 85.04 63%
>> 8 256 9194.89 9373.41 101% 135.98 119.62 87%
>> 1 512 7106.67 7128.00 100% 124.79 124.30 99%
>> 2 512 9190.22 9397.33 102% 180.84 149.34 82%
>> 4 512 9401.01 9376.67 99% 173.00 140.15 81%
>> 8 512 8572.84 9032.90 105% 150.49 127.58 84%
>> 1 1024 9361.93 9379.24 100% 205.81 202.94 98%
>> 2 1024 9386.69 9389.04 100% 201.78 165.75 82%
>> 4 1024 9403.43 9378.54 99% 195.33 152.06 77%
>> 8 1024 9213.63 9180.64 99% 178.99 141.51 79%
>> 1 2048 9338.95 9384.67 100% 223.22 227.86 102%
>> 2 2048 9389.28 9389.45 100% 202.37 170.08 84%
>> 4 2048 9405.86 9388.71 99% 193.76 161.54 83%
>> 8 2048 9352.40 9384.06 100% 189.16 157.06 83%
>> 1 4096 9380.74 9384.90 100% 239.37 241.56 100%
>> 2 4096 9393.47 9376.74 99% 213.84 195.61 91%
>> 4 4096 9393.85 9381.50 99% 198.06 170.18 85%
>> 8 4096 9400.41 9232.31 98% 192.87 163.56 84%
>> 1 16384 9348.18 9335.55 99% 253.02 254.86 100%
>> 2 16384 9384.97 9359.53 99% 218.56 208.59 95%
>> 4 16384 9326.60 9382.15 100% 206.24 179.72 87%
>> 8 16384 9355.82 9392.85 100% 198.22 172.89 87%
>> - TCP RR
>> sessions size throughput1 throughput2 norm1 norm2
>> 50 1 200340.33 261750.19 130% 2935.27 3018.59 102%
>> 100 1 236141.58 266304.49 112% 3452.16 3071.74 88%
>> 250 1 361574.59 320825.08 88% 4972.98 3705.70 74%
>> 50 64 225748.53 242671.12 107% 3011.48 2869.07 95%
>> 100 64 249885.37 260453.72 104% 3240.21 3063.67 94%
>> 250 64 360341.12 310775.60 86% 4682.42 3657.91 78%
>> 50 128 227995.27 289320.38 126% 2950.92 3479.37 117%
>> 100 128 239491.11 291135.77 121% 3099.55 3508.75 113%
>> 250 128 390390.68 362484.35 92% 5042.30 4368.52 86%
>> 50 256 222604.51 317140.97 142% 3058.08 3839.39 125%
>> 100 256 254770.92 335606.03 131% 3326.16 4046.65 121%
>> 250 256 400584.52 436749.22 109% 5220.79 5278.86 101%
>> - External Host to 2 Guests
>> sessions size throughput1 throughput2 norm1 norm2
>> 1 64 1667.99 1684.50 100% 59.66 60.77 101%
>> 2 64 3338.83 3379.97 101% 83.61 64.82 77%
>> 4 64 6613.65 6619.11 100% 131.00 97.19 74%
>> 8 64 6553.07 6418.31 97% 141.35 98.27 69%
>> 1 256 3938.40 4068.52 103% 125.21 123.76 98%
>> 2 256 9215.57 9210.88 99% 185.31 154.27 83%
>> 4 256 9407.29 9008.13 95% 186.72 150.01 80%
>> 8 256 9377.17 9385.57 100% 190.28 137.59 72%
>> 1 512 7360.19 6984.80 94% 214.09 211.66 98%
>> 2 512 9392.91 9401.88 100% 193.92 173.11 89%
>> 4 512 9382.64 9394.34 100% 189.27 145.80 77%
>> 8 512 9308.60 9094.08 97% 189.70 141.26 74%
>> 1 1024 9153.26 9066.06 99% 223.07 219.95 98%
>> 2 1024 9393.38 9398.43 100% 194.02 173.82 89%
>> 4 1024 9395.92 8960.73 95% 192.61 145.82 75%
>> 8 1024 9388.92 9399.08 100% 191.18 143.87 75%
>> 1 2048 9355.32 9240.63 98% 221.50 223.03 100%
>> 2 2048 9395.68 9399.62 100% 193.31 177.21 91%
>> 4 2048 9397.67 9399.56 100% 195.25 157.53 80%
>> 8 2048 9397.89 9401.70 100% 197.57 146.96 74%
>> 1 4096 9375.84 9381.72 100% 223.06 225.06 100%
>> 2 4096 9389.47 9396.00 100% 193.91 197.13 101%
>> 4 4096 9397.45 9400.11 100% 192.33 163.60 85%
>> 8 4096 9105.40 9415.76 103% 192.71 140.41 72%
>> 1 16384 9381.53 9381.40 99% 223.53 225.66 100%
>> 2 16384 9387.90 9395.44 100% 193.34 177.03 91%
>> 4 16384 9397.92 9410.98 100% 195.04 151.14 77%
>> 8 16384 9259.00 9419.48 101% 194.91 153.48 78%
>>
>> 4) Local vm to vm 2 vcpu 1q vs 2q - pin vcpu/thread in the same numa
>> node
>>
>> - VM to VM TCP STREAM
>> sessions size throughput1 throughput2 norm1 norm2
>> 1 64 576.05 576.14 100% 12.25 12.32 100%
>> 2 64 1266.75 1160.04 91% 19.10 16.05 84%
>> 4 64 1267.34 1123.70 88% 19.08 15.51 81%
>> 8 64 1230.88 1174.70 95% 18.53 15.58 84%
>> 1 256 1311.00 1303.02 99% 25.34 25.35 100%
>> 2 256 5400.26 2794.00 51% 75.92 36.43 47%
>> 4 256 5200.67 2818.88 54% 72.81 33.92 46%
>> 8 256 5234.55 2893.74 55% 73.10 34.97 47%
>> 1 512 3244.09 3263.72 100% 56.48 56.65 100%
>> 2 512 8172.16 4661.15 57% 119.05 67.89 57%
>> 4 512 10567.44 7063.25 66% 147.76 77.27 52%
>> 8 512 10477.87 8471.33 80% 145.94 102.91 70%
>> 1 1024 5432.54 5333.99 98% 93.69 92.38 98%
>> 2 1024 12590.24 9259.97 73% 185.37 135.28 72%
>> 4 1024 15600.53 10731.93 68% 222.20 123.60 55%
>> 8 1024 16222.87 10704.85 65% 227.05 113.81 50%
>> 1 2048 6667.61 7484.37 112% 116.75 129.72 111%
>> 2 2048 8180.43 11500.88 140% 137.84 156.64 113%
>> 4 2048 15127.93 14416.16 95% 227.60 154.59 67%
>> 8 2048 16381.79 14794.10 90% 244.29 158.45 64%
>> 1 4096 7375.63 8948.90 121% 131.97 156.57 118%
>> 2 4096 9321.16 14443.21 154% 161.24 163.74 101%
>> 4 4096 13028.45 15984.94 122% 212.78 171.26 80%
>> 8 4096 15611.28 18810.54 120% 245.15 198.65 81%
>> 1 16384 15304.38 14202.08 92% 259.94 244.04 93%
>> 2 16384 15508.97 15913.09 102% 261.30 244.26 93%
>> 4 16384 14859.98 20164.34 135% 248.29 214.26 86%
>> 8 16384 15594.59 19960.99 127% 253.79 211.27 83%
>> - TCP RR
>> sessions size throughput1 throughput2 norm1 norm2
>> 50 1 54972.51 69820.99 127% 1133.58 1063.58 93%
>> 100 1 55847.16 72407.93 129% 1155.73 1024.35 88%
>> 250 1 60066.23 108266.50 180% 1114.30 1323.55 118%
>> 50 64 48727.63 62378.32 128% 1014.29 888.78 87%
>> 100 64 51804.65 69250.51 133% 1077.78 986.97 91%
>> 250 64 61278.68 100015.78 163% 1076.93 1243.18 115%
>> 50 256 51593.29 62046.22 120% 1069.14 871.08 81%
>> 100 256 51647.00 68197.43 132% 1071.66 958.51 89%
>> 250 256 60433.88 99072.59 163% 1072.41 1199.10 111%
>> 50 512 52177.79 66483.77 127% 1082.65 960.82 88%
>> 100 512 50351.67 62537.63 124% 1041.61 876.41 84%
>> 250 512 60510.14 103856.79 171% 1055.21 1245.17 118%
>>
>>
>> Jason Wang (4):
>> virtio_ring: move queue_index to vring_virtqueue
>> virtio: intorduce an API to set affinity for a virtqueue
>> virtio_net: multiqueue support
>> virtio_net: support negotiating the number of queues through ctrl vq
>>
>> Krishna Kumar (1):
>> virtio_net: Introduce VIRTIO_NET_F_MULTIQUEUE
>>
>> drivers/net/virtio_net.c | 792
>> +++++++++++++++++++++++++++++------------
>> drivers/virtio/virtio_mmio.c | 5 +-
>> drivers/virtio/virtio_pci.c | 58 +++-
>> drivers/virtio/virtio_ring.c | 17 +
>> include/linux/virtio.h | 4 +
>> include/linux/virtio_config.h | 21 ++
>> include/linux/virtio_net.h | 10 +
>> 7 files changed, 677 insertions(+), 230 deletions(-)
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
^ permalink raw reply
* Re: [PATCH 2/2] ksz884x: fix Endian
From: Joe Perches @ 2012-07-09 5:44 UTC (permalink / raw)
To: RongQing Li; +Cc: Ben Hutchings, netdev, Tristram.Ha
In-Reply-To: <CAJFZqHzm7=-PpsiNZJ9TgkDY2bt5WW7XwY6nBOa_E4eerRh1pg@mail.gmail.com>
On Mon, 2012-07-09 at 13:26 +0800, RongQing Li wrote:
> 2012/7/7, Ben Hutchings <bhutchings@solarflare.com>:
> > On Thu, 2012-07-05 at 10:06 +0800, roy.qing.li@gmail.com wrote:
> >> ETH_P_IP is host Endian, skb->protocol is big Endian, when
> >> compare them, we should change skb->protocol from big endian
> >> to host endian, ntohs, not htons.
[]
> >> diff --git a/drivers/net/ethernet/micrel/ksz884x.c
[]
> >> @@ -4882,7 +4882,7 @@ static netdev_tx_t netdev_tx(struct sk_buff *skb,
> >> struct net_device *dev)
> >> if (left) {
> >> if (left < num ||
> >> ((CHECKSUM_PARTIAL == skb->ip_summed) &&
> >> - (ETH_P_IPV6 == htons(skb->protocol)))) {
> >> + (ETH_P_IPV6 == ntohs(skb->protocol)))) {
> >
> > This should really be changed to the idiomatic 'skb->protocol ==
> > htons(ETH_P_IPV6)'. For the current code, the compiler will probably
> > generate a run-time byte-swap for little-endian systems.
True. Perhaps this would be better written as:
if (left) {
if (left < num ||
(ip->ip_summed == CHECKSUM_PARTIAL &&
skb->protocol == htons(ETH_P_IPV6))) {
etc...
^ 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