* Re: [PATCHv2 net-next-2.6] 3c59x: Use fine-grained locks for MII and windowed register access
From: David Miller @ 2010-06-30 6:15 UTC (permalink / raw)
To: ben; +Cc: steffen.klassert, netdev, chase.douglas, nordmark
In-Reply-To: <1277861216.28819.36.camel@localhost>
From: Ben Hutchings <ben@decadent.org.uk>
Date: Wed, 30 Jun 2010 02:26:56 +0100
> This avoids scheduling in atomic context and also means that IRQs
> will only be deferred for relatively short periods of time.
>
> Previously discussed in:
> http://article.gmane.org/gmane.linux.network/155024
>
> Reported-by: Arne Nordmark <nordmark@mech.kth.se>
> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Applied.
^ permalink raw reply
* Re: RFC: Allow 'ip' to run in daemon mode?
From: Stephen Hemminger @ 2010-06-30 7:00 UTC (permalink / raw)
To: Ben Greear, NetDev; +Cc: Stephen Hemminger
write a new service rather than bloating the existing code or just use netlink or libnl
Ben Greear <greearb@candelatech.com> wrote:
>I'm considering modifying 'ip' to be able to run in daemon
>mode so that I can do lots of IP commands without having to
>pay the startup cost of iproute.
>
>The -batch option almost works, but it's hard to programatically
>figure out failure codes.
>
>I'm thinking about making these changes:
>
>1) Move all of the error printing code into common methods (basically,
> wrap printf). In daemon mode this text can be sent back to the
> calling process, and in normal mode, it will be printed to stdout/stderr
> as it is currently.
>
>2) Remove all or most calls to 'exit' and instead return error codes
> to the calling logic.
>
>3) Add ability to listen on a unix socket for commands, basically treat
> them just like batch commands, one command per packet.
>
>4) Return well formatted error code and text response to calling process
> over the unix socket, maybe something like:
>
>RV: [errno or equiv, zero for success]\n
>CMD: [ command string this relates to ]\n
>[ Optional free form text ]
>
>
>Does something like this have any chance of upstream inclusion?
>
>Thanks,
>Ben
>
>--
>Ben Greear <greearb@candelatech.com>
>Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: static inline int xfrm_mark_get() broken
From: Simon Horman @ 2010-06-30 7:01 UTC (permalink / raw)
To: Andreas Steffen
Cc: Steffen Andreas (asteffen@hsr.ch), netdev@vger.kernel.org, jamal
In-Reply-To: <4C2AD009.40306@hsr.ch>
On Wed, Jun 30, 2010 at 07:03:05AM +0200, Andreas Steffen wrote:
> Hello Simon,
>
> actually I don't care how this bug is going to be fixed, but with
> sizeof(struct xfrm_mark) I'm dead certain that both the mark
> value and mask are being copied. Actually in the next inline
> function right below sizeof(struct xfrm_mark) is used, too:
>
> static inline int xfrm_mark_put(struct sk_buff *skb, struct xfrm_mark *m)
> {
> if (m->m | m->v)
> NLA_PUT(skb, XFRMA_MARK, sizeof(struct xfrm_mark), m);
> return 0;
In that case I withdraw my suggestion.
^ permalink raw reply
* ip6 route output() and ip_route_output_key() by drivers
From: Parav Pandit @ 2010-06-30 7:24 UTC (permalink / raw)
To: netdev
Hi,
Our device driver uses ip6 route output() and typecast the return value of dst_entry to rt6_info (similar to (net/ip6/icmp.c)
Driver uses (a) rt6i_dst.addr, (b) rt6i_dst.plen and (c) rt6i_gateway to get the route entry (ip/mask, gw, netdev).
Can anyone please confirm that drivers and/or netfilter kernel modules are allowed to use them? netdev drivers like : cnic.c, cxgb3, nes are using the ipv4 API (but not IPv6 API).
Also ip_route_output_key() rtable and dst_entry doesn't seem to provide route entry's subnet mask/prefix value. how drivers/netfilter kernel module can get a ip/mask gateway value while given a destination IP address as input?
I really appreciate your inputs. I hope I am asking it on the relevant mailing list.
Regards,
Parav Pandit
^ permalink raw reply
* Re: [Bridge] Bridge blocking network traffic
From: ratheesh k @ 2010-06-30 7:50 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Netfilter mailing list, netdev, bridge
In-Reply-To: <20100422130919.70206765@nehalam>
>>On Fri, Apr 23, 2010 at 1:39 AM, Stephen Hemminger <shemminger@linux-foundation.org> wrote:
>>You are supposed to assign IP address to bridge not the member of the bridge
Why is it so ?
I have a linux machine with interfaces eth0 (192.168.1.100 ) and
eth1 ( 192.168.2.100 ) . . I can connect both eth0 an eth1 to a
hardware HUB . How could i do this in linux machine itself using
brctl ?
Thanks,
Ratheesh
> On Thu, 22 Apr 2010 10:48:09 +1000
> benno joy <bennojoy@gmail.com> wrote:
>
>> Dear Team,
>>
>> I have a strange problem...... This is my problem i have a linux box running
>> Xen kernel (2.2). and i have the a bonding interface called bond0.497(eth0
>> and eth1 and also des Vlan tagging).
>> the bond0.497 is part of the bridge "xenbrv497", the issue is as soon as i
>> make the bond a part of the bridge my network traffic stops to work.
>> I did some prelimanary tests and found the following:
>> 1) if i assighn an ip to the bond and do a ping to the gateway it works
>> (provided it is not part of bridge xenbrv497)
>> 2) if i add the bondig interface to the brodge xenbrv497 (brclt addif
>> xenbrv497 bond0.497) the ping tests fails.
>> 3) i did a tcpdump and found that arp requests are going out of the
>> interface and we are getting response also. but soemhow
>> the arp entries are not gettign registered. i did some googling and found it
>> may be because of filtering so i disabled it by
>> echo 0 > in /proc/sys/net/bridge/bridge-nf-*.
>> But even this did not help still the arp entries are not getting registered
>> due to which my network traffic is gettign dropped.
>> This problem can be resolved by a reboot. but i would like to troubleshoot
>> it.
>> Could you please let me know how i can get more debugging message from the
>> bridge calls so i can figure out what exactly is happening.
>>
>> # uname -a
>> Linux vmclkxstgh04.espdev.aurdev.national.com.au 2.6.18-128.2.1.4.13.el5xen
>> #1 SMP Mon Dec 7 14:34:40 EST 2009 i686 i686 i386 GNU/Linux
>>
>> [root@vmclkxstgh04 ~]# brctl show
>> bridge name bridge id STP enabled interfaces
>> vlan441 8000.0017a4770470 no bond0.441
>> xenbrv205 8000.0017a477046c no bond1.205
>> xenbrv208 8000.0017a477046c no bond1.208
>> xenbrv220 8000.000000000000 no
>> xenbrv221 8000.000000000000 no
>> xenbrv226 8000.0017a477046c no vif40.1
>> vif39.1
>> vif37.1
>> vif26.1
>> vif25.1
>> vif24.1
>> vif13.1
>> bond1.226
>> xenbrv227 8000.0017a4770470 no vif40.0
>> vif39.0
>> vif37.0
>> vif26.0
>> vif25.0
>> vif24.0
>> vif13.0
>> bond0.227
>> xenbrv420 8000.0017a4770470 no bond0.420
>> xenbrv422 8000.0017a4770470 no vif35.0
>> vif7.0
>> vif6.0
>> vif4.0
>> vif3.0
>> vif2.0
>> tap2.0
>> bond0.422
>> xenbrv425 8000.0017a4770470 no bond0.425
>> xenbrv450 8000.0017a4770470 no bond0.450
>> xenbrv492 8000.0017a4770470 no bond0.492
>> xenbrv493 8000.0017a4770470 no bond0.493
>> xenbrv494 8000.0017a4770470 no bond0.494
>> xenbrv495 8000.0017a4770470 no bond0.495
>> xenbrv496 8000.0017a4770470 no bond0.496
>> xenbrv497 8000.0017a4770470 no bond0.497
>> xenbrv701 8000.0017a477046c no vif44.1
>> bond1.701
>>
>> bond0.497 Link encap:Ethernet HWaddr 00:17:A4:77:04:70
>> inet addr:10.12.166.231 Bcast:10.12.166.255 Mask:255.255.255.224
>> UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1
>> RX packets:3807595 errors:0 dropped:0 overruns:0 frame:0
>> TX packets:3304 errors:0 dropped:0 overruns:0 carrier:0
>> collisions:0 txqueuelen:0
>> RX bytes:188847200 (180.0 MiB) TX bytes:138768 (135.5 KiB)
>
> You are supposed to assign IP address to bridge not the member of the bridge.
>
>
> --
> _______________________________________________
> Bridge mailing list
> Bridge@lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/bridge
>
^ permalink raw reply
* [PATCH] igbvf: avoid name clash between PF and VF
From: Stefan Assmann @ 2010-06-30 8:53 UTC (permalink / raw)
To: netdev; +Cc: e1000-devel, Andy Gospodarek, jeffrey.t.kirsher, gregory.v.rose
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.
To avoid this problem we could change the kernel name for the VFs and
thus avoid confusion between VFs and PFs.
I've already discussed this with Alexander Duyck and Greg Rose, so far
they have no objection. However this problem appears for all drivers that
support PFs and VFs and thus the changes should be applied consistently
to all of these drivers.
Signed-off-by: Stefan Assmann <sassmann@redhat.com>
---
drivers/net/igbvf/netdev.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/igbvf/netdev.c b/drivers/net/igbvf/netdev.c
index 5e2b2a8..2fb665b 100644
--- a/drivers/net/igbvf/netdev.c
+++ b/drivers/net/igbvf/netdev.c
@@ -2787,7 +2787,7 @@ static int __devinit igbvf_probe(struct pci_dev *pdev,
netif_carrier_off(netdev);
netif_stop_queue(netdev);
- strcpy(netdev->name, "eth%d");
+ strcpy(netdev->name, "veth%d");
err = register_netdev(netdev);
if (err)
goto err_hw_init;
--
1.6.5.2
------------------------------------------------------------------------------
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 related
* [PATCH] act_mirred: combine duplicate code
From: Changli Gao @ 2010-06-30 8:54 UTC (permalink / raw)
To: Jamal Hadi Salim; +Cc: David S. Miller, netdev, linux-kernel, Changli Gao
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.
Signed-off-by: Changli Gao <xiaosuo@gmail.com>
----
net/sched/act_mirred.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/net/sched/act_mirred.c b/net/sched/act_mirred.c
index 2e9a7b9..a16b017 100644
--- a/net/sched/act_mirred.c
+++ b/net/sched/act_mirred.c
@@ -160,6 +160,8 @@ static int tcf_mirred(struct sk_buff *skb, struct tc_action *a,
spin_lock(&m->tcf_lock);
m->tcf_tm.lastuse = jiffies;
+ m->tcf_bstats.bytes += qdisc_pkt_len(skb);
+ m->tcf_bstats.packets++;
dev = m->tcfm_dev;
if (!(dev->flags & IFF_UP)) {
@@ -174,8 +176,6 @@ static int tcf_mirred(struct sk_buff *skb, struct tc_action *a,
if (skb2 == NULL)
goto out;
- m->tcf_bstats.bytes += qdisc_pkt_len(skb2);
- m->tcf_bstats.packets++;
if (!(at & AT_EGRESS)) {
if (m->tcfm_ok_push)
skb_push(skb2, skb2->dev->hard_header_len);
@@ -193,8 +193,6 @@ static int tcf_mirred(struct sk_buff *skb, struct tc_action *a,
out:
if (err) {
m->tcf_qstats.overlimits++;
- m->tcf_bstats.bytes += qdisc_pkt_len(skb);
- m->tcf_bstats.packets++;
/* should we be asking for packet to be dropped?
* may make sense for redirect case only
*/
^ permalink raw reply related
* [PATCH v2] net/core: use ntohs for skb->protocol
From: Sebastian Andrzej Siewior @ 2010-06-30 9:02 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20100629.151740.135534374.davem@davemloft.net>
From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
This is only noticed by people that are not doing everything correct in
the first place.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
---
net/core/dev.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index eb4be99..8e61dc5 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1537,7 +1537,8 @@ static void dev_queue_xmit_nit(struct sk_buff *skb, struct net_device *dev)
if (net_ratelimit())
printk(KERN_CRIT "protocol %04x is "
"buggy, dev %s\n",
- skb2->protocol, dev->name);
+ ntohs(skb2->protocol),
+ dev->name);
skb_reset_network_header(skb2);
}
--
1.6.6.1
^ permalink raw reply related
* [PATCH] act_nat: use stack variable
From: Changli Gao @ 2010-06-30 9:07 UTC (permalink / raw)
To: Jamal Hadi Salim; +Cc: Herbert Xu, David S. Miller, netdev, Changli Gao
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>
----
net/sched/act_nat.c | 31 ++++++++++---------------------
1 file changed, 10 insertions(+), 21 deletions(-)
diff --git a/net/sched/act_nat.c b/net/sched/act_nat.c
index 5709494..0be49a4 100644
--- a/net/sched/act_nat.c
+++ b/net/sched/act_nat.c
@@ -265,40 +265,29 @@ static int tcf_nat_dump(struct sk_buff *skb, struct tc_action *a,
{
unsigned char *b = skb_tail_pointer(skb);
struct tcf_nat *p = a->priv;
- struct tc_nat *opt;
+ struct tc_nat opt;
struct tcf_t t;
- int s;
- s = sizeof(*opt);
+ opt.old_addr = p->old_addr;
+ opt.new_addr = p->new_addr;
+ opt.mask = p->mask;
+ opt.flags = p->flags;
- /* netlink spinlocks held above us - must use ATOMIC */
- opt = kzalloc(s, GFP_ATOMIC);
- if (unlikely(!opt))
- return -ENOBUFS;
+ opt.index = p->tcf_index;
+ opt.action = p->tcf_action;
+ opt.refcnt = p->tcf_refcnt - ref;
+ opt.bindcnt = p->tcf_bindcnt - bind;
- opt->old_addr = p->old_addr;
- opt->new_addr = p->new_addr;
- opt->mask = p->mask;
- opt->flags = p->flags;
-
- opt->index = p->tcf_index;
- opt->action = p->tcf_action;
- opt->refcnt = p->tcf_refcnt - ref;
- opt->bindcnt = p->tcf_bindcnt - bind;
-
- NLA_PUT(skb, TCA_NAT_PARMS, s, opt);
+ NLA_PUT(skb, TCA_NAT_PARMS, sizeof(opt), &opt);
t.install = jiffies_to_clock_t(jiffies - p->tcf_tm.install);
t.lastuse = jiffies_to_clock_t(jiffies - p->tcf_tm.lastuse);
t.expires = jiffies_to_clock_t(p->tcf_tm.expires);
NLA_PUT(skb, TCA_NAT_TM, sizeof(t), &t);
- kfree(opt);
-
return skb->len;
nla_put_failure:
nlmsg_trim(skb, b);
- kfree(opt);
return -1;
}
^ permalink raw reply related
* [PATCH] xfrm: fix XFRMA_MARK extraction in xfrm_mark_get
From: Andreas Steffen @ 2010-06-30 7:57 UTC (permalink / raw)
To: netdev; +Cc: jamal, David Miller
Determine the size of the xfrm_mark struct, not of its pointer.
Signed-off-by: Andreas Steffen <andreas.steffen@strongswan.org>
---
include/net/xfrm.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/net/xfrm.h b/include/net/xfrm.h
index 1913af6..fc8f36d 100644
--- a/include/net/xfrm.h
+++ b/include/net/xfrm.h
@@ -1586,7 +1586,7 @@ static inline struct xfrm_state *xfrm_input_state(struct sk_buff *skb)
static inline int xfrm_mark_get(struct nlattr **attrs, struct xfrm_mark *m)
{
if (attrs[XFRMA_MARK])
- memcpy(m, nla_data(attrs[XFRMA_MARK]), sizeof(m));
+ memcpy(m, nla_data(attrs[XFRMA_MARK]), sizeof(struct xfrm_mark));
else
m->v = m->m = 0;
--
1.7.0.4
^ permalink raw reply related
* 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
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