* Re: [PATCH 1/2 v5] usbnet: allow status interrupt URB to always be active
From: Ming Lei @ 2013-04-11 8:37 UTC (permalink / raw)
To: Bjørn Mork
Cc: Oliver Neukum, Dan Williams, Elina Pasheva, Network Development,
linux-usb, Rory Filer, Phil Sutter
In-Reply-To: <87txndwkx1.fsf@nemi.mork.no>
On Thu, Apr 11, 2013 at 4:06 PM, Bjørn Mork <bjorn@mork.no> wrote:
> Oliver Neukum <oliver@neukum.org> writes:
>
> My immediate thought was that someone also might want to use this new
> API from atomic context, e.g. calling it directly from an URB callback.
I am wondering it is a valid use case, and if there is one URB submitted,
the interrupt URB for status has been submitted already, hasn't it?
> But that is of course not possible taking a mutex. Could the lock
> preventing interrupt_count maybe be a spinlock instead? Or am I on the
> completely wrong track here?
Also it is a bit odd that the 'start' API is allowed in atomic context, but
the 'stop' API isn't allowed, and it is very easy to cause unbalanced counter.
>
> In any case, I don't see the point unnecessarily limiting the API by
> dropping the memflags. What possible problem would that solve?
If you think 'start' API should be called in atomic context, the memflags
should be always 'GFP_ATOMIC'. I let Oliver explain why GFP_NOIO
is needed in other cases.
Thanks
--
Ming Lei
^ permalink raw reply
* [PATCH v2] net: mvmdio: add clocks property to binding documentation
From: Sebastian Hesselbarth @ 2013-04-11 9:24 UTC (permalink / raw)
To: Sebastian Hesselbarth
Cc: Grant Likely, Rob Herring, Rob Landley, David S. Miller,
Florian Fainelli, Thomas Petazzoni, Greg Kroah-Hartman, netdev,
devicetree-discuss, linux-doc, linux-kernel
In-Reply-To: <1365615391-26244-1-git-send-email-sebastian.hesselbarth@gmail.com>
Commit 3d604da1e9547c09c9dcc0ee443c306c9ae1a480
("net: mvmdio: get and enable optional clock")
was missing an update of the corresponding device tree binding
documentation. This patch adds the clocks property to mvmdio
binding documentation.
Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
---
Changes from v1:
- name commit and hash in commit message
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Rob Herring <rob.herring@calxeda.com>
Cc: Rob Landley <rob@landley.net>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Florian Fainelli <florian@openwrt.org>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: netdev@vger.kernel.org
Cc: devicetree-discuss@lists.ozlabs.org
Cc: linux-doc@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
Documentation/devicetree/bindings/net/marvell-orion-mdio.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/net/marvell-orion-mdio.txt b/Documentation/devicetree/bindings/net/marvell-orion-mdio.txt
index 052b5f2..9417e54 100644
--- a/Documentation/devicetree/bindings/net/marvell-orion-mdio.txt
+++ b/Documentation/devicetree/bindings/net/marvell-orion-mdio.txt
@@ -11,6 +11,7 @@ Required properties:
Optional properties:
- interrupts: interrupt line number for the SMI error/done interrupt
+- clocks: Phandle to the clock control device and gate bit
The child nodes of the MDIO driver are the individual PHY devices
connected to this MDIO bus. They must have a "reg" property given the
--
1.7.10.4
^ permalink raw reply related
* [PATCH 0/2] net: mv643xx_eth: use managed clk and allocation
From: Sebastian Hesselbarth @ 2013-04-11 9:29 UTC (permalink / raw)
To: Sebastian Hesselbarth
Cc: Andrew Lunn, Jason Cooper, Sergei Shtylyov,
linux-doc-u79uwXL29TY76Z2rM5mHXA,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Paul Mackerras,
netdev-u79uwXL29TY76Z2rM5mHXA,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ, Florian Fainelli,
Lennert Buytenhek
With introduction of common clock framework and the ability to provide
gated clocks, mv643xx_eth required calls to get and enable these clock
gates on some platforms. Back then, common clock framework api wasn't
safe for architectures without support for common clocks. This has
changed now and there are also managed (devm_) counterparts for clock
related functions.
The second patch in this series, also converts kzalloc to devm_kzalloc
where applicable.
Both patches have been sent to the corresponding mailing lists as
individual patches before. To get the order required to apply them right,
this patch set combines both patches into one set.
Sebastian Hesselbarth (2):
net: mv643xx_eth: add shared clk and cleanup existing clk handling
net: mv643xx_eth: use managed devm_kzalloc
Documentation/devicetree/bindings/marvell.txt | 3 ++
drivers/net/ethernet/marvell/mv643xx_eth.c | 44 +++++++++----------------
2 files changed, 18 insertions(+), 29 deletions(-)
---
Cc: Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
Cc: Rob Herring <rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>
Cc: Rob Landley <rob-VoJi6FS/r0vR7s880joybQ@public.gmane.org>
Cc: Lennert Buytenhek <buytenh-OLH4Qvv75CYX/NnBR394Jw@public.gmane.org>
Cc: Sebastian Hesselbarth <sebastian.hesselbarth-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org>
Cc: Jason Cooper <jason-NLaQJdtUoK4Be96aLqz0jA@public.gmane.org>
Cc: Florian Fainelli <florian-p3rKhJxN3npAfugRpC6u6w@public.gmane.org>
Cc: Sergei Shtylyov <sergei.shtylyov-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org>
Cc: Benjamin Herrenschmidt <benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
Cc: Paul Mackerras <paulus-eUNUBHrolfbYtjvyW6yDsg@public.gmane.org>
Cc: linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
Cc: linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
--
1.7.10.4
^ permalink raw reply
* [PATCH 1/2] net: mv643xx_eth: add shared clk and cleanup existing clk handling
From: Sebastian Hesselbarth @ 2013-04-11 9:29 UTC (permalink / raw)
To: Sebastian Hesselbarth
Cc: Andrew Lunn, Jason Cooper, Sergei Shtylyov,
linux-doc-u79uwXL29TY76Z2rM5mHXA,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Paul Mackerras,
netdev-u79uwXL29TY76Z2rM5mHXA,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ, Florian Fainelli,
Lennert Buytenhek
In-Reply-To: <1365672574-31123-1-git-send-email-sebastian.hesselbarth-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
This patch adds an optional shared block clock to avoid lockups on
clock gated controllers. Besides the new clock, clock handling for
existing clocks is cleaned up and moved to devm_clk_get. Device
tree binding documentation is updated for the new clocks property.
Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
Cc: Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
Cc: Rob Herring <rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>
Cc: Rob Landley <rob-VoJi6FS/r0vR7s880joybQ@public.gmane.org>
Cc: Lennert Buytenhek <buytenh-OLH4Qvv75CYX/NnBR394Jw@public.gmane.org>
Cc: Sebastian Hesselbarth <sebastian.hesselbarth-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org>
Cc: Jason Cooper <jason-NLaQJdtUoK4Be96aLqz0jA@public.gmane.org>
Cc: Florian Fainelli <florian-p3rKhJxN3npAfugRpC6u6w@public.gmane.org>
Cc: Sergei Shtylyov <sergei.shtylyov-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org>
Cc: Benjamin Herrenschmidt <benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
Cc: Paul Mackerras <paulus-eUNUBHrolfbYtjvyW6yDsg@public.gmane.org>
Cc: linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
Cc: linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
---
Documentation/devicetree/bindings/marvell.txt | 3 +++
drivers/net/ethernet/marvell/mv643xx_eth.c | 27 ++++++++++---------------
2 files changed, 14 insertions(+), 16 deletions(-)
diff --git a/Documentation/devicetree/bindings/marvell.txt b/Documentation/devicetree/bindings/marvell.txt
index f1533d9..f7a0da6 100644
--- a/Documentation/devicetree/bindings/marvell.txt
+++ b/Documentation/devicetree/bindings/marvell.txt
@@ -115,6 +115,9 @@ prefixed with the string "marvell,", for Marvell Technology Group Ltd.
- compatible : "marvell,mv64360-eth-block"
- reg : Offset and length of the register set for this block
+ Optional properties:
+ - clocks : Phandle to the clock control device and gate bit
+
Example Discovery Ethernet block node:
ethernet-block@2000 {
#address-cells = <1>;
diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c b/drivers/net/ethernet/marvell/mv643xx_eth.c
index aedbd82..bbe6104 100644
--- a/drivers/net/ethernet/marvell/mv643xx_eth.c
+++ b/drivers/net/ethernet/marvell/mv643xx_eth.c
@@ -268,7 +268,7 @@ struct mv643xx_eth_shared_private {
int extended_rx_coal_limit;
int tx_bw_control;
int tx_csum_limit;
-
+ struct clk *clk;
};
#define TX_BW_CONTROL_ABSENT 0
@@ -410,9 +410,7 @@ struct mv643xx_eth_private {
/*
* Hardware-specific parameters.
*/
-#if defined(CONFIG_HAVE_CLK)
struct clk *clk;
-#endif
unsigned int t_clk;
};
@@ -2569,6 +2567,10 @@ static int mv643xx_eth_shared_probe(struct platform_device *pdev)
if (msp->base == NULL)
goto out_free;
+ msp->clk = devm_clk_get(&pdev->dev, NULL);
+ if (!IS_ERR(msp->clk))
+ clk_prepare_enable(msp->clk);
+
/*
* (Re-)program MBUS remapping windows if we are asked to.
*/
@@ -2595,6 +2597,8 @@ static int mv643xx_eth_shared_remove(struct platform_device *pdev)
struct mv643xx_eth_shared_private *msp = platform_get_drvdata(pdev);
iounmap(msp->base);
+ if (!IS_ERR(msp->clk))
+ clk_disable_unprepare(msp->clk);
kfree(msp);
return 0;
@@ -2801,13 +2805,12 @@ static int mv643xx_eth_probe(struct platform_device *pdev)
* it to override the default.
*/
mp->t_clk = 133000000;
-#if defined(CONFIG_HAVE_CLK)
- mp->clk = clk_get(&pdev->dev, (pdev->id ? "1" : "0"));
+ mp->clk = devm_clk_get(&pdev->dev, NULL);
if (!IS_ERR(mp->clk)) {
clk_prepare_enable(mp->clk);
mp->t_clk = clk_get_rate(mp->clk);
}
-#endif
+
set_params(mp, pd);
netif_set_real_num_tx_queues(dev, mp->txq_count);
netif_set_real_num_rx_queues(dev, mp->rxq_count);
@@ -2889,12 +2892,8 @@ static int mv643xx_eth_probe(struct platform_device *pdev)
return 0;
out:
-#if defined(CONFIG_HAVE_CLK)
- if (!IS_ERR(mp->clk)) {
+ if (!IS_ERR(mp->clk))
clk_disable_unprepare(mp->clk);
- clk_put(mp->clk);
- }
-#endif
free_netdev(dev);
return err;
@@ -2909,12 +2908,8 @@ static int mv643xx_eth_remove(struct platform_device *pdev)
phy_detach(mp->phy);
cancel_work_sync(&mp->tx_timeout_task);
-#if defined(CONFIG_HAVE_CLK)
- if (!IS_ERR(mp->clk)) {
+ if (!IS_ERR(mp->clk))
clk_disable_unprepare(mp->clk);
- clk_put(mp->clk);
- }
-#endif
free_netdev(mp->dev);
--
1.7.10.4
^ permalink raw reply related
* [PATCH v2 2/2] net: mv643xx_eth: use managed devm_kzalloc
From: Sebastian Hesselbarth @ 2013-04-11 9:29 UTC (permalink / raw)
To: Sebastian Hesselbarth
Cc: Grant Likely, Rob Herring, Rob Landley, Lennert Buytenhek,
Andrew Lunn, Jason Cooper, Florian Fainelli, Sergei Shtylyov,
Benjamin Herrenschmidt, Paul Mackerras, linuxppc-dev,
devicetree-discuss, linux-doc, linux-kernel, netdev
In-Reply-To: <1365672574-31123-1-git-send-email-sebastian.hesselbarth@gmail.com>
This patch moves shared private data kzalloc to managed devm_kzalloc and
cleans now unneccessary kfree and error handling.
Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
---
Changes from v1:
- replaced EADDRNOTAVAIL with ENOMEM on failing ioremap (Reported by
Sergei Shtylyov)
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Rob Herring <rob.herring@calxeda.com>
Cc: Rob Landley <rob@landley.net>
Cc: Lennert Buytenhek <buytenh@wantstofly.org>
Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Florian Fainelli <florian@openwrt.org>
Cc: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: linuxppc-dev@lists.ozlabs.org
Cc: devicetree-discuss@lists.ozlabs.org
Cc: linux-doc@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: netdev@vger.kernel.org
---
drivers/net/ethernet/marvell/mv643xx_eth.c | 17 ++++-------------
1 file changed, 4 insertions(+), 13 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c b/drivers/net/ethernet/marvell/mv643xx_eth.c
index bbe6104..305038f 100644
--- a/drivers/net/ethernet/marvell/mv643xx_eth.c
+++ b/drivers/net/ethernet/marvell/mv643xx_eth.c
@@ -2547,25 +2547,22 @@ static int mv643xx_eth_shared_probe(struct platform_device *pdev)
struct mv643xx_eth_shared_private *msp;
const struct mbus_dram_target_info *dram;
struct resource *res;
- int ret;
if (!mv643xx_eth_version_printed++)
pr_notice("MV-643xx 10/100/1000 ethernet driver version %s\n",
mv643xx_eth_driver_version);
- ret = -EINVAL;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (res == NULL)
- goto out;
+ return -EINVAL;
- ret = -ENOMEM;
- msp = kzalloc(sizeof(*msp), GFP_KERNEL);
+ msp = devm_kzalloc(&pdev->dev, sizeof(*msp), GFP_KERNEL);
if (msp == NULL)
- goto out;
+ return -ENOMEM;
msp->base = ioremap(res->start, resource_size(res));
if (msp->base == NULL)
- goto out_free;
+ return -ENOMEM;
msp->clk = devm_clk_get(&pdev->dev, NULL);
if (!IS_ERR(msp->clk))
@@ -2585,11 +2582,6 @@ static int mv643xx_eth_shared_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, msp);
return 0;
-
-out_free:
- kfree(msp);
-out:
- return ret;
}
static int mv643xx_eth_shared_remove(struct platform_device *pdev)
@@ -2599,7 +2591,6 @@ static int mv643xx_eth_shared_remove(struct platform_device *pdev)
iounmap(msp->base);
if (!IS_ERR(msp->clk))
clk_disable_unprepare(msp->clk);
- kfree(msp);
return 0;
}
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH 0/2] net: mv643xx_eth: use managed clk and allocation
From: Florian Fainelli @ 2013-04-11 9:32 UTC (permalink / raw)
To: Sebastian Hesselbarth
Cc: Grant Likely, Rob Herring, Rob Landley, Lennert Buytenhek,
Andrew Lunn, Jason Cooper, Sergei Shtylyov,
Benjamin Herrenschmidt, Paul Mackerras, linuxppc-dev,
devicetree-discuss, linux-doc, linux-kernel, netdev
In-Reply-To: <1365672574-31123-1-git-send-email-sebastian.hesselbarth@gmail.com>
Le 04/11/13 11:29, Sebastian Hesselbarth a écrit :
> With introduction of common clock framework and the ability to provide
> gated clocks, mv643xx_eth required calls to get and enable these clock
> gates on some platforms. Back then, common clock framework api wasn't
> safe for architectures without support for common clocks. This has
> changed now and there are also managed (devm_) counterparts for clock
> related functions.
>
> The second patch in this series, also converts kzalloc to devm_kzalloc
> where applicable.
>
> Both patches have been sent to the corresponding mailing lists as
> individual patches before. To get the order required to apply them right,
> this patch set combines both patches into one set.
>
> Sebastian Hesselbarth (2):
> net: mv643xx_eth: add shared clk and cleanup existing clk handling
> net: mv643xx_eth: use managed devm_kzalloc
Looks good, thanks Sebastian!
Acked-by: Florian Fainelli <florian@openwrt.org>
--
Florian
^ permalink raw reply
* [net-next PATCH 0/2] vlan TSO support for virtio-net
From: Jason Wang @ 2013-04-11 9:32 UTC (permalink / raw)
To: davem, mst, netdev, linux-kernel; +Cc: Jason Wang
This series simply enable the vlan TSO support for virtio-net by just initialize
vlan_features for virtio-net and tun which allows vlan TSO packets to be
processed in both TX and RX path for virtio-net.
Netperf shows great improvements on stream tests:
Before:
Guest sending: 4162.35 10^6bits/sec
Guest receiving: 2786.67 10^6bit/sec
After:
Guest sending: 9365.42 10^6bits/sec
Guest receiving: 8085.49 10^6bit/sec
Jason Wang (2):
virtio-net: initialize vlan_features
tuntap: initialize vlan_features
drivers/net/tun.c | 1 +
drivers/net/virtio_net.c | 2 ++
2 files changed, 3 insertions(+), 0 deletions(-)
^ permalink raw reply
* [net-next PATCH 1/2] virtio-net: initialize vlan_features
From: Jason Wang @ 2013-04-11 9:32 UTC (permalink / raw)
To: davem, mst, netdev, linux-kernel; +Cc: Jason Wang, Rusty Russell
In-Reply-To: <1365672742-42258-1-git-send-email-jasowang@redhat.com>
There's nothing that prevent passing the device features of virtio_net to its
vlan device. So this patch simply passes those to vlan device to benefit from
advanced features.
Netperf shows better sending performance for vlan device since TSO can work on
vlan now.
before:
netperf -H 192.168.5.2
MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.5.2 ()
port 0 AF_INET : demo
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec
87380 16384 16384 10.00 4162.35
after:
netperf -H 192.168.5.2
MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.5.2 ()
port 0 AF_INET : demo
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec
87380 16384 16384 10.00 9365.42
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: "Michael S. Tsirkin" <mst@redhat.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
---
drivers/net/virtio_net.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index f7d67e8..8fdfde6 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -1511,6 +1511,8 @@ static int virtnet_probe(struct virtio_device *vdev)
/* (!csum && gso) case will be fixed by register_netdev() */
}
+ dev->vlan_features = dev->features;
+
/* Configuration may specify what MAC to use. Otherwise random. */
if (virtio_config_val_len(vdev, VIRTIO_NET_F_MAC,
offsetof(struct virtio_net_config, mac),
--
1.7.1
^ permalink raw reply related
* [net-next PATCH 2/2] tuntap: initialize vlan_features
From: Jason Wang @ 2013-04-11 9:32 UTC (permalink / raw)
To: davem, mst, netdev, linux-kernel; +Cc: Jason Wang
In-Reply-To: <1365672742-42258-1-git-send-email-jasowang@redhat.com>
The vlan_features was zero which prevents vlan GSO packets to be transmitted to
userspace. This is suboptimal so enable this by initialize vlan_features for
tuntap.
Netperf shows better performance of guest receiving since vlan TSO works for
tuntap:
before:
netperf -H 192.168.5.4
MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.5.4 ()
port 0 AF_INET : demo
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec
87380 16384 16384 10.01 2786.67
after:
netperf -H 192.168.5.4
MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.5.4 ()
port 0 AF_INET : demo
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec
87380 16384 16384 10.00 8085.49
Signed-off-by: Jason Wang <jasowang@redhat.com>
---
drivers/net/tun.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 29538e6..316c759 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -1656,6 +1656,7 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr)
dev->hw_features = NETIF_F_SG | NETIF_F_FRAGLIST |
TUN_USER_FEATURES;
dev->features = dev->hw_features;
+ dev->vlan_features = dev->features;
INIT_LIST_HEAD(&tun->disabled);
err = tun_attach(tun, file);
--
1.7.1
^ permalink raw reply related
* Re: [PATCH net-next] ptp: dynamic allocation of PHC char devices
From: Jiri Benc @ 2013-04-11 9:52 UTC (permalink / raw)
To: Ben Hutchings; +Cc: David Miller, netdev, richardcochran
In-Reply-To: <1365617559.2581.25.camel@bwh-desktop.uk.solarflarecom.com>
On Wed, 10 Apr 2013 19:12:39 +0100, Ben Hutchings wrote:
> On Wed, 2013-04-10 at 13:49 -0400, David Miller wrote:
> > Can't multiple (unrelated) devices carve out minor space in the same
> > major? Isn't that why it's designed this way?
>
> Only at a level above the core char device functions, e.g.
> misc_register() for singleton devices. Unless I'm very much mistaken,
> when you allocate a char device range and specify major=0 you get a
> dynamically allocated and previously unused major, regardless of how
> many minors you asked for.
You're correct. And thinking about it, I indeed see no reason not to
allocate the full range. We save some memory that way, as each minor
range allocation is tracked by register_chrdev_region, and the code is
going to be simpler.
I'll respin the patch.
Thanks,
Jiri
^ permalink raw reply
* Re: [PATCH 1/2 v5] usbnet: allow status interrupt URB to always be active
From: Oliver Neukum @ 2013-04-11 9:53 UTC (permalink / raw)
To: Ming Lei
Cc: Dan Williams, Elina Pasheva, Network Development, linux-usb,
Rory Filer, Phil Sutter
In-Reply-To: <CACVXFVMxWML6nVNwPLv9RcnVgVNZzUqL8=nf9RaS-KS6Sjqaew@mail.gmail.com>
On Thursday 11 April 2013 16:09:16 Ming Lei wrote:
> On Thu, Apr 11, 2013 at 2:50 PM, Oliver Neukum <oliver@neukum.org> wrote:
> > On Thursday 11 April 2013 10:31:31 Ming Lei wrote:
> >
> >> 'mem_flags' isn't needed any more since we can apply allocation
> >> of GFP_NOIO automatically in resume path now, and you can always
> >> use GFP_KERNEL safely. Considered that it is a API, please don't
> >> introduce it.
> >
> > The automatic system goes a long way, but there are corner cases, for example
> > work queues, which still need mem_flags.
>
> Could you explain why work queue need GFP_NOIO?
Your fix for the memory allocation depends on it happening in the same
context. If you execute code on a work queue this happens in the context
of a kernel thread.
> and the use case for
> usbnet?
Processing your response from a work queue.
Regards
Oliver
^ permalink raw reply
* Re: [net-next PATCH 1/2] virtio-net: initialize vlan_features
From: Michael S. Tsirkin @ 2013-04-11 9:55 UTC (permalink / raw)
To: Jason Wang; +Cc: davem, netdev, linux-kernel, Rusty Russell
In-Reply-To: <1365672742-42258-2-git-send-email-jasowang@redhat.com>
On Thu, Apr 11, 2013 at 05:32:21PM +0800, Jason Wang wrote:
> There's nothing that prevent passing the device features of virtio_net to its
> vlan device. So this patch simply passes those to vlan device to benefit from
> advanced features.
>
> Netperf shows better sending performance for vlan device since TSO can work on
> vlan now.
>
> before:
> netperf -H 192.168.5.2
> MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.5.2 ()
> port 0 AF_INET : demo
> Recv Send Send
> Socket Socket Message Elapsed
> Size Size Size Time Throughput
> bytes bytes bytes secs. 10^6bits/sec
>
> 87380 16384 16384 10.00 4162.35
>
> after:
> netperf -H 192.168.5.2
> MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.5.2 ()
> port 0 AF_INET : demo
> Recv Send Send
> Socket Socket Message Elapsed
> Size Size Size Time Throughput
> bytes bytes bytes secs. 10^6bits/sec
>
> 87380 16384 16384 10.00 9365.42
>
> Cc: Rusty Russell <rusty@rustcorp.com.au>
> Cc: "Michael S. Tsirkin" <mst@redhat.com>
> Signed-off-by: Jason Wang <jasowang@redhat.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
> ---
> drivers/net/virtio_net.c | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index f7d67e8..8fdfde6 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -1511,6 +1511,8 @@ static int virtnet_probe(struct virtio_device *vdev)
> /* (!csum && gso) case will be fixed by register_netdev() */
> }
>
> + dev->vlan_features = dev->features;
> +
> /* Configuration may specify what MAC to use. Otherwise random. */
> if (virtio_config_val_len(vdev, VIRTIO_NET_F_MAC,
> offsetof(struct virtio_net_config, mac),
> --
> 1.7.1
^ permalink raw reply
* Re: [net-next PATCH 2/2] tuntap: initialize vlan_features
From: Michael S. Tsirkin @ 2013-04-11 9:55 UTC (permalink / raw)
To: Jason Wang; +Cc: davem, netdev, linux-kernel
In-Reply-To: <1365672742-42258-3-git-send-email-jasowang@redhat.com>
On Thu, Apr 11, 2013 at 05:32:22PM +0800, Jason Wang wrote:
> The vlan_features was zero which prevents vlan GSO packets to be transmitted to
> userspace. This is suboptimal so enable this by initialize vlan_features for
> tuntap.
>
> Netperf shows better performance of guest receiving since vlan TSO works for
> tuntap:
>
> before:
> netperf -H 192.168.5.4
> MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.5.4 ()
> port 0 AF_INET : demo
> Recv Send Send
> Socket Socket Message Elapsed
> Size Size Size Time Throughput
> bytes bytes bytes secs. 10^6bits/sec
>
> 87380 16384 16384 10.01 2786.67
>
> after:
> netperf -H 192.168.5.4
> MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.5.4 ()
> port 0 AF_INET : demo
> Recv Send Send
> Socket Socket Message Elapsed
> Size Size Size Time Throughput
> bytes bytes bytes secs. 10^6bits/sec
>
> 87380 16384 16384 10.00 8085.49
>
> Signed-off-by: Jason Wang <jasowang@redhat.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
> ---
> drivers/net/tun.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> index 29538e6..316c759 100644
> --- a/drivers/net/tun.c
> +++ b/drivers/net/tun.c
> @@ -1656,6 +1656,7 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr)
> dev->hw_features = NETIF_F_SG | NETIF_F_FRAGLIST |
> TUN_USER_FEATURES;
> dev->features = dev->hw_features;
> + dev->vlan_features = dev->features;
>
> INIT_LIST_HEAD(&tun->disabled);
> err = tun_attach(tun, file);
> --
> 1.7.1
^ permalink raw reply
* Re: [PATCH 1/2 v5] usbnet: allow status interrupt URB to always be active
From: Oliver Neukum @ 2013-04-11 9:59 UTC (permalink / raw)
To: Ming Lei
Cc: Bjørn Mork, Dan Williams, Elina Pasheva, Network Development,
linux-usb, Rory Filer, Phil Sutter
In-Reply-To: <CACVXFVMW2Dosr0FAKCvxgUFQKmwbduiC+HqmzS1tsvAHu=G8Kg@mail.gmail.com>
On Thursday 11 April 2013 16:37:53 Ming Lei wrote:
> On Thu, Apr 11, 2013 at 4:06 PM, Bjørn Mork <bjorn@mork.no> wrote:
> > Oliver Neukum <oliver@neukum.org> writes:
> >
> > My immediate thought was that someone also might want to use this new
> > API from atomic context, e.g. calling it directly from an URB callback.
>
> I am wondering it is a valid use case, and if there is one URB submitted,
> the interrupt URB for status has been submitted already, hasn't it?
That is the point of this patch. There are multiple reasons to keep
the status urb submitted. The generic layer has to count them and
react to the count.
> > But that is of course not possible taking a mutex. Could the lock
> > preventing interrupt_count maybe be a spinlock instead? Or am I on the
> > completely wrong track here?
>
> Also it is a bit odd that the 'start' API is allowed in atomic context, but
> the 'stop' API isn't allowed, and it is very easy to cause unbalanced counter.
It simply is easier to submit an URB in an atomic context than to kill it.
The code allowing doing it under a spinlock would be complex.
> > In any case, I don't see the point unnecessarily limiting the API by
> > dropping the memflags. What possible problem would that solve?
>
> If you think 'start' API should be called in atomic context, the memflags
It may be called. It doesn't have to be. usbnet needs a certain amount
of genericness in the API. Passing a flag does that and is simple.
Regards
Oliver
^ permalink raw reply
* Re: [PATCH 1/2 v5] usbnet: allow status interrupt URB to always be active
From: Ming Lei @ 2013-04-11 10:03 UTC (permalink / raw)
To: Oliver Neukum
Cc: Dan Williams, Elina Pasheva, Network Development, linux-usb,
Rory Filer, Phil Sutter
In-Reply-To: <3010836.mDNO71IiS7@linux-5eaq.site>
On Thu, Apr 11, 2013 at 5:53 PM, Oliver Neukum <oliver@neukum.org> wrote:
> On Thursday 11 April 2013 16:09:16 Ming Lei wrote:
>>
>> Could you explain why work queue need GFP_NOIO?
>
> Your fix for the memory allocation depends on it happening in the same
> context. If you execute code on a work queue this happens in the context
> of a kernel thread.
I understand the interface might be called from workqueue, and my question
is why GFP_NOIO is needed in the work queue context. Generally speaking,
GFP_KERNEL is enough for work queue context.
As we discussed before, GFP_NOIO is required in runtime resume context
and reset context, and the two contexts have been addressed automatically.
So looks you didn't answer my question, :-)
I mean if GFP_NOIO isn't needed, we can use GFP_KERNEL directly, and
the extra parameter isn't need.
Thanks,
--
Ming Lei
^ permalink raw reply
* Re: [PATCH 1/2 v5] usbnet: allow status interrupt URB to always be active
From: Bjørn Mork @ 2013-04-11 10:04 UTC (permalink / raw)
To: Ming Lei
Cc: Oliver Neukum, Dan Williams, Elina Pasheva, Network Development,
linux-usb, Rory Filer, Phil Sutter
In-Reply-To: <CACVXFVMW2Dosr0FAKCvxgUFQKmwbduiC+HqmzS1tsvAHu=G8Kg@mail.gmail.com>
Ming Lei <tom.leiming@gmail.com> writes:
> On Thu, Apr 11, 2013 at 4:06 PM, Bjørn Mork <bjorn@mork.no> wrote:
>> Oliver Neukum <oliver@neukum.org> writes:
>>
>> My immediate thought was that someone also might want to use this new
>> API from atomic context, e.g. calling it directly from an URB callback.
>
> I am wondering it is a valid use case, and if there is one URB submitted,
> the interrupt URB for status has been submitted already, hasn't it?
It might not be valid.
>> But that is of course not possible taking a mutex. Could the lock
>> preventing interrupt_count maybe be a spinlock instead? Or am I on the
>> completely wrong track here?
>
> Also it is a bit odd that the 'start' API is allowed in atomic context, but
> the 'stop' API isn't allowed, and it is very easy to cause unbalanced counter.
Yes, that's a valid point. Just a random thought popping out :)
For the record: I believe the v5 patch as posted really is fine without
any changes.
>> In any case, I don't see the point unnecessarily limiting the API by
>> dropping the memflags. What possible problem would that solve?
>
> If you think 'start' API should be called in atomic context, the memflags
> should be always 'GFP_ATOMIC'. I let Oliver explain why GFP_NOIO
> is needed in other cases.
Again: What problem are you attempting to solve by removing the
mem_flags from the API?
I think you are turning this the wrong way around. Please explain why
there are no use cases where different flags are needed. You seem to be
only concerned about the resume case. This API is not limited to
resuming. We pass mem_flags around all the time. It's the common thing
to do in any API where allocations may be required.
Bjørn
^ permalink raw reply
* Re: [PATCH 1/2 v5] usbnet: allow status interrupt URB to always be active
From: Ming Lei @ 2013-04-11 10:09 UTC (permalink / raw)
To: Bjørn Mork
Cc: Oliver Neukum, Dan Williams, Elina Pasheva, Network Development,
linux-usb, Rory Filer, Phil Sutter
In-Reply-To: <87ppy1wfhq.fsf@nemi.mork.no>
On Thu, Apr 11, 2013 at 6:04 PM, Bjørn Mork <bjorn@mork.no> wrote:
> Ming Lei <tom.leiming@gmail.com> writes:
>
> I think you are turning this the wrong way around. Please explain why
> there are no use cases where different flags are needed. You seem to be
> only concerned about the resume case. This API is not limited to
> resuming. We pass mem_flags around all the time. It's the common thing
> to do in any API where allocations may be required.
No always, we can find many many APIs which doesn't have the memflags
parameter but may allocate memory.
My point is very simple: if GFP_KERNEL is enough, why bother to pass one
memflag parameter?
Thanks,
--
Ming Lei
^ permalink raw reply
* [PATCH v2] vxlan: Allow setting destination to unicast address.
From: Atzm Watanabe @ 2013-04-11 10:16 UTC (permalink / raw)
To: netdev; +Cc: David S. Miller, Stephen Hemminger, Cong Wang
This patch allows setting VXLAN destination to unicast address.
It allows that VXLAN can be used as peer-to-peer tunnel without
multicast.
v2: use a new attribute REMOTE instead of GROUP based by
Cong Wang's comments.
Signed-off-by: Atzm Watanabe <atzm@stratosphere.co.jp>
---
drivers/net/vxlan.c | 45 ++++++++++++++++++++++++++++++++++----------
include/uapi/linux/if_link.h | 1 +
2 files changed, 36 insertions(+), 10 deletions(-)
diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index 9a64715..ae589a3 100644
--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@ -106,7 +106,7 @@ struct vxlan_dev {
struct hlist_node hlist;
struct net_device *dev;
__u32 vni; /* virtual network id */
- __be32 gaddr; /* multicast group */
+ __be32 daddr; /* destination address */
__be32 saddr; /* source address */
unsigned int link; /* link to multicast over */
__u16 port_min; /* source port range */
@@ -591,7 +591,7 @@ static bool vxlan_group_used(struct vxlan_net *vn,
if (!netif_running(vxlan->dev))
continue;
- if (vxlan->gaddr == this->gaddr)
+ if (vxlan->daddr == this->daddr)
return true;
}
@@ -605,7 +605,7 @@ static int vxlan_join_group(struct net_device *dev)
struct vxlan_net *vn = net_generic(dev_net(dev), vxlan_net_id);
struct sock *sk = vn->sock->sk;
struct ip_mreqn mreq = {
- .imr_multiaddr.s_addr = vxlan->gaddr,
+ .imr_multiaddr.s_addr = vxlan->daddr,
.imr_ifindex = vxlan->link,
};
int err;
@@ -633,7 +633,7 @@ static int vxlan_leave_group(struct net_device *dev)
int err = 0;
struct sock *sk = vn->sock->sk;
struct ip_mreqn mreq = {
- .imr_multiaddr.s_addr = vxlan->gaddr,
+ .imr_multiaddr.s_addr = vxlan->daddr,
.imr_ifindex = vxlan->link,
};
@@ -1106,7 +1106,7 @@ static netdev_tx_t vxlan_xmit(struct sk_buff *skb, struct net_device *dev)
did_rsc = false;
group.remote_port = vxlan_port;
group.remote_vni = vxlan->vni;
- group.remote_ip = vxlan->gaddr;
+ group.remote_ip = vxlan->daddr;
group.remote_ifindex = vxlan->link;
group.remote_next = 0;
rdst0 = &group;
@@ -1189,7 +1189,7 @@ static int vxlan_open(struct net_device *dev)
struct vxlan_dev *vxlan = netdev_priv(dev);
int err;
- if (vxlan->gaddr) {
+ if (IN_MULTICAST(ntohl(vxlan->daddr))) {
err = vxlan_join_group(dev);
if (err)
return err;
@@ -1223,7 +1223,7 @@ static int vxlan_stop(struct net_device *dev)
{
struct vxlan_dev *vxlan = netdev_priv(dev);
- if (vxlan->gaddr)
+ if (IN_MULTICAST(ntohl(vxlan->daddr)))
vxlan_leave_group(dev);
del_timer_sync(&vxlan->age_timer);
@@ -1312,6 +1312,7 @@ static const struct nla_policy vxlan_policy[IFLA_VXLAN_MAX + 1] = {
[IFLA_VXLAN_GROUP] = { .len = FIELD_SIZEOF(struct iphdr, daddr) },
[IFLA_VXLAN_LINK] = { .type = NLA_U32 },
[IFLA_VXLAN_LOCAL] = { .len = FIELD_SIZEOF(struct iphdr, saddr) },
+ [IFLA_VXLAN_REMOTE] = { .len = FIELD_SIZEOF(struct iphdr, daddr) },
[IFLA_VXLAN_TOS] = { .type = NLA_U8 },
[IFLA_VXLAN_TTL] = { .type = NLA_U8 },
[IFLA_VXLAN_LEARNING] = { .type = NLA_U8 },
@@ -1347,6 +1348,9 @@ static int vxlan_validate(struct nlattr *tb[], struct nlattr *data[])
return -ERANGE;
}
+ if (data[IFLA_VXLAN_GROUP] && data[IFLA_VXLAN_REMOTE])
+ return -EINVAL;
+
if (data[IFLA_VXLAN_GROUP]) {
__be32 gaddr = nla_get_be32(data[IFLA_VXLAN_GROUP]);
if (!IN_MULTICAST(ntohl(gaddr))) {
@@ -1355,6 +1359,14 @@ static int vxlan_validate(struct nlattr *tb[], struct nlattr *data[])
}
}
+ if (data[IFLA_VXLAN_REMOTE]) {
+ __be32 daddr = nla_get_be32(data[IFLA_VXLAN_REMOTE]);
+ if (IN_MULTICAST(ntohl(daddr))) {
+ pr_debug("remote address is not IPv4 unicast\n");
+ return -EADDRNOTAVAIL;
+ }
+ }
+
if (data[IFLA_VXLAN_PORT_RANGE]) {
const struct ifla_vxlan_port_range *p
= nla_data(data[IFLA_VXLAN_PORT_RANGE]);
@@ -1399,7 +1411,10 @@ static int vxlan_newlink(struct net *net, struct net_device *dev,
vxlan->vni = vni;
if (data[IFLA_VXLAN_GROUP])
- vxlan->gaddr = nla_get_be32(data[IFLA_VXLAN_GROUP]);
+ vxlan->daddr = nla_get_be32(data[IFLA_VXLAN_GROUP]);
+
+ if (data[IFLA_VXLAN_REMOTE])
+ vxlan->daddr = nla_get_be32(data[IFLA_VXLAN_REMOTE]);
if (data[IFLA_VXLAN_LOCAL])
vxlan->saddr = nla_get_be32(data[IFLA_VXLAN_LOCAL]);
@@ -1483,6 +1498,7 @@ static size_t vxlan_get_size(const struct net_device *dev)
nla_total_size(sizeof(__be32)) +/* IFLA_VXLAN_GROUP */
nla_total_size(sizeof(__u32)) + /* IFLA_VXLAN_LINK */
nla_total_size(sizeof(__be32))+ /* IFLA_VXLAN_LOCAL */
+ nla_total_size(sizeof(__be32))+ /* IFLA_VXLAN_REMOTE */
nla_total_size(sizeof(__u8)) + /* IFLA_VXLAN_TTL */
nla_total_size(sizeof(__u8)) + /* IFLA_VXLAN_TOS */
nla_total_size(sizeof(__u8)) + /* IFLA_VXLAN_LEARNING */
@@ -1507,8 +1523,17 @@ static int vxlan_fill_info(struct sk_buff *skb, const struct net_device *dev)
if (nla_put_u32(skb, IFLA_VXLAN_ID, vxlan->vni))
goto nla_put_failure;
- if (vxlan->gaddr && nla_put_be32(skb, IFLA_VXLAN_GROUP, vxlan->gaddr))
- goto nla_put_failure;
+ if (vxlan->daddr) {
+ int err;
+
+ if (IN_MULTICAST(ntohl(vxlan->daddr)))
+ err = nla_put_be32(skb, IFLA_VXLAN_GROUP, vxlan->daddr);
+ else
+ err = nla_put_be32(skb, IFLA_VXLAN_REMOTE, vxlan->daddr);
+
+ if (err)
+ goto nla_put_failure;
+ }
if (vxlan->link && nla_put_u32(skb, IFLA_VXLAN_LINK, vxlan->link))
goto nla_put_failure;
diff --git a/include/uapi/linux/if_link.h b/include/uapi/linux/if_link.h
index 6b35c42..3b9dab9b 100644
--- a/include/uapi/linux/if_link.h
+++ b/include/uapi/linux/if_link.h
@@ -299,6 +299,7 @@ enum {
IFLA_VXLAN_GROUP,
IFLA_VXLAN_LINK,
IFLA_VXLAN_LOCAL,
+ IFLA_VXLAN_REMOTE,
IFLA_VXLAN_TTL,
IFLA_VXLAN_TOS,
IFLA_VXLAN_LEARNING,
--
1.8.1.5
^ permalink raw reply related
* [PATCH iproute2 v2] vxlan: Allow setting destination to unicast address.
From: Atzm Watanabe @ 2013-04-11 10:17 UTC (permalink / raw)
To: netdev; +Cc: Stephen Hemminger
This patch allows setting VXLAN destination to unicast address.
It allows that VXLAN can be used as peer-to-peer tunnel without
multicast.
v2: use a new argument "remote" instead of "group" based by
Stephen Hemminger's comments.
Signed-off-by: Atzm Watanabe <atzm@stratosphere.co.jp>
---
include/linux/if_link.h | 1 +
ip/iplink_vxlan.c | 25 +++++++++++++++++++++++--
2 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/include/linux/if_link.h b/include/linux/if_link.h
index 40167af..0bf03dc 100644
--- a/include/linux/if_link.h
+++ b/include/linux/if_link.h
@@ -296,6 +296,7 @@ enum {
IFLA_VXLAN_GROUP,
IFLA_VXLAN_LINK,
IFLA_VXLAN_LOCAL,
+ IFLA_VXLAN_REMOTE,
IFLA_VXLAN_TTL,
IFLA_VXLAN_TOS,
IFLA_VXLAN_LEARNING,
diff --git a/ip/iplink_vxlan.c b/ip/iplink_vxlan.c
index 1025326..ce2c30c 100644
--- a/ip/iplink_vxlan.c
+++ b/ip/iplink_vxlan.c
@@ -23,7 +23,8 @@
static void explain(void)
{
- fprintf(stderr, "Usage: ... vxlan id VNI [ group ADDR ] [ local ADDR ]\n");
+ fprintf(stderr, "Usage: ... vxlan id VNI [ group ADDR ] [ remote ADDR ]\n");
+ fprintf(stderr, " [ local ADDR ]\n");
fprintf(stderr, " [ ttl TTL ] [ tos TOS ] [ dev PHYS_DEV ]\n");
fprintf(stderr, " [ port MIN MAX ] [ [no]learning ]\n");
fprintf(stderr, " [ [no]proxy ] [ [no]rsc ]\n");
@@ -41,6 +42,7 @@ static int vxlan_parse_opt(struct link_util *lu, int argc, char **argv,
__u32 vni = 0;
int vni_set = 0;
__u32 saddr = 0;
+ __u32 daddr = 0;
__u32 gaddr = 0;
unsigned link = 0;
__u8 tos = 0;
@@ -68,7 +70,13 @@ static int vxlan_parse_opt(struct link_util *lu, int argc, char **argv,
gaddr = get_addr32(*argv);
if (!IN_MULTICAST(ntohl(gaddr)))
- invarg("invald group address", *argv);
+ invarg("invalid group address", *argv);
+ } else if (!matches(*argv, "remote")) {
+ NEXT_ARG();
+ daddr = get_addr32(*argv);
+
+ if (IN_MULTICAST(ntohl(daddr)))
+ invarg("invalid remote address", *argv);
} else if (!matches(*argv, "local")) {
NEXT_ARG();
if (strcmp(*argv, "any"))
@@ -160,9 +168,15 @@ static int vxlan_parse_opt(struct link_util *lu, int argc, char **argv,
fprintf(stderr, "vxlan: missing virtual network identifier\n");
return -1;
}
+ if (gaddr && daddr) {
+ fprintf(stderr, "vxlan: both group and remote cannot be specified\n");
+ return -1;
+ }
addattr32(n, 1024, IFLA_VXLAN_ID, vni);
if (gaddr)
addattr_l(n, 1024, IFLA_VXLAN_GROUP, &gaddr, 4);
+ else if (daddr)
+ addattr_l(n, 1024, IFLA_VXLAN_REMOTE, &daddr, 4);
if (saddr)
addattr_l(n, 1024, IFLA_VXLAN_LOCAL, &saddr, 4);
if (link)
@@ -213,6 +227,13 @@ static void vxlan_print_opt(struct link_util *lu, FILE *f, struct rtattr *tb[])
format_host(AF_INET, 4, &addr, s1, sizeof(s1)));
}
+ if (tb[IFLA_VXLAN_REMOTE]) {
+ __be32 addr = rta_getattr_u32(tb[IFLA_VXLAN_REMOTE]);
+ if (addr)
+ fprintf(f, "remote %s ",
+ format_host(AF_INET, 4, &addr, s1, sizeof(s1)));
+ }
+
if (tb[IFLA_VXLAN_LOCAL]) {
__be32 addr = rta_getattr_u32(tb[IFLA_VXLAN_LOCAL]);
if (addr)
--
1.8.1.5
^ permalink raw reply related
* Re: [PATCH 1/2 v5] usbnet: allow status interrupt URB to always be active
From: Ming Lei @ 2013-04-11 10:19 UTC (permalink / raw)
To: Bjørn Mork
Cc: Oliver Neukum, Dan Williams, Elina Pasheva, Network Development,
linux-usb, Rory Filer, Phil Sutter
In-Reply-To: <87ppy1wfhq.fsf@nemi.mork.no>
On Thu, Apr 11, 2013 at 6:04 PM, Bjørn Mork <bjorn@mork.no> wrote:
> Ming Lei <tom.leiming@gmail.com> writes:
>
> Again: What problem are you attempting to solve by removing the
> mem_flags from the API?
It is not about removing anything, we are discussing one new API
(include the parameters) to be introduced.
Thanks,
--
Ming Lei
^ permalink raw reply
* Re: [PATCH 1/2 v5] usbnet: allow status interrupt URB to always be active
From: Bjørn Mork @ 2013-04-11 10:26 UTC (permalink / raw)
To: Ming Lei
Cc: Oliver Neukum, Dan Williams, Elina Pasheva, Network Development,
linux-usb, Rory Filer, Phil Sutter
In-Reply-To: <CACVXFVNn9MQr6JLdin=u642Jb-2ZPfVk8YaBmNdhU0_2e7WJqQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Ming Lei <tom.leiming-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
> On Thu, Apr 11, 2013 at 6:04 PM, Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org> wrote:
>> Ming Lei <tom.leiming-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
>>
>> Again: What problem are you attempting to solve by removing the
>> mem_flags from the API?
>
> It is not about removing anything, we are discussing one new API
> (include the parameters) to be introduced.
Yes. Sure. And the original proposal was to add a new API with a
mem_flags parameter. You proposed to add the same API, but without the
mem_flags parameter. You did not explain why. I still assumed that you
have some reason to propose it. I assumed that reason must be some
problem which would be introduced by having the mem_flags parameter, and
which would be solved if we instead drop it.
It seems that you are either unable or unwilling to explain your
reasons, so I'll just go ahead and drop my assumptions. You never had
any reason and there never would be any problem.
Thanks.
Bjørn
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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: [PATCH 1/2 v5] usbnet: allow status interrupt URB to always be active
From: Ming Lei @ 2013-04-11 10:30 UTC (permalink / raw)
To: Bjørn Mork
Cc: Oliver Neukum, Dan Williams, Elina Pasheva, Network Development,
linux-usb, Rory Filer, Phil Sutter
In-Reply-To: <87hajdwefp.fsf@nemi.mork.no>
On Thu, Apr 11, 2013 at 6:26 PM, Bjørn Mork <bjorn@mork.no> wrote:
> Ming Lei <tom.leiming@gmail.com> writes:
>
>> On Thu, Apr 11, 2013 at 6:04 PM, Bjørn Mork <bjorn@mork.no> wrote:
>>> Ming Lei <tom.leiming@gmail.com> writes:
>>>
>>> Again: What problem are you attempting to solve by removing the
>>> mem_flags from the API?
>>
>> It is not about removing anything, we are discussing one new API
>> (include the parameters) to be introduced.
>
> Yes. Sure. And the original proposal was to add a new API with a
> mem_flags parameter. You proposed to add the same API, but without the
> mem_flags parameter. You did not explain why. I still assumed that you
> have some reason to propose it. I assumed that reason must be some
> problem which would be introduced by having the mem_flags parameter, and
> which would be solved if we instead drop it.
>
> It seems that you are either unable or unwilling to explain your
> reasons, so I'll just go ahead and drop my assumptions. You never had
> any reason and there never would be any problem.
OK, I say it again, GFP_KERNEL is enough to cover all cases, and the
mem_flags parameter is redundant.
Thanks,
--
Ming Lei
^ permalink raw reply
* Re: [PATCH 1/3] if.h: add IFF_BRIDGE_RESTRICTED flag
From: Antonio Quartulli @ 2013-04-11 10:56 UTC (permalink / raw)
To: Stephen Hemminger
Cc: netdev@vger.kernel.org, bridge@lists.linux-foundation.org,
Jamal Hadi Salim, David S. Miller
In-Reply-To: <20130410134609.46bcaeae@nehalam.linuxnetplumber.net>
[-- Attachment #1: Type: text/plain, Size: 1534 bytes --]
On Wed, Apr 10, 2013 at 01:46:09PM -0700, Stephen Hemminger wrote:
> On Wed, 10 Apr 2013 18:54:34 +0200
> Antonio Quartulli <antonio@open-mesh.com> wrote:
>
> > Hi Jamal, all,
> >
> > On Tue, Apr 09, 2013 at 08:49:17 -0700, Jamal Hadi Salim wrote:
> > > On 13-04-09 09:51 AM, Antonio Quartulli wrote:
> > >
> > > >
> > > > Does this work at the bridge level? A packet entering a port and going out from
> > > > another one can be affected by tc/mark?
> > >
> > > Yes of course. And on any construct that looks like a netdev (tunnels etc).
> > >
> >
> > Thanks for your hints. After having struggled a bit I found out how to do it
> > using ebtables and the mark target :)
> >
> > Thanks a Lot!
> >
> Come back again, though. The ebtables method offers more flexibility which can
> be a good or bad thing...
I just realised that :)
By installing ebtables (meaning modules + userspace tool) my iperf test result
drops from 81Mbps to 66Mbps: former without, latter with ebtables module enabled.
I did this test between two devices connected with Fast Ethernet.
I thought that most of the code is in netfilter, so shared with iptables, hence
I expected a reasonable overhead why this is much worse.
Does anybody have a clue about this? I should probably start a new thread on the
netfilter mailing list.
However this problem makes ebtables unusable at all.
Suggestions are welcome :)
Cheers,
--
Antonio Quartulli
..each of us alone is worth nothing..
Ernesto "Che" Guevara
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 1/3] if.h: add IFF_BRIDGE_RESTRICTED flag
From: Jamal Hadi Salim @ 2013-04-11 11:03 UTC (permalink / raw)
To: Antonio Quartulli
Cc: Stephen Hemminger, netdev@vger.kernel.org,
bridge@lists.linux-foundation.org, David S. Miller
In-Reply-To: <20130411105628.GA4717@open-mesh.com>
On 13-04-11 06:56 AM, Antonio Quartulli wrote:
> I just realised that :)
>
> By installing ebtables (meaning modules + userspace tool) my iperf test result
> drops from 81Mbps to 66Mbps: former without, latter with ebtables module enabled.
> I did this test between two devices connected with Fast Ethernet.
>
Please try tc like i said earlier ;->
cheers,
jamal
> I thought that most of the code is in netfilter, so shared with iptables, hence
> I expected a reasonable overhead why this is much worse.
>
> Does anybody have a clue about this? I should probably start a new thread on the
> netfilter mailing list.
>
> However this problem makes ebtables unusable at all.
>
> Suggestions are welcome :)
>
> Cheers,
>
^ permalink raw reply
* Re: [PATCH 1/2 v5] usbnet: allow status interrupt URB to always be active
From: Bjørn Mork @ 2013-04-11 11:08 UTC (permalink / raw)
To: Ming Lei
Cc: Oliver Neukum, Dan Williams, Elina Pasheva, Network Development,
linux-usb, Rory Filer, Phil Sutter
In-Reply-To: <CACVXFVO+QZ+mtdOFuNuh+8HQOMcuQrKJRAaW9ohyrMCMeZXsjQ@mail.gmail.com>
Ming Lei <tom.leiming@gmail.com> writes:
> OK, I say it again, GFP_KERNEL is enough to cover all cases, and the
> mem_flags parameter is redundant.
The docs for usb_submit_urb() in drivers/usb/core/urb.c lists some
possible mem_flags use cases. Among these are (where (b) and (c) are
cases needing GFP_ATOMIC and not applicable here):
<quote>
* (3) If you use a kernel thread with a network driver you must use
* GFP_NOIO, unless (b) or (c) apply;
</quote>
Is this example
a) wrong, or
b) not applicable, or
c) to be excluded from the new API?
Bjørn
^ 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