* Re: nat bypass
From: ratheesh k @ 2010-06-30 9:24 UTC (permalink / raw)
To: Simon Horman; +Cc: Netfilter mailing list, netdev
In-Reply-To: <20100630023718.GU2138@verge.net.au>
> Let me try and understand this.
>
> R is routing between 192.168.1.0/24 and 10.232.18.0/24.
> As A is on the 192.168.1.0/24 side of R.
> But to give A an 10.232.18.0/24 address (dynamically)?
>
> Why?
>
For some clients , R should act as a mere bridge , Not a router .
On Wed, Jun 30, 2010 at 8:07 AM, Simon Horman <horms@verge.net.au> wrote:
> On Mon, Jun 28, 2010 at 03:43:46PM +0530, ratheesh k wrote:
>> Hi,
>>
>> A -------> R ------->S
>>
>> I have a linux machine A is connected to Linux machine R . Machine R
>> is having two network interfaces and acting as a router .
>> It has a dhcp server running . It will assign ip in 192.168.1.0/24
>> subnet to all machine connected on lan side ( A is connected also in
>> lan side ) . Wan side of R is connected to HTTP server S . There is
>> also a DHCP server running on S to assign ip in 10.232.18.0/24 subnet
>> . Is there any way , in which NAT should be bypassed to get ip from
>> DHCP server running on S . My question is : How can A will get an ip
>> from 10.232.18.0/24 pool ip .?
>> ebtables is an option ? How can we make it ?
>> Is there any other optimal way ?
>
> Let me try and understand this.
>
> R is routing between 192.168.1.0/24 and 10.232.18.0/24.
> As A is on the 192.168.1.0/24 side of R.
> But to give A an 10.232.18.0/24 address (dynamically)?
>
> Why?
>
>
^ permalink raw reply
* [ANNOUNCE] 7th Netfilter Workshop in Seville, Spain
From: Pablo Neira Ayuso @ 2010-06-30 10:06 UTC (permalink / raw)
To: netfilter-announce
Cc: Netfilter Development Mailinglist, Mail List - Netfilter, lwn,
Linux Netdev List
Hi!
We're happy to announce the next Netfilter Workshop in the series. This
year it will take place in Seville, Spain. We will provide you up to
date information through our website:
http://workshop.netfilter.org/2010/
On behalf of the Netfilter coreteam,
Pablo!
^ permalink raw reply
* Re: [PATCH] xfrm: fix XFRMA_MARK extraction in xfrm_mark_get
From: jamal @ 2010-06-30 10:07 UTC (permalink / raw)
To: Andreas Steffen; +Cc: netdev, David Miller, Simon Horman
In-Reply-To: <4C2AF8EE.8030508@strongswan.org>
On Wed, 2010-06-30 at 09:57 +0200, Andreas Steffen wrote:
> Determine the size of the xfrm_mark struct, not of its pointer.
>
> Signed-off-by: Andreas Steffen <andreas.steffen@strongswan.org>
Good catch (you are right this was tested on 64 bit ;->).
The preferred style would be what Simon mentioned. No biggie if
you keep it this way - but if you resubmit, add:
Acked-by: Jamal Hadi Salim <hadi@cyberus.ca>
cheers,
jamal
^ permalink raw reply
* Re: [PATCH] act_mirred: combine duplicate code
From: jamal @ 2010-06-30 10:24 UTC (permalink / raw)
To: Changli Gao; +Cc: David S. Miller, netdev
In-Reply-To: <1277888098-27632-1-git-send-email-xiaosuo@gmail.com>
removed lkml
On Wed, 2010-06-30 at 16:54 +0800, Changli Gao wrote:
> act_mirred: combine duplicate code
>
> tcf_bstats is updated in any way, so we can do it earlier to reduce the size of
> the code.
There is one condition when !(dev->flags & IFF_UP) where we dont update
the stats in current code. This changes with your patch.
It would make sense to actually update at that point (as you do) and
additionally increment some other counter to track that like
m->tcf_qstats.drops. I suggest resubmit with that change and add my
signed-off.
cheers,
jamal
^ permalink raw reply
* Re: [PATCH] act_nat: use stack variable
From: jamal @ 2010-06-30 10:25 UTC (permalink / raw)
To: Changli Gao; +Cc: Herbert Xu, David S. Miller, netdev
In-Reply-To: <1277888829-30230-1-git-send-email-xiaosuo@gmail.com>
On Wed, 2010-06-30 at 17:07 +0800, Changli Gao wrote:
> act_nat: use stack variable
>
> structure tc_nat isn't too big for stack, so we can put it in stack.
>
> Signed-off-by: Changli Gao <xiaosuo@gmail.com>
Doesnt look unreasonable - will let Herbert make the call..
cheers,
jamal
^ permalink raw reply
* Re: [PATCH] act_nat: use stack variable
From: Herbert Xu @ 2010-06-30 10:30 UTC (permalink / raw)
To: jamal; +Cc: Changli Gao, David S. Miller, netdev
In-Reply-To: <1277893521.3509.17.camel@bigi>
On Wed, Jun 30, 2010 at 06:25:21AM -0400, jamal wrote:
> On Wed, 2010-06-30 at 17:07 +0800, Changli Gao wrote:
> > act_nat: use stack variable
> >
> > structure tc_nat isn't too big for stack, so we can put it in stack.
> >
> > Signed-off-by: Changli Gao <xiaosuo@gmail.com>
>
> Doesnt look unreasonable - will let Herbert make the call..
Looks good to me too.
Thanks!
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] igbvf: avoid name clash between PF and VF
From: Ben Hutchings @ 2010-06-30 10:44 UTC (permalink / raw)
To: Stefan Assmann
Cc: netdev, e1000-devel, Duyck, Alexander H, gregory.v.rose,
jeffrey.t.kirsher, Andy Gospodarek
In-Reply-To: <4C2B0614.9040004@redhat.com>
On Wed, 2010-06-30 at 10:53 +0200, Stefan Assmann wrote:
> From: Stefan Assmann <sassmann@redhat.com>
>
> It looks like the VFs get initialized before all the PFs are. Therefore
> the udev mapping MAC <-> ethX (for PFs) gets screwed because the VFs
> may grab the ethX interface names (reserved by udev) for the PFs.
>
> Example:
> igb max_vfs=0
> eth0 Link encap:Ethernet HWaddr 00:13:20:F7:A5:9E
> eth1 Link encap:Ethernet HWaddr 00:13:20:F7:A5:9F
> eth2 Link encap:Ethernet HWaddr 00:13:20:F7:A5:A0
> eth3 Link encap:Ethernet HWaddr 00:13:20:F7:A5:A1
> igb max_vfs=1
> eth0 Link encap:Ethernet HWaddr 00:13:20:F7:A5:9E
> eth1 Link encap:Ethernet HWaddr 0A:CF:41:69:F7:A9
> eth2 Link encap:Ethernet HWaddr 3A:FE:20:4C:2A:3B
> eth3 Link encap:Ethernet HWaddr C6:C3:B1:56:C9:A4
> eth3_rename Link encap:Ethernet HWaddr 00:13:20:F7:A5:9F
> eth4 Link encap:Ethernet HWaddr 6E:8A:8A:A3:5F:69
> eth4_rename Link encap:Ethernet HWaddr 00:13:20:F7:A5:A0
> eth5_rename Link encap:Ethernet HWaddr 00:13:20:F7:A5:A1
>
> In the example above VF 0A:CF:41:69:F7:A9 grabs eth1 but udev
> has a rule that says eth1 should be assigned PF 00:13:20:F7:A5:9F
> (eth3_rename) and waits for the VF to disappear to rename eth3_rename
> to eth1. Unfortunately eth1 is not going to disappear.
> This is not a udev bug since udev doesn't create persistent rules for
> VFs as their MAC address changes every reboot.
[...]
I think it is a bug in the udev rules: udev should rename the VFs even
though their names won't be persistent.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH] act_mirred: combine duplicate code
From: jamal @ 2010-06-30 10:49 UTC (permalink / raw)
To: Changli Gao; +Cc: David S. Miller, netdev
In-Reply-To: <1277893442.3509.16.camel@bigi>
On Wed, 2010-06-30 at 06:24 -0400, jamal wrote:
> m->tcf_qstats.drops.
Sorry - this nagged me - we are already incrementing overlimits - we
should increment drops. Scratch that too. I am going to say your patch
as is:
signed-off-by: Jamal Hadi Salim <hadi@cyberus.ca>
cheers,
jamal
^ permalink raw reply
* Re: [PATCH] igbvf: avoid name clash between PF and VF
From: Stefan Assmann @ 2010-06-30 10:57 UTC (permalink / raw)
To: Ben Hutchings
Cc: e1000-devel, netdev, kay.sievers, gregory.v.rose,
jeffrey.t.kirsher, Andy Gospodarek, harald
In-Reply-To: <1277894679.28819.60.camel@localhost>
On 30.06.2010 12:44, Ben Hutchings wrote:
> On Wed, 2010-06-30 at 10:53 +0200, Stefan Assmann wrote:
>> From: Stefan Assmann <sassmann@redhat.com>
>>
>> It looks like the VFs get initialized before all the PFs are. Therefore
>> the udev mapping MAC <-> ethX (for PFs) gets screwed because the VFs
>> may grab the ethX interface names (reserved by udev) for the PFs.
>>
>> Example:
>> igb max_vfs=0
>> eth0 Link encap:Ethernet HWaddr 00:13:20:F7:A5:9E
>> eth1 Link encap:Ethernet HWaddr 00:13:20:F7:A5:9F
>> eth2 Link encap:Ethernet HWaddr 00:13:20:F7:A5:A0
>> eth3 Link encap:Ethernet HWaddr 00:13:20:F7:A5:A1
>> igb max_vfs=1
>> eth0 Link encap:Ethernet HWaddr 00:13:20:F7:A5:9E
>> eth1 Link encap:Ethernet HWaddr 0A:CF:41:69:F7:A9
>> eth2 Link encap:Ethernet HWaddr 3A:FE:20:4C:2A:3B
>> eth3 Link encap:Ethernet HWaddr C6:C3:B1:56:C9:A4
>> eth3_rename Link encap:Ethernet HWaddr 00:13:20:F7:A5:9F
>> eth4 Link encap:Ethernet HWaddr 6E:8A:8A:A3:5F:69
>> eth4_rename Link encap:Ethernet HWaddr 00:13:20:F7:A5:A0
>> eth5_rename Link encap:Ethernet HWaddr 00:13:20:F7:A5:A1
>>
>> In the example above VF 0A:CF:41:69:F7:A9 grabs eth1 but udev
>> has a rule that says eth1 should be assigned PF 00:13:20:F7:A5:9F
>> (eth3_rename) and waits for the VF to disappear to rename eth3_rename
>> to eth1. Unfortunately eth1 is not going to disappear.
>> This is not a udev bug since udev doesn't create persistent rules for
>> VFs as their MAC address changes every reboot.
> [...]
>
> I think it is a bug in the udev rules: udev should rename the VFs even
> though their names won't be persistent.
In that case let's Cc udev people.
Stefan
--
Stefan Assmann | Red Hat GmbH
Software Engineer | Otto-Hahn-Strasse 20, 85609 Dornach
| HR: Amtsgericht Muenchen HRB 153243
| GF: Brendan Lane, Charlie Peters,
sassmann at redhat.com | Michael Cunningham, Charles Cachera
------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* Re: [PATCH] igbvf: avoid name clash between PF and VF
From: Kay Sievers @ 2010-06-30 11:11 UTC (permalink / raw)
To: Stefan Assmann
Cc: Ben Hutchings, netdev, e1000-devel, Duyck, Alexander H,
gregory.v.rose, jeffrey.t.kirsher, Andy Gospodarek, harald
In-Reply-To: <4C2B22FD.4050705@redhat.com>
On Wed, Jun 30, 2010 at 12:57, Stefan Assmann <sassmann@redhat.com> wrote:
> On 30.06.2010 12:44, Ben Hutchings wrote:
>> On Wed, 2010-06-30 at 10:53 +0200, Stefan Assmann wrote:
>>> From: Stefan Assmann <sassmann@redhat.com>
>>>
>>> It looks like the VFs get initialized before all the PFs are. Therefore
>>> the udev mapping MAC <-> ethX (for PFs) gets screwed because the VFs
>>> may grab the ethX interface names (reserved by udev) for the PFs.
>>>
>>> Example:
>>> igb max_vfs=0
>>> eth0 Link encap:Ethernet HWaddr 00:13:20:F7:A5:9E
>>> eth1 Link encap:Ethernet HWaddr 00:13:20:F7:A5:9F
>>> eth2 Link encap:Ethernet HWaddr 00:13:20:F7:A5:A0
>>> eth3 Link encap:Ethernet HWaddr 00:13:20:F7:A5:A1
>>> igb max_vfs=1
>>> eth0 Link encap:Ethernet HWaddr 00:13:20:F7:A5:9E
>>> eth1 Link encap:Ethernet HWaddr 0A:CF:41:69:F7:A9
>>> eth2 Link encap:Ethernet HWaddr 3A:FE:20:4C:2A:3B
>>> eth3 Link encap:Ethernet HWaddr C6:C3:B1:56:C9:A4
>>> eth3_rename Link encap:Ethernet HWaddr 00:13:20:F7:A5:9F
>>> eth4 Link encap:Ethernet HWaddr 6E:8A:8A:A3:5F:69
>>> eth4_rename Link encap:Ethernet HWaddr 00:13:20:F7:A5:A0
>>> eth5_rename Link encap:Ethernet HWaddr 00:13:20:F7:A5:A1
>>>
>>> In the example above VF 0A:CF:41:69:F7:A9 grabs eth1 but udev
>>> has a rule that says eth1 should be assigned PF 00:13:20:F7:A5:9F
>>> (eth3_rename) and waits for the VF to disappear to rename eth3_rename
>>> to eth1. Unfortunately eth1 is not going to disappear.
>>> This is not a udev bug since udev doesn't create persistent rules for
>>> VFs as their MAC address changes every reboot.
>> [...]
>>
>> I think it is a bug in the udev rules: udev should rename the VFs even
>> though their names won't be persistent.
Udev writes out these configs to a rules file, and therefore can never
handle random MAC addresses, as they would just accumulate in the
rules file with a new entry at every bootup.
Stuff like this is just not supported at the moment with the rather
simple logic it has, and there is no current plan/idea, or anybody
working on changing/improving this at the moment.
Kay
^ permalink raw reply
* Re: [RFC] [PATCH] ethtool: Change ethtool_op_set_flags to validate flags
From: Stanislaw Gruszka @ 2010-06-30 11:21 UTC (permalink / raw)
To: Ben Hutchings
Cc: Amit Salecha, netdev@vger.kernel.org, Amerigo Wang,
Anirban Chakraborty
In-Reply-To: <1277827261.2112.48.camel@achroite.uk.solarflarecom.com>
On Tue, 29 Jun 2010 17:01:01 +0100
Ben Hutchings <bhutchings@solarflare.com> wrote:
> This is the sort of change I'd like to see.
>
> Ben.
>
> ---
> ethtool_op_set_flags() does not check for unsupported flags, and has
> no way of doing so. This means it is not suitable for use as a
> default implementation of ethtool_ops::set_flags.
>
> Add a 'supported' parameter specifying the flags that the driver and
> hardware support, validate the requested flags against this, and
> change all current callers to pass this parameter.
>
> Change some other trivial implementations of ethtool_ops::set_flags to
> call ethtool_op_set_flags().
> ---
> drivers/net/cxgb4/cxgb4_main.c | 9 +--------
> drivers/net/enic/enic_main.c | 1 -
> drivers/net/ixgbe/ixgbe_ethtool.c | 5 ++++-
> drivers/net/mv643xx_eth.c | 7 ++++++-
> drivers/net/myri10ge/myri10ge.c | 10 +++++++---
> drivers/net/niu.c | 9 +--------
> drivers/net/sfc/ethtool.c | 5 +----
> drivers/net/sky2.c | 16 ++++++----------
> include/linux/ethtool.h | 2 +-
> net/core/ethtool.c | 28 +++++-----------------------
> 10 files changed, 32 insertions(+), 60 deletions(-)
Looks good for me as well.
Reviewed-by: Stanislaw Gruszka <sgruszka@redhat.com>
^ permalink raw reply
* Re: [PATCH -next] myri10ge: clear NETIF_F_LRO bit directly
From: Stanislaw Gruszka @ 2010-06-30 11:26 UTC (permalink / raw)
To: Andrew Gallatin; +Cc: netdev, Amerigo Wang, Brice Goglin
In-Reply-To: <4C2A14CE.3090502@myri.com>
On Tue, 29 Jun 2010 11:44:14 -0400
Andrew Gallatin <gallatin@myri.com> wrote:
> Stanislaw Gruszka wrote:
> > Do not use ethtool_op_set_flags() to clear one bit in ->features.
> > Inform user about disabling LRO.
>
> Thanks.. That simplifies things nicely. But was
> direct manipulation of netdev->features ever discouraged,
> or has my use of ethtool_op_{get,set}_flags() to manipulate
> the features always been complete overkill?
It was a bit overkill. Manipulate netdev->features is fine,
many drivers do it.
> > Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
>
> Acked-by: Andrew J. Gallatin <gallatin@myri.com>
Thanks. FYI: Ben Hutchings posted other patch spread over
all drivers: http://patchwork.ozlabs.org/patch/57286/
we most likely will use it to put this myri10ge bits in.
Stanislaw
^ permalink raw reply
* Re: nat bypass
From: Stephen Clark @ 2010-06-30 12:05 UTC (permalink / raw)
To: ratheesh k; +Cc: Simon Horman, Netfilter mailing list, netdev
In-Reply-To: <AANLkTilxqHHiDfzQbewBe8cnTtvdB9CCTPn9EVCcAf5Q@mail.gmail.com>
On 06/30/2010 05:24 AM, ratheesh k wrote:
>> Let me try and understand this.
>>
>> R is routing between 192.168.1.0/24 and 10.232.18.0/24.
>> As A is on the 192.168.1.0/24 side of R.
>> But to give A an 10.232.18.0/24 address (dynamically)?
>>
>> Why?
>>
>
> For some clients , R should act as a mere bridge , Not a router .
>
>
> On Wed, Jun 30, 2010 at 8:07 AM, Simon Horman<horms@verge.net.au> wrote:
>> On Mon, Jun 28, 2010 at 03:43:46PM +0530, ratheesh k wrote:
>>> Hi,
>>>
>>> A -------> R ------->S
>>>
>>> I have a linux machine A is connected to Linux machine R . Machine R
>>> is having two network interfaces and acting as a router .
>>> It has a dhcp server running . It will assign ip in 192.168.1.0/24
>>> subnet to all machine connected on lan side ( A is connected also in
>>> lan side ) . Wan side of R is connected to HTTP server S . There is
>>> also a DHCP server running on S to assign ip in 10.232.18.0/24 subnet
>>> . Is there any way , in which NAT should be bypassed to get ip from
>>> DHCP server running on S . My question is : How can A will get an ip
>>> from 10.232.18.0/24 pool ip .?
>>> ebtables is an option ? How can we make it ?
>>> Is there any other optimal way ?
>>
>> Let me try and understand this.
>>
>> R is routing between 192.168.1.0/24 and 10.232.18.0/24.
>> As A is on the 192.168.1.0/24 side of R.
>> But to give A an 10.232.18.0/24 address (dynamically)?
>>
>> Why?
>>
>>
> --
> 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
>
Will dhcprelay work for you?
--
"They that give up essential liberty to obtain temporary safety,
deserve neither liberty nor safety." (Ben Franklin)
"The course of history shows that as a government grows, liberty
decreases." (Thomas Jefferson)
^ permalink raw reply
* Re: [PATCH net-next-2.6] netfilter: remove deprecated config option NF_CT_ACCT
From: Patrick McHardy @ 2010-06-30 12:10 UTC (permalink / raw)
To: Jiri Pirko; +Cc: netdev, davem, ole
In-Reply-To: <20100629154507.GA5260@psychotron.brq.redhat.com>
Jiri Pirko wrote:
> This patch removes deprecated config option NF_CT_ACCT. The default value is set
> to 0 and warning message is put into connbytes_mt_init (connbytes selected
> NF_CT_ACCT to enable it by default).
Thanks, I already have a patch queued in nf-next for this.
^ permalink raw reply
* [PATCH net-next-2.6 1/3] ethtool: Change ethtool_op_set_flags to validate flags
From: Ben Hutchings @ 2010-06-30 12:44 UTC (permalink / raw)
To: David Miller
Cc: netdev, linux-net-drivers, Stanislaw Gruszka, Amit Salecha,
Amerigo Wang, Anirban Chakraborty, Dimitris Michailidis,
Scott Feldman, Vasanthy Kolluri, Roopa Prabhu, e1000-devel,
Lennert Buytenhek, Andrew Gallatin, Brice Goglin,
Stephen Hemminger, Jeff Garzik
ethtool_op_set_flags() does not check for unsupported flags, and has
no way of doing so. This means it is not suitable for use as a
default implementation of ethtool_ops::set_flags.
Add a 'supported' parameter specifying the flags that the driver and
hardware support, validate the requested flags against this, and
change all current callers to pass this parameter.
Change some other trivial implementations of ethtool_ops::set_flags to
call ethtool_op_set_flags().
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Reviewed-by: Stanislaw Gruszka <sgruszka@redhat.com>
Acked-by: Jeff Garzik <jgarzik@redhat.com>
---
drivers/net/cxgb4/cxgb4_main.c | 9 +--------
drivers/net/enic/enic_main.c | 1 -
drivers/net/ixgbe/ixgbe_ethtool.c | 5 ++++-
drivers/net/mv643xx_eth.c | 7 ++++++-
drivers/net/myri10ge/myri10ge.c | 10 +++++++---
drivers/net/niu.c | 9 +--------
drivers/net/sfc/ethtool.c | 5 +----
drivers/net/sky2.c | 16 ++++++----------
include/linux/ethtool.h | 2 +-
net/core/ethtool.c | 28 +++++-----------------------
10 files changed, 32 insertions(+), 60 deletions(-)
diff --git a/drivers/net/cxgb4/cxgb4_main.c b/drivers/net/cxgb4/cxgb4_main.c
index 6528167..55a720e 100644
--- a/drivers/net/cxgb4/cxgb4_main.c
+++ b/drivers/net/cxgb4/cxgb4_main.c
@@ -1799,14 +1799,7 @@ static int set_tso(struct net_device *dev, u32 value)
static int set_flags(struct net_device *dev, u32 flags)
{
- if (flags & ~ETH_FLAG_RXHASH)
- return -EOPNOTSUPP;
-
- if (flags & ETH_FLAG_RXHASH)
- dev->features |= NETIF_F_RXHASH;
- else
- dev->features &= ~NETIF_F_RXHASH;
- return 0;
+ return ethtool_op_set_flags(dev, flags, ETH_FLAG_RXHASH);
}
static struct ethtool_ops cxgb_ethtool_ops = {
diff --git a/drivers/net/enic/enic_main.c b/drivers/net/enic/enic_main.c
index 6c6795b..77a7f87 100644
--- a/drivers/net/enic/enic_main.c
+++ b/drivers/net/enic/enic_main.c
@@ -365,7 +365,6 @@ static const struct ethtool_ops enic_ethtool_ops = {
.get_coalesce = enic_get_coalesce,
.set_coalesce = enic_set_coalesce,
.get_flags = ethtool_op_get_flags,
- .set_flags = ethtool_op_set_flags,
};
static void enic_free_wq_buf(struct vnic_wq *wq, struct vnic_wq_buf *buf)
diff --git a/drivers/net/ixgbe/ixgbe_ethtool.c b/drivers/net/ixgbe/ixgbe_ethtool.c
index 873b45e..7d2e5ea 100644
--- a/drivers/net/ixgbe/ixgbe_ethtool.c
+++ b/drivers/net/ixgbe/ixgbe_ethtool.c
@@ -2205,8 +2205,11 @@ static int ixgbe_set_flags(struct net_device *netdev, u32 data)
{
struct ixgbe_adapter *adapter = netdev_priv(netdev);
bool need_reset = false;
+ int rc;
- ethtool_op_set_flags(netdev, data);
+ rc = ethtool_op_set_flags(netdev, data, ETH_FLAG_LRO | ETH_FLAG_NTUPLE);
+ if (rc)
+ return rc;
/* if state changes we need to update adapter->flags and reset */
if (adapter->flags2 & IXGBE_FLAG2_RSC_CAPABLE) {
diff --git a/drivers/net/mv643xx_eth.c b/drivers/net/mv643xx_eth.c
index e345ec8..82b720f 100644
--- a/drivers/net/mv643xx_eth.c
+++ b/drivers/net/mv643xx_eth.c
@@ -1636,6 +1636,11 @@ static void mv643xx_eth_get_ethtool_stats(struct net_device *dev,
}
}
+static int mv643xx_eth_set_flags(struct net_device *dev, u32 data)
+{
+ return ethtool_op_set_flags(dev, data, ETH_FLAG_LRO);
+}
+
static int mv643xx_eth_get_sset_count(struct net_device *dev, int sset)
{
if (sset == ETH_SS_STATS)
@@ -1661,7 +1666,7 @@ static const struct ethtool_ops mv643xx_eth_ethtool_ops = {
.get_strings = mv643xx_eth_get_strings,
.get_ethtool_stats = mv643xx_eth_get_ethtool_stats,
.get_flags = ethtool_op_get_flags,
- .set_flags = ethtool_op_set_flags,
+ .set_flags = mv643xx_eth_set_flags,
.get_sset_count = mv643xx_eth_get_sset_count,
};
diff --git a/drivers/net/myri10ge/myri10ge.c b/drivers/net/myri10ge/myri10ge.c
index e0b47cc..d771d16 100644
--- a/drivers/net/myri10ge/myri10ge.c
+++ b/drivers/net/myri10ge/myri10ge.c
@@ -1730,8 +1730,7 @@ static int myri10ge_set_rx_csum(struct net_device *netdev, u32 csum_enabled)
if (csum_enabled)
mgp->csum_flag = MXGEFW_FLAGS_CKSUM;
else {
- u32 flags = ethtool_op_get_flags(netdev);
- err = ethtool_op_set_flags(netdev, (flags & ~ETH_FLAG_LRO));
+ netdev->features &= ~NETIF_F_LRO;
mgp->csum_flag = 0;
}
@@ -1900,6 +1899,11 @@ static u32 myri10ge_get_msglevel(struct net_device *netdev)
return mgp->msg_enable;
}
+static int myri10ge_set_flags(struct net_device *netdev, u32 value)
+{
+ return ethtool_op_set_flags(netdev, value, ETH_FLAG_LRO);
+}
+
static const struct ethtool_ops myri10ge_ethtool_ops = {
.get_settings = myri10ge_get_settings,
.get_drvinfo = myri10ge_get_drvinfo,
@@ -1920,7 +1924,7 @@ static const struct ethtool_ops myri10ge_ethtool_ops = {
.set_msglevel = myri10ge_set_msglevel,
.get_msglevel = myri10ge_get_msglevel,
.get_flags = ethtool_op_get_flags,
- .set_flags = ethtool_op_set_flags
+ .set_flags = myri10ge_set_flags
};
static int myri10ge_allocate_rings(struct myri10ge_slice_state *ss)
diff --git a/drivers/net/niu.c b/drivers/net/niu.c
index 63e8e38..3d523cb 100644
--- a/drivers/net/niu.c
+++ b/drivers/net/niu.c
@@ -7920,14 +7920,7 @@ static int niu_phys_id(struct net_device *dev, u32 data)
static int niu_set_flags(struct net_device *dev, u32 data)
{
- if (data & (ETH_FLAG_LRO | ETH_FLAG_NTUPLE))
- return -EOPNOTSUPP;
-
- if (data & ETH_FLAG_RXHASH)
- dev->features |= NETIF_F_RXHASH;
- else
- dev->features &= ~NETIF_F_RXHASH;
- return 0;
+ return ethtool_op_set_flags(dev, data, ETH_FLAG_RXHASH);
}
static const struct ethtool_ops niu_ethtool_ops = {
diff --git a/drivers/net/sfc/ethtool.c b/drivers/net/sfc/ethtool.c
index 7693cfb..23372bf 100644
--- a/drivers/net/sfc/ethtool.c
+++ b/drivers/net/sfc/ethtool.c
@@ -551,10 +551,7 @@ static int efx_ethtool_set_flags(struct net_device *net_dev, u32 data)
struct efx_nic *efx = netdev_priv(net_dev);
u32 supported = efx->type->offload_features & ETH_FLAG_RXHASH;
- if (data & ~supported)
- return -EOPNOTSUPP;
-
- return ethtool_op_set_flags(net_dev, data);
+ return ethtool_op_set_flags(net_dev, data, supported);
}
static void efx_ethtool_self_test(struct net_device *net_dev,
diff --git a/drivers/net/sky2.c b/drivers/net/sky2.c
index 7985165..c762c6a 100644
--- a/drivers/net/sky2.c
+++ b/drivers/net/sky2.c
@@ -4188,17 +4188,13 @@ static int sky2_set_eeprom(struct net_device *dev, struct ethtool_eeprom *eeprom
static int sky2_set_flags(struct net_device *dev, u32 data)
{
struct sky2_port *sky2 = netdev_priv(dev);
+ u32 supported =
+ (sky2->hw->flags & SKY2_HW_RSS_BROKEN) ? 0 : ETH_FLAG_RXHASH;
+ int rc;
- if (data & ~ETH_FLAG_RXHASH)
- return -EOPNOTSUPP;
-
- if (data & ETH_FLAG_RXHASH) {
- if (sky2->hw->flags & SKY2_HW_RSS_BROKEN)
- return -EINVAL;
-
- dev->features |= NETIF_F_RXHASH;
- } else
- dev->features &= ~NETIF_F_RXHASH;
+ rc = ethtool_op_set_flags(dev, data, supported);
+ if (rc)
+ return rc;
rx_set_rss(dev);
diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
index 2c8af09..084ddb3 100644
--- a/include/linux/ethtool.h
+++ b/include/linux/ethtool.h
@@ -457,7 +457,7 @@ int ethtool_op_set_tso(struct net_device *dev, u32 data);
u32 ethtool_op_get_ufo(struct net_device *dev);
int ethtool_op_set_ufo(struct net_device *dev, u32 data);
u32 ethtool_op_get_flags(struct net_device *dev);
-int ethtool_op_set_flags(struct net_device *dev, u32 data);
+int ethtool_op_set_flags(struct net_device *dev, u32 data, u32 supported);
void ethtool_ntuple_flush(struct net_device *dev);
/**
diff --git a/net/core/ethtool.c b/net/core/ethtool.c
index a0f4964..5d42fae 100644
--- a/net/core/ethtool.c
+++ b/net/core/ethtool.c
@@ -144,31 +144,13 @@ u32 ethtool_op_get_flags(struct net_device *dev)
}
EXPORT_SYMBOL(ethtool_op_get_flags);
-int ethtool_op_set_flags(struct net_device *dev, u32 data)
+int ethtool_op_set_flags(struct net_device *dev, u32 data, u32 supported)
{
- const struct ethtool_ops *ops = dev->ethtool_ops;
- unsigned long features = dev->features;
-
- if (data & ETH_FLAG_LRO)
- features |= NETIF_F_LRO;
- else
- features &= ~NETIF_F_LRO;
-
- if (data & ETH_FLAG_NTUPLE) {
- if (!ops->set_rx_ntuple)
- return -EOPNOTSUPP;
- features |= NETIF_F_NTUPLE;
- } else {
- /* safe to clear regardless */
- features &= ~NETIF_F_NTUPLE;
- }
-
- if (data & ETH_FLAG_RXHASH)
- features |= NETIF_F_RXHASH;
- else
- features &= ~NETIF_F_RXHASH;
+ if (data & ~supported)
+ return -EINVAL;
- dev->features = features;
+ dev->features = ((dev->features & ~flags_dup_features) |
+ (data & flags_dup_features));
return 0;
}
EXPORT_SYMBOL(ethtool_op_set_flags);
--
1.6.2.5
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply related
* [PATCH net-next-2.6 2/3] netdev: Make ethtool_ops::set_flags() return -EINVAL for unsupported flags
From: Ben Hutchings @ 2010-06-30 12:46 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <1277901872.2082.10.camel@achroite.uk.solarflarecom.com>
The documented error code for attempts to set unsupported flags (or
to clear flags that cannot be disabled) is EINVAL, not EOPNOTSUPP.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
---
drivers/net/bnx2x_main.c | 2 +-
drivers/net/netxen/netxen_nic_ethtool.c | 2 +-
drivers/net/qlcnic/qlcnic_ethtool.c | 2 +-
drivers/net/s2io.c | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/bnx2x_main.c b/drivers/net/bnx2x_main.c
index 0809f6c..29e293f 100644
--- a/drivers/net/bnx2x_main.c
+++ b/drivers/net/bnx2x_main.c
@@ -10983,7 +10983,7 @@ static int bnx2x_set_flags(struct net_device *dev, u32 data)
int rc = 0;
if (data & ~(ETH_FLAG_LRO | ETH_FLAG_RXHASH))
- return -EOPNOTSUPP;
+ return -EINVAL;
if (bp->recovery_state != BNX2X_RECOVERY_DONE) {
printk(KERN_ERR "Handling parity error recovery. Try again later\n");
diff --git a/drivers/net/netxen/netxen_nic_ethtool.c b/drivers/net/netxen/netxen_nic_ethtool.c
index 6d94ee5..b30de24 100644
--- a/drivers/net/netxen/netxen_nic_ethtool.c
+++ b/drivers/net/netxen/netxen_nic_ethtool.c
@@ -888,7 +888,7 @@ static int netxen_nic_set_flags(struct net_device *netdev, u32 data)
int hw_lro;
if (data & ~ETH_FLAG_LRO)
- return -EOPNOTSUPP;
+ return -EINVAL;
if (!(adapter->capabilities & NX_FW_CAPABILITY_HW_LRO))
return -EINVAL;
diff --git a/drivers/net/qlcnic/qlcnic_ethtool.c b/drivers/net/qlcnic/qlcnic_ethtool.c
index b9d5acb..f8e39e4 100644
--- a/drivers/net/qlcnic/qlcnic_ethtool.c
+++ b/drivers/net/qlcnic/qlcnic_ethtool.c
@@ -984,7 +984,7 @@ static int qlcnic_set_flags(struct net_device *netdev, u32 data)
int hw_lro;
if (data & ~ETH_FLAG_LRO)
- return -EOPNOTSUPP;
+ return -EINVAL;
if (!(adapter->capabilities & QLCNIC_FW_CAPABILITY_HW_LRO))
return -EINVAL;
diff --git a/drivers/net/s2io.c b/drivers/net/s2io.c
index a032d72..22371f1 100644
--- a/drivers/net/s2io.c
+++ b/drivers/net/s2io.c
@@ -6692,7 +6692,7 @@ static int s2io_ethtool_set_flags(struct net_device *dev, u32 data)
int changed = 0;
if (data & ~ETH_FLAG_LRO)
- return -EOPNOTSUPP;
+ return -EINVAL;
if (data & ETH_FLAG_LRO) {
if (lro_enable) {
--
1.6.2.5
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply related
* [PATCH net-next-2.6 3/3] vmxnet3: Remove incorrect implementation of ethtool_ops::get_flags()
From: Ben Hutchings @ 2010-06-30 12:47 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Shreyas Bhatewara, VMware, Inc.
In-Reply-To: <1277901872.2082.10.camel@achroite.uk.solarflarecom.com>
Only some netdev feature flags correspond directly to ethtool feature
flags. ethtool_op_get_flags() does the right thing.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
---
drivers/net/vmxnet3/vmxnet3_ethtool.c | 8 +-------
1 files changed, 1 insertions(+), 7 deletions(-)
diff --git a/drivers/net/vmxnet3/vmxnet3_ethtool.c b/drivers/net/vmxnet3/vmxnet3_ethtool.c
index 8a71a21..de1ba14 100644
--- a/drivers/net/vmxnet3/vmxnet3_ethtool.c
+++ b/drivers/net/vmxnet3/vmxnet3_ethtool.c
@@ -275,12 +275,6 @@ vmxnet3_get_strings(struct net_device *netdev, u32 stringset, u8 *buf)
}
}
-static u32
-vmxnet3_get_flags(struct net_device *netdev)
-{
- return netdev->features;
-}
-
static int
vmxnet3_set_flags(struct net_device *netdev, u32 data)
{
@@ -559,7 +553,7 @@ static struct ethtool_ops vmxnet3_ethtool_ops = {
.get_tso = ethtool_op_get_tso,
.set_tso = ethtool_op_set_tso,
.get_strings = vmxnet3_get_strings,
- .get_flags = vmxnet3_get_flags,
+ .get_flags = ethtool_op_get_flags,
.set_flags = vmxnet3_set_flags,
.get_sset_count = vmxnet3_get_sset_count,
.get_ethtool_stats = vmxnet3_get_ethtool_stats,
--
1.6.2.5
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply related
* Re: [PATCH net-next-2.6] netfilter: remove deprecated config option NF_CT_ACCT
From: Jiri Pirko @ 2010-06-30 12:49 UTC (permalink / raw)
To: Patrick McHardy; +Cc: netdev, davem, ole
In-Reply-To: <4C2B3437.6000602@trash.net>
Wed, Jun 30, 2010 at 02:10:31PM CEST, kaber@trash.net wrote:
>Jiri Pirko wrote:
>>This patch removes deprecated config option NF_CT_ACCT. The default value is set
>>to 0 and warning message is put into connbytes_mt_init (connbytes selected
>>NF_CT_ACCT to enable it by default).
>
>Thanks, I already have a patch queued in nf-next for this.
>
Oh, I see that: d70a011dbbaa6335a19deb63ec3eb613f48faafd
Apart your patch doesn't remove option from defconfigs (not sure if that's
necessary or not), your patch also do not print warning in connbytes_mt_init.
That would make connbytes silently non-functional. Therefore I think my patch is
better (more complete).
Jirka
^ permalink raw reply
* Re: [PATCH net-next-2.6] netfilter: remove deprecated config option NF_CT_ACCT
From: Patrick McHardy @ 2010-06-30 12:53 UTC (permalink / raw)
To: Jiri Pirko; +Cc: netdev, davem, ole
In-Reply-To: <20100630124954.GA2582@psychotron.brq.redhat.com>
Jiri Pirko wrote:
> Wed, Jun 30, 2010 at 02:10:31PM CEST, kaber@trash.net wrote:
>
>> Jiri Pirko wrote:
>>
>>> This patch removes deprecated config option NF_CT_ACCT. The default value is set
>>> to 0 and warning message is put into connbytes_mt_init (connbytes selected
>>> NF_CT_ACCT to enable it by default).
>>>
>> Thanks, I already have a patch queued in nf-next for this.
>>
>>
>
> Oh, I see that: d70a011dbbaa6335a19deb63ec3eb613f48faafd
>
a8756201ba4189bca3ee1a6ec4e290f467ee09ab also belongs to the removal.
>
> Apart your patch doesn't remove option from defconfigs (not sure if that's
> necessary or not), your patch also do not print warning in connbytes_mt_init.
> That would make connbytes silently non-functional. Therefore I think my patch is
> better (more complete).
The patch I have queued is automatically enabling accounting when
the connbytes match is used and is printing a warning.
^ permalink raw reply
* Re: [PATCH] igbvf: avoid name clash between PF and VF
From: Harald Hoyer @ 2010-06-30 13:07 UTC (permalink / raw)
To: Kay Sievers
Cc: e1000-devel, netdev, gregory.v.rose, jeffrey.t.kirsher,
Andy Gospodarek, Ben Hutchings, Stefan Assmann
In-Reply-To: <AANLkTin08wA8a5nCnq-djQnTSq1g2TQ7GqYfCEBCTn9l@mail.gmail.com>
On 06/30/2010 01:11 PM, Kay Sievers wrote:
> On Wed, Jun 30, 2010 at 12:57, Stefan Assmann<sassmann@redhat.com> wrote:
>> On 30.06.2010 12:44, Ben Hutchings wrote:
>>> On Wed, 2010-06-30 at 10:53 +0200, Stefan Assmann wrote:
>>>> From: Stefan Assmann<sassmann@redhat.com>
>>>>
>>>> It looks like the VFs get initialized before all the PFs are. Therefore
>>>> the udev mapping MAC<-> ethX (for PFs) gets screwed because the VFs
>>>> may grab the ethX interface names (reserved by udev) for the PFs.
>>>>
>>>> Example:
>>>> igb max_vfs=0
>>>> eth0 Link encap:Ethernet HWaddr 00:13:20:F7:A5:9E
>>>> eth1 Link encap:Ethernet HWaddr 00:13:20:F7:A5:9F
>>>> eth2 Link encap:Ethernet HWaddr 00:13:20:F7:A5:A0
>>>> eth3 Link encap:Ethernet HWaddr 00:13:20:F7:A5:A1
>>>> igb max_vfs=1
>>>> eth0 Link encap:Ethernet HWaddr 00:13:20:F7:A5:9E
>>>> eth1 Link encap:Ethernet HWaddr 0A:CF:41:69:F7:A9
>>>> eth2 Link encap:Ethernet HWaddr 3A:FE:20:4C:2A:3B
>>>> eth3 Link encap:Ethernet HWaddr C6:C3:B1:56:C9:A4
>>>> eth3_rename Link encap:Ethernet HWaddr 00:13:20:F7:A5:9F
>>>> eth4 Link encap:Ethernet HWaddr 6E:8A:8A:A3:5F:69
>>>> eth4_rename Link encap:Ethernet HWaddr 00:13:20:F7:A5:A0
>>>> eth5_rename Link encap:Ethernet HWaddr 00:13:20:F7:A5:A1
>>>>
>>>> In the example above VF 0A:CF:41:69:F7:A9 grabs eth1 but udev
>>>> has a rule that says eth1 should be assigned PF 00:13:20:F7:A5:9F
>>>> (eth3_rename) and waits for the VF to disappear to rename eth3_rename
>>>> to eth1. Unfortunately eth1 is not going to disappear.
>>>> This is not a udev bug since udev doesn't create persistent rules for
>>>> VFs as their MAC address changes every reboot.
>>> [...]
>>>
>>> I think it is a bug in the udev rules: udev should rename the VFs even
>>> though their names won't be persistent.
>
> Udev writes out these configs to a rules file, and therefore can never
> handle random MAC addresses, as they would just accumulate in the
> rules file with a new entry at every bootup.
>
> Stuff like this is just not supported at the moment with the rather
> simple logic it has, and there is no current plan/idea, or anybody
> working on changing/improving this at the moment.
>
> Kay
Solution: move away from the "eth*" namespace and use "net*" for configured
interfaces.
------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* Re: [PATCH net-next-2.6] netfilter: remove deprecated config option NF_CT_ACCT
From: Jiri Pirko @ 2010-06-30 13:11 UTC (permalink / raw)
To: Patrick McHardy; +Cc: netdev, davem, ole
In-Reply-To: <4C2B3E3D.7030804@trash.net>
Wed, Jun 30, 2010 at 02:53:17PM CEST, kaber@trash.net wrote:
>Jiri Pirko wrote:
>>Wed, Jun 30, 2010 at 02:10:31PM CEST, kaber@trash.net wrote:
>>>Jiri Pirko wrote:
>>>>This patch removes deprecated config option NF_CT_ACCT. The default value is set
>>>>to 0 and warning message is put into connbytes_mt_init (connbytes selected
>>>>NF_CT_ACCT to enable it by default).
>>>Thanks, I already have a patch queued in nf-next for this.
>>>
>>
>>Oh, I see that: d70a011dbbaa6335a19deb63ec3eb613f48faafd
>
>a8756201ba4189bca3ee1a6ec4e290f467ee09ab also belongs to the removal.
>
>>
>>Apart your patch doesn't remove option from defconfigs (not sure if that's
>>necessary or not), your patch also do not print warning in connbytes_mt_init.
>>That would make connbytes silently non-functional. Therefore I think my patch is
>>better (more complete).
>
>The patch I have queued is automatically enabling accounting when
>the connbytes match is used and is printing a warning.
ok, that looks fine to me. What about those config options in def_config files?
^ permalink raw reply
* Re: [PATCH net-next-2.6] netfilter: remove deprecated config option NF_CT_ACCT
From: Patrick McHardy @ 2010-06-30 13:42 UTC (permalink / raw)
To: Jiri Pirko; +Cc: netdev, davem, ole
In-Reply-To: <20100630131153.GB2582@psychotron.brq.redhat.com>
Jiri Pirko wrote:
> Wed, Jun 30, 2010 at 02:53:17PM CEST, kaber@trash.net wrote:
>
>> Jiri Pirko wrote:
>>
>>> Apart your patch doesn't remove option from defconfigs (not sure if that's
>>> necessary or not), your patch also do not print warning in connbytes_mt_init.
>>> That would make connbytes silently non-functional. Therefore I think my patch is
>>> better (more complete).
>>>
>> The patch I have queued is automatically enabling accounting when
>> the connbytes match is used and is printing a warning.
>>
>
> ok, that looks fine to me. What about those config options in def_config files?
>
I usually leave those for the architecture maintainers.
^ permalink raw reply
* Re: [PATCH net-next-2.6] netfilter: remove deprecated config option NF_CT_ACCT
From: Jiri Pirko @ 2010-06-30 14:15 UTC (permalink / raw)
To: Patrick McHardy; +Cc: netdev, davem, ole
In-Reply-To: <4C2B49B9.5050302@trash.net>
Wed, Jun 30, 2010 at 03:42:17PM CEST, kaber@trash.net wrote:
>Jiri Pirko wrote:
>>Wed, Jun 30, 2010 at 02:53:17PM CEST, kaber@trash.net wrote:
>>>Jiri Pirko wrote:
>>>>Apart your patch doesn't remove option from defconfigs (not sure if that's
>>>>necessary or not), your patch also do not print warning in connbytes_mt_init.
>>>>That would make connbytes silently non-functional. Therefore I think my patch is
>>>>better (more complete).
>>>The patch I have queued is automatically enabling accounting when
>>>the connbytes match is used and is printing a warning.
>>
>>ok, that looks fine to me. What about those config options in def_config files?
>
>I usually leave those for the architecture maintainers.
>
Ok, Thanks Patrick.
Dave, please drop this patch.
Thanks.
^ permalink raw reply
* Re: [PATCH net-next-2.6 2/3] netdev: Make ethtool_ops::set_flags() return -EINVAL for unsupported flags
From: Eilon Greenstein @ 2010-06-30 15:01 UTC (permalink / raw)
To: Ben Hutchings; +Cc: David Miller, netdev@vger.kernel.org
In-Reply-To: <1277902016.2082.12.camel@achroite.uk.solarflarecom.com>
On Wed, 2010-06-30 at 05:46 -0700, Ben Hutchings wrote:
> The documented error code for attempts to set unsupported flags (or
> to clear flags that cannot be disabled) is EINVAL, not EOPNOTSUPP.
>
> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
If that's what the document say...
Acked-by: Eilon Greenstein <eilong@broadcom.com>
Thanks Ben!
^ permalink raw reply
* [PATCH net-next-2.6 1/2] ethtool: Add support for control of RX flow hash indirection
From: Ben Hutchings @ 2010-06-30 15:05 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-net-drivers
Many NICs use an indirection table to map an RX flow hash value to one
of an arbitrary number of queues (not necessarily a power of 2). It
can be useful to remove some queues from this indirection table so
that they are only used for flows that are specifically filtered
there. It may also be useful to weight the mapping to account for
user processes with the same CPU-affinity as the RX interrupts.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
---
include/linux/ethtool.h | 15 +++++++++
net/core/ethtool.c | 80 +++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 95 insertions(+), 0 deletions(-)
diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
index 2c8af09..3b089d8 100644
--- a/include/linux/ethtool.h
+++ b/include/linux/ethtool.h
@@ -384,6 +384,15 @@ struct ethtool_rxnfc {
__u32 rule_locs[0];
};
+struct ethtool_rxfh_indir {
+ __u32 cmd;
+ /* On entry, this is the array size of the user buffer. On
+ * return from ETHTOOL_GRXFHINDIR, this is the array size of
+ * the hardware indirection table. */
+ __u32 size;
+ __u32 ring_index[0]; /* ring/queue index for each hash value */
+};
+
struct ethtool_rx_ntuple_flow_spec {
__u32 flow_type;
union {
@@ -576,6 +585,10 @@ struct ethtool_ops {
int (*set_rx_ntuple)(struct net_device *,
struct ethtool_rx_ntuple *);
int (*get_rx_ntuple)(struct net_device *, u32 stringset, void *);
+ int (*get_rxfh_indir)(struct net_device *,
+ struct ethtool_rxfh_indir *);
+ int (*set_rxfh_indir)(struct net_device *,
+ const struct ethtool_rxfh_indir *);
};
#endif /* __KERNEL__ */
@@ -637,6 +650,8 @@ struct ethtool_ops {
#define ETHTOOL_SRXNTUPLE 0x00000035 /* Add an n-tuple filter to device */
#define ETHTOOL_GRXNTUPLE 0x00000036 /* Get n-tuple filters from device */
#define ETHTOOL_GSSET_INFO 0x00000037 /* Get string set info */
+#define ETHTOOL_GRXFHINDIR 0x00000038 /* Get RX flow hash indir'n table */
+#define ETHTOOL_SRXFHINDIR 0x00000039 /* Set RX flow hash indir'n table */
/* compatibility with older code */
#define SPARC_ETH_GSET ETHTOOL_GSET
diff --git a/net/core/ethtool.c b/net/core/ethtool.c
index a0f4964..d978096 100644
--- a/net/core/ethtool.c
+++ b/net/core/ethtool.c
@@ -376,6 +376,80 @@ err_out:
return ret;
}
+static noinline_for_stack int ethtool_get_rxfh_indir(struct net_device *dev,
+ void __user *useraddr)
+{
+ struct ethtool_rxfh_indir *indir;
+ u32 table_size;
+ size_t full_size;
+ int ret;
+
+ if (!dev->ethtool_ops->get_rxfh_indir)
+ return -EOPNOTSUPP;
+
+ if (copy_from_user(&table_size,
+ useraddr + offsetof(struct ethtool_rxfh_indir, size),
+ sizeof(table_size)))
+ return -EFAULT;
+
+ if (table_size >
+ (KMALLOC_MAX_SIZE - sizeof(*indir)) / sizeof(*indir->ring_index))
+ return -ENOMEM;
+ full_size = sizeof(*indir) + sizeof(*indir->ring_index) * table_size;
+ indir = kmalloc(full_size, GFP_USER);
+ if (!indir)
+ return -ENOMEM;
+
+ indir->cmd = ETHTOOL_GRXFHINDIR;
+ indir->size = table_size;
+ ret = dev->ethtool_ops->get_rxfh_indir(dev, indir);
+ if (ret)
+ goto out;
+
+ if (copy_to_user(useraddr, indir, full_size))
+ ret = -EFAULT;
+
+out:
+ kfree(indir);
+ return ret;
+}
+
+static noinline_for_stack int ethtool_set_rxfh_indir(struct net_device *dev,
+ void __user *useraddr)
+{
+ struct ethtool_rxfh_indir *indir;
+ u32 table_size;
+ size_t full_size;
+ int ret;
+
+ if (!dev->ethtool_ops->set_rxfh_indir)
+ return -EOPNOTSUPP;
+
+ if (copy_from_user(&table_size,
+ useraddr + offsetof(struct ethtool_rxfh_indir, size),
+ sizeof(table_size)))
+ return -EFAULT;
+
+ if (table_size >
+ (KMALLOC_MAX_SIZE - sizeof(*indir)) / sizeof(*indir->ring_index))
+ return -ENOMEM;
+ full_size = sizeof(*indir) + sizeof(*indir->ring_index) * table_size;
+ indir = kmalloc(full_size, GFP_USER);
+ if (!indir)
+ return -ENOMEM;
+
+ if (copy_from_user(indir, useraddr, full_size)) {
+ ret = -EFAULT;
+ goto out;
+ }
+
+ ret = dev->ethtool_ops->set_rxfh_indir(dev, indir);
+
+out:
+ kfree(indir);
+ return ret;
+}
+
static void __rx_ntuple_filter_add(struct ethtool_rx_ntuple_list *list,
struct ethtool_rx_ntuple_flow_spec *spec,
struct ethtool_rx_ntuple_flow_spec_container *fsc)
@@ -1544,6 +1618,12 @@ int dev_ethtool(struct net *net, struct ifreq *ifr)
case ETHTOOL_GSSET_INFO:
rc = ethtool_get_sset_info(dev, useraddr);
break;
+ case ETHTOOL_GRXFHINDIR:
+ rc = ethtool_get_rxfh_indir(dev, useraddr);
+ break;
+ case ETHTOOL_SRXFHINDIR:
+ rc = ethtool_set_rxfh_indir(dev, useraddr);
+ break;
default:
rc = -EOPNOTSUPP;
}
--
1.6.2.5
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply related
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