* Re: [*v2 PATCH 08/22] IPVS: netns preparation for proto_sctp
From: Simon Horman @ 2010-12-13 22:23 UTC (permalink / raw)
To: Hans Schillstrom
Cc: ja, daniel.lezcano, wensong, lvs-devel, netdev, netfilter-devel,
hans
In-Reply-To: <1292247510-753-9-git-send-email-hans.schillstrom@ericsson.com>
On Mon, Dec 13, 2010 at 02:38:16PM +0100, Hans Schillstrom wrote:
> In this phase (one), all local vars will be moved to ipvs struct.
>
> Remaining work, add param struct net *net to a couple of
> functions that is common for all protos and use ip_vs_proto_data
>
> Signed-off-by: Hans Schillstrom <hans.schillstrom@ericsson.com>
[ snip ]
> diff --git a/net/netfilter/ipvs/ip_vs_proto_sctp.c b/net/netfilter/ipvs/ip_vs_proto_sctp.c
> index 521b827..108ae0c 100644
> --- a/net/netfilter/ipvs/ip_vs_proto_sctp.c
> +++ b/net/netfilter/ipvs/ip_vs_proto_sctp.c
[ snip ]
> @@ -1101,43 +1098,51 @@ static int sctp_app_conn_bind(struct ip_vs_conn *cp)
> goto out;
> }
> }
> - spin_unlock(&sctp_app_lock);
> + spin_unlock(&ipvs->sctp_app_lock);
> out:
> return result;
> }
>
> -static void ip_vs_sctp_init(struct ip_vs_protocol *pp)
> +/* ---------------------------------------------
> + * timeouts is netns related now.
> + * ---------------------------------------------
> + */
> +static void __ip_vs_sctp_init(struct net *net, struct ip_vs_proto_data *pd)
> {
> - IP_VS_INIT_HASH_TABLE(sctp_apps);
> - pp->timeout_table = sctp_timeouts;
> -}
> + struct netns_ipvs *ipvs = net_ipvs(net);
>
> + ip_vs_init_hash_table(ipvs->sctp_apps, SCTP_APP_TAB_SIZE);
> + spin_lock_init(&ipvs->tcp_app_lock);
> + pd->timeout_table = ip_vs_create_timeout_table((int*)sctp_timeouts,
> + sizeof(sctp_timeouts));
> +}
>
> -static void ip_vs_sctp_exit(struct ip_vs_protocol *pp)
> +static void __ip_vs_sctp_exit(struct net *net, struct ip_vs_proto_data *pd)
> {
> -
> + kfree(pd->timeout_table);
> }
>
> struct ip_vs_protocol ip_vs_protocol_sctp = {
> - .name = "SCTP",
> - .protocol = IPPROTO_SCTP,
> - .num_states = IP_VS_SCTP_S_LAST,
> - .dont_defrag = 0,
> - .appcnt = ATOMIC_INIT(0),
> - .init = ip_vs_sctp_init,
> - .exit = ip_vs_sctp_exit,
> - .register_app = sctp_register_app,
> + .name = "SCTP",
> + .protocol = IPPROTO_SCTP,
> + .num_states = IP_VS_SCTP_S_LAST,
> + .dont_defrag = 0,
> + .init = NULL,
> + .exit = NULL,
> + .init_netns = __ip_vs_sctp_init,
> + .exit_netns = __ip_vs_sctp_exit,
> + .register_app = sctp_register_app,
> .unregister_app = sctp_unregister_app,
> - .conn_schedule = sctp_conn_schedule,
> - .conn_in_get = ip_vs_conn_in_get_proto,
> - .conn_out_get = ip_vs_conn_out_get_proto,
> - .snat_handler = sctp_snat_handler,
> - .dnat_handler = sctp_dnat_handler,
> - .csum_check = sctp_csum_check,
> - .state_name = sctp_state_name,
> + .conn_schedule = sctp_conn_schedule,
> + .conn_in_get = ip_vs_conn_in_get_proto,
> + .conn_out_get = ip_vs_conn_out_get_proto,
> + .snat_handler = sctp_snat_handler,
> + .dnat_handler = sctp_dnat_handler,
> + .csum_check = sctp_csum_check,
> + .state_name = sctp_state_name,
> .state_transition = sctp_state_transition,
> - .app_conn_bind = sctp_app_conn_bind,
> - .debug_packet = ip_vs_tcpudp_debug_packet,
> - .timeout_change = sctp_timeout_change,
> - .set_state_timeout = sctp_set_state_timeout,
> + .app_conn_bind = sctp_app_conn_bind,
> + .debug_packet = ip_vs_tcpudp_debug_packet,
> + .timeout_change = NULL,
> +/* .set_state_timeout = sctp_set_state_timeout, */
> };
While I'm not a big fan or the original formatting,
the whitespace changes above make it rather difficult to see
what is really being changed. Could you either drop
the whitespace changes or move them into a separate patch?
^ permalink raw reply
* Re: Fw: [Bug 24842] New: Compatibility issue with uggly Windows RFC1323 implementation.
From: Eric Dumazet @ 2010-12-13 22:31 UTC (permalink / raw)
To: Дмитрий Балакин,
David Miller
Cc: Stephen Hemminger, netdev
In-Reply-To: <AANLkTikTgbKSNYHthic8P3bi9+ewN8fEBknnSK=tdTgU@mail.gmail.com>
Le lundi 13 décembre 2010 à 23:44 +0300, Дмитрий Балакин a écrit :
> 2010/12/13 Eric Dumazet <eric.dumazet@gmail.com>:
> > Le lundi 13 décembre 2010 à 08:59 -0800, Stephen Hemminger a écrit :
> >>
> >> Begin forwarded message:
> >>
> >> Date: Mon, 13 Dec 2010 14:29:58 GMT
> >> From: bugzilla-daemon@bugzilla.kernel.org
> >> To: shemminger@linux-foundation.org
> >> Subject: [Bug 24842] New: Compatibility issue with uggly Windows RFC1323 implementation.
> >>
> >>
> >> https://bugzilla.kernel.org/show_bug.cgi?id=24842
> >>
> >> Summary: Compatibility issue with uggly Windows RFC1323
> >> implementation.
> >> Product: Networking
> >> Version: 2.5
> >> Kernel Version: All
> >> Platform: All
> >> OS/Version: Linux
> >> Tree: Mainline
> >> Status: NEW
> >> Severity: normal
> >> Priority: P1
> >> Component: IPV4
> >> AssignedTo: shemminger@linux-foundation.org
> >> ReportedBy: dmitriy.balakin@nicneiron.ru
> >> Regression: No
> >>
> >>
> >> Created an attachment (id=40012)
> >> --> (https://bugzilla.kernel.org/attachment.cgi?id=40012)
> >> Patch
> >>
> >> First, sorry for my bad english.
> >>
> >> The issue is that Linux-based OS sometimes can't make an tcp connection to some
> >> Windows servers with switched on buggy implementation of rfc1323, that
> >> described on this forum:
> >> http://www.network-builders.com/windows-tcp-timestamp-not-compliant-rfc-1323-a-t80898.html.
> >>
> >> Because some Windows hosts implementation of rfc1323 bases on randomly
> >> generated TSval and sent first value of TSval as 0, the difference of recent
> >> and new TSval sometimes has been affected by a sign magic issue and the PAWS
> >> mechanism has been triggered. Anyway, the rfc1323 has discribes the condition
> >> of PAWS as "0 < (t - s) < 2**31", that has been right implementation in current
> >> linux kernel, but incompatible with Windows bug.
> >>
> >> For example, the one of affected to this issue Windows host is behind
> >> relay.n-l-e.ru:80
> >>
> >> I think that my small patch makes the kernel more compatible with this windows
> >> bug.
> >>
> >> -
> >
> > I have no problem connecting my linux client to relay.n-l-e.ru:80
> >
> > Could you elaborate please ?
> >
> > 18:13:12.444250 IP 10.150.51.215.51781 > 212.176.201.162.80: Flags [S],
> > seq 665972386, win 5840, options [mss 1460,sackOK,TS val 1746885 ecr
> > 0,nop,wscale 7], length 0
> > 18:13:12.473912 IP 212.176.201.162.80 > 10.150.51.215.51781: Flags [S.],
> > seq 190215045, ack 665972387, win 5792, options [mss 1460,sackOK,TS val
> > 730697107 ecr 1746885,nop,wscale 0], length 0
> > 18:13:12.473976 IP 10.150.51.215.51781 > 212.176.201.162.80: Flags [.],
> > ack 1, win 46, options [nop,nop,TS val 1746888 ecr 730697107], length 0
> > 18:13:14.984153 IP 10.150.51.215.51781 > 212.176.201.162.80: Flags [P.],
> > seq 1:8, ack 1, win 46, options [nop,nop,TS val 1747139 ecr 730697107],
> > length 7
> > 18:13:15.013901 IP 212.176.201.162.80 > 10.150.51.215.51781: Flags [.],
> > ack 8, win 5792, options [nop,nop,TS val 730697360 ecr 1747139], length
> > 0
> > 18:13:15.377879 IP 10.150.51.215.51781 > 212.176.201.162.80: Flags [P.],
> > seq 8:10, ack 1, win 46, options [nop,nop,TS val 1747178 ecr 730697360],
> > length 2
> > 18:13:15.403900 IP 212.176.201.162.80 > 10.150.51.215.51781: Flags [.],
> > ack 10, win 5792, options [nop,nop,TS val 730697399 ecr 1747178], length
> > 0
> > 18:13:15.461384 IP 212.176.201.162.80 > 10.150.51.215.51781: Flags [P.],
> > seq 1:159, ack 10, win 5792, options [nop,nop,TS val 730697405 ecr
> > 1747178], length 158
> > 18:13:15.461429 IP 10.150.51.215.51781 > 212.176.201.162.80: Flags [.],
> > ack 159, win 54, options [nop,nop,TS val 1747186 ecr 730697405], length
> > 0
> > 18:13:15.461448 IP 212.176.201.162.80 > 10.150.51.215.51781: Flags [F.],
> > seq 159, ack 10, win 5792, options [nop,nop,TS val 730697405 ecr
> > 1747178], length 0
> > 18:13:15.461607 IP 10.150.51.215.51781 > 212.176.201.162.80: Flags [F.],
> > seq 10, ack 160, win 54, options [nop,nop,TS val 1747186 ecr 730697405],
> > length 0
> > 18:13:15.533846 IP 212.176.201.162.80 > 10.150.51.215.51781: Flags [.],
> > ack 11, win 5792, options [nop,nop,TS val 730697412 ecr 1747186], length
> > 0
> >
> >
> >
>
> Problems occur only when the remote side sets the TC val > 2147483647,
> ie when there is a sign:
>
You mean a windows machine with a big uptime ?
That must be quite rare indeed ;)
Anyway, we can not test values like suggested patch, or risk a problem
when wrap around occurs...
However, testing the special ts_recent=0 case would be possible (we
already did a change to accept a windows initiated connect to a linux
server and still activate tcp timestamps)
(commit fc1ad92dfc4e363a055 tcp: allow timestamps even if SYN packet has
tsval=0)
Something like following patch ?
Thanks
[PATCH net-next-2.6] tcp: relax tcp_paws_check()
Some windows versions have wrong RFC1323 implementations, with SYN and
SYNACKS messages containing zero tcp timestamps.
We relaxed in commit fc1ad92dfc4e363 the passive connection case
(Windows connects to a linux machine), but the reverse case (linux
connects to a Windows machine) has an analogue problem when tsvals from
windows machine are 'negative' (high order bit set) : PAWS triggers and
we drops incoming messages.
Fix this by making zero ts_recent value special, allowing frame to be
processed.
Based on a report and initial patch from Dmitiy Balakin
Bugzilla reference : https://bugzilla.kernel.org/show_bug.cgi?id=24842
Reported-by: dmitriy.balakin@nicneiron.ru
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
include/net/tcp.h | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/include/net/tcp.h b/include/net/tcp.h
index 3f227ba..2ab6c9c 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -1038,7 +1038,13 @@ static inline int tcp_paws_check(const struct tcp_options_received *rx_opt,
return 1;
if (unlikely(get_seconds() >= rx_opt->ts_recent_stamp + TCP_PAWS_24DAYS))
return 1;
-
+ /*
+ * Some OSes send SYN and SYNACK messages with tsval=0 tsecr=0,
+ * then following tcp messages have valid values. Ignore 0 value,
+ * or else 'negative' tsval might forbid us to accept their packets.
+ */
+ if (!rx_opt->ts_recent)
+ return 1;
return 0;
}
^ permalink raw reply related
* [PATCH net-next-2.6 v3] net: factorize sync-rcu call in unregister_netdevice_many
From: Octavian Purdila @ 2010-12-13 22:44 UTC (permalink / raw)
To: netdev; +Cc: Lucian Adrian Grijincu, Vlad Dogaru, Octavian Purdila
Add dev_close_many and dev_deactivate_many to factorize another
sync-rcu operation on the netdevice unregister path.
$ modprobe dummy numdummies=10000
$ ip link set dev dummy* up
$ time rmmod dummy
Without the patch With the patch
real 0m 24.63s real 0m 5.15s
user 0m 0.00s user 0m 0.00s
sys 0m 6.05s sys 0m 5.14s
Signed-off-by: Octavian Purdila <opurdila@ixiacom.com>
---
Changes from v2:
* don't delete entries from dev_close_many otherwise rollback_registered_many
will not complete the cleanup for the deleted entries
Changes from v1:
* move ASSERT_RTNL() and might_sleep() out of the loop
include/net/sch_generic.h | 1 +
net/core/dev.c | 118 +++++++++++++++++++++++++++++----------------
net/sched/sch_generic.c | 29 ++++++++---
3 files changed, 99 insertions(+), 49 deletions(-)
diff --git a/include/net/sch_generic.h b/include/net/sch_generic.h
index ea1f8a8..786cc39 100644
--- a/include/net/sch_generic.h
+++ b/include/net/sch_generic.h
@@ -321,6 +321,7 @@ extern void dev_init_scheduler(struct net_device *dev);
extern void dev_shutdown(struct net_device *dev);
extern void dev_activate(struct net_device *dev);
extern void dev_deactivate(struct net_device *dev);
+extern void dev_deactivate_many(struct list_head *head);
extern struct Qdisc *dev_graft_qdisc(struct netdev_queue *dev_queue,
struct Qdisc *qdisc);
extern void qdisc_reset(struct Qdisc *qdisc);
diff --git a/net/core/dev.c b/net/core/dev.c
index d28b3a0..33296ef 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1222,52 +1222,90 @@ int dev_open(struct net_device *dev)
}
EXPORT_SYMBOL(dev_open);
-static int __dev_close(struct net_device *dev)
+static int __dev_close_many(struct list_head *head)
{
- const struct net_device_ops *ops = dev->netdev_ops;
+ struct net_device *dev;
ASSERT_RTNL();
might_sleep();
- /*
- * Tell people we are going down, so that they can
- * prepare to death, when device is still operating.
- */
- call_netdevice_notifiers(NETDEV_GOING_DOWN, dev);
+ list_for_each_entry(dev, head, unreg_list) {
+ /*
+ * Tell people we are going down, so that they can
+ * prepare to death, when device is still operating.
+ */
+ call_netdevice_notifiers(NETDEV_GOING_DOWN, dev);
- clear_bit(__LINK_STATE_START, &dev->state);
+ clear_bit(__LINK_STATE_START, &dev->state);
- /* Synchronize to scheduled poll. We cannot touch poll list,
- * it can be even on different cpu. So just clear netif_running().
- *
- * dev->stop() will invoke napi_disable() on all of it's
- * napi_struct instances on this device.
- */
- smp_mb__after_clear_bit(); /* Commit netif_running(). */
+ /* Synchronize to scheduled poll. We cannot touch poll list, it
+ * can be even on different cpu. So just clear netif_running().
+ *
+ * dev->stop() will invoke napi_disable() on all of it's
+ * napi_struct instances on this device.
+ */
+ smp_mb__after_clear_bit(); /* Commit netif_running(). */
+ }
- dev_deactivate(dev);
+ dev_deactivate_many(head);
- /*
- * Call the device specific close. This cannot fail.
- * Only if device is UP
- *
- * We allow it to be called even after a DETACH hot-plug
- * event.
- */
- if (ops->ndo_stop)
- ops->ndo_stop(dev);
+ list_for_each_entry(dev, head, unreg_list) {
+ const struct net_device_ops *ops = dev->netdev_ops;
- /*
- * Device is now down.
- */
+ /*
+ * Call the device specific close. This cannot fail.
+ * Only if device is UP
+ *
+ * We allow it to be called even after a DETACH hot-plug
+ * event.
+ */
+ if (ops->ndo_stop)
+ ops->ndo_stop(dev);
+
+ /*
+ * Device is now down.
+ */
+
+ dev->flags &= ~IFF_UP;
+
+ /*
+ * Shutdown NET_DMA
+ */
+ net_dmaengine_put();
+ }
- dev->flags &= ~IFF_UP;
+ return 0;
+}
+
+static int __dev_close(struct net_device *dev)
+{
+ LIST_HEAD(single);
+
+ list_add(&dev->unreg_list, &single);
+ return __dev_close_many(&single);
+}
+
+int dev_close_many(struct list_head *head)
+{
+ struct net_device *dev, *tmp;
+ LIST_HEAD(tmp_list);
+
+ list_for_each_entry_safe(dev, tmp, head, unreg_list)
+ if (!(dev->flags & IFF_UP))
+ list_move(&dev->unreg_list, &tmp_list);
+
+ __dev_close_many(head);
/*
- * Shutdown NET_DMA
+ * Tell people we are down
*/
- net_dmaengine_put();
+ list_for_each_entry(dev, head, unreg_list) {
+ rtmsg_ifinfo(RTM_NEWLINK, dev, IFF_UP|IFF_RUNNING);
+ call_netdevice_notifiers(NETDEV_DOWN, dev);
+ }
+ /* rollback_registered_many needs the complete original list */
+ list_splice(&tmp_list, head);
return 0;
}
@@ -1282,16 +1320,10 @@ static int __dev_close(struct net_device *dev)
*/
int dev_close(struct net_device *dev)
{
- if (!(dev->flags & IFF_UP))
- return 0;
-
- __dev_close(dev);
+ LIST_HEAD(single);
- /*
- * Tell people we are down
- */
- rtmsg_ifinfo(RTM_NEWLINK, dev, IFF_UP|IFF_RUNNING);
- call_netdevice_notifiers(NETDEV_DOWN, dev);
+ list_add(&dev->unreg_list, &single);
+ dev_close_many(&single);
return 0;
}
@@ -4958,10 +4990,12 @@ static void rollback_registered_many(struct list_head *head)
}
BUG_ON(dev->reg_state != NETREG_REGISTERED);
+ }
- /* If device is running, close it first. */
- dev_close(dev);
+ /* If device is running, close it first. */
+ dev_close_many(head);
+ list_for_each_entry(dev, head, unreg_list) {
/* And unlink it from device chain. */
unlist_netdevice(dev);
diff --git a/net/sched/sch_generic.c b/net/sched/sch_generic.c
index 0918834..34dc598 100644
--- a/net/sched/sch_generic.c
+++ b/net/sched/sch_generic.c
@@ -810,20 +810,35 @@ static bool some_qdisc_is_busy(struct net_device *dev)
return false;
}
-void dev_deactivate(struct net_device *dev)
+void dev_deactivate_many(struct list_head *head)
{
- netdev_for_each_tx_queue(dev, dev_deactivate_queue, &noop_qdisc);
- if (dev_ingress_queue(dev))
- dev_deactivate_queue(dev, dev_ingress_queue(dev), &noop_qdisc);
+ struct net_device *dev;
- dev_watchdog_down(dev);
+ list_for_each_entry(dev, head, unreg_list) {
+ netdev_for_each_tx_queue(dev, dev_deactivate_queue,
+ &noop_qdisc);
+ if (dev_ingress_queue(dev))
+ dev_deactivate_queue(dev, dev_ingress_queue(dev),
+ &noop_qdisc);
+
+ dev_watchdog_down(dev);
+ }
/* Wait for outstanding qdisc-less dev_queue_xmit calls. */
synchronize_rcu();
/* Wait for outstanding qdisc_run calls. */
- while (some_qdisc_is_busy(dev))
- yield();
+ list_for_each_entry(dev, head, unreg_list)
+ while (some_qdisc_is_busy(dev))
+ yield();
+}
+
+void dev_deactivate(struct net_device *dev)
+{
+ LIST_HEAD(single);
+
+ list_add(&dev->unreg_list, &single);
+ dev_deactivate_many(&single);
}
static void dev_init_scheduler_queue(struct net_device *dev,
--
1.7.1
^ permalink raw reply related
* Re: [PATCH 2.6.36] vlan: Avoid hwaccel vlan packets when vid not used
From: Matt Carlson @ 2010-12-13 22:45 UTC (permalink / raw)
To: Jesse Gross
Cc: Michael Leun, Matthew Carlson, Michael Chan, Eric Dumazet,
David Miller, Ben Greear, linux-kernel@vger.kernel.org,
netdev@vger.kernel.org
In-Reply-To: <AANLkTinLMCzKz7n45HdeAwNxsWjCADAkgfK+MjXVcFqh@mail.gmail.com>
On Sun, Dec 12, 2010 at 04:11:13PM -0800, Jesse Gross wrote:
> On Mon, Dec 6, 2010 at 1:27 PM, Michael Leun
> <lkml20101129@newton.leun.net> wrote:
> > On Mon, 6 Dec 2010 12:04:48 -0800
> > Jesse Gross <jesse@nicira.com> wrote:
> >
> >> On Mon, Dec 6, 2010 at 11:34 AM, Michael Leun
> >> <lkml20101129@newton.leun.net> wrote:
> >> > On Mon, 6 Dec 2010 10:14:55 -0800
> >> > Jesse Gross <jesse@nicira.com> wrote:
> >> >
> >> >> On Sun, Dec 5, 2010 at 2:44 AM, Michael Leun
> >> >> <lkml20101129@newton.leun.net> wrote:
> >> >> > Hi Jesse,
> >> >> >
> >> >> > On Sun, 5 Dec 2010 10:55:28 +0100
> >> >> > Michael Leun <lkml20101129@newton.leun.net> wrote:
> >> >> >
> >> >> >> On Sun, 05 Dec 2010 09:03:53 +0100
> >> >> >> Eric Dumazet <eric.dumazet@gmail.com> wrote:
> >> >> >>
> >> >> >> > > But on
> >> >> >> > >
> >> >> >> > > hpdl320g5:/home/ml # lspci | grep Eth
> >> >> >> > > 03:04.0 Ethernet controller: Broadcom Corporation NetXtreme
> >> >> >> > > BCM5714 Gigabit Ethernet (rev a3) 03:04.1 Ethernet
> >> >> >> > > controller: Broadcom Corporation NetXtreme BCM5714 Gigabit
> >> >> >> > > Ethernet (rev a3)
> >> >> >> > >
> >> >> >> > > the good message is that it also does not crash, but with
> >> >> >> > > tcpdump I see vlan tags when no vlan devices configured on
> >> >> >> > > the respective eth, if so I do not see tags anymore vlan
> >> >> >> > > tags on the trunk interface.
> >> >> >> > >
> >> >> >> >
> >> >> >> > For all these very specific needs, you'll have to try 2.6.37
> >> >> >> > I am afraid. Jesse did huge changes to exactly make this
> >> >> >> > working, we wont backport this to 2.6.36, but only avoid
> >> >> >> > crashes.
> >> >> >>
> >> >> >> OK, I'm perfectly fine with that, of course, actually nice to
> >> >> >> hear that the issue already is addressed.
> >> >> >>
> >> >> >> Likely I'll give some rc an shot on this machine (maybe over
> >> >> >> christmas), but it is an production machine (acutally testing
> >> >> >> other devices is the "product" produced on this machine), so
> >> >> >> unfortunately I'm not that free in when and what I can do (but
> >> >> >> the possibility to, for example, bridge the trunk interface
> >> >> >> would make testing easier, that justifies something...).
> >> >> >>
> >> >> >> Thank you all very much for your work.
> >> >> >
> >> >> > Are these changes already in 2.6.37-rc4? Or, if not are they
> >> >> > somewhere publically available already?
> >> >> >
> >> >> > I looked into various changelogs but have some difficulties to
> >> >> > identify them...
> >> >> >
> >> >> > Maybe I have some time next days to give them an try...
> >> >>
> >> >> Yes, all of the existing vlan changes are in 2.6.37-rc4. ?There
> >> >> were a number of patches but the main one was
> >> >> 3701e51382a026cba10c60b03efabe534fba4ca4
> >> >
> >> > Then, I'm afraid, this (seeing vlan tags even if vlan interfaces are
> >> > configured) does not work on HP DL320G5 (for exact description and
> >> > examples please see my mail a few days ago).
> >>
> >> What driver are you using? ?Is it tg3?
> >>
> >> The vlan changes that I made unfortunately require updating drivers to
> >> get the full benefit. ?I've been busy lately so tg3 hasn't yet been
> >> updated.
> >>
> >> I know that tg3 does some things differently depending on whether a
> >> vlan group is configured, so that would likely be the cause of what
> >> you are seeing. ?I'd have to look at it in more detail to be sure
> >> though.
> >>
> >> You said that everything works on the other Broadcom NIC that you
> >> tested? ?Maybe it uses bnx2 instead?
> >>
> >
> > Both machines use tg3 / 2.6.36.1 - one is opensuse, one ubuntu (but
> > this should not matter, I think).
> >
> > If I can do anything to support your investigations / work (most
> > likely testing / providing information) please let me know.
>
> Unfortunately, I probably won't have time to look at this in the near
> future. Given that the test works on one NIC but not another that
> strongly suggests that it is a driver problem, even if both NICs use
> the same driver. I see tg3 can do different things with vlans
> depending on the model and what features are enabled. I also ran a
> quick test on some of my machines and I didn't experience this issue.
> They are running net-next with ixgbe.
>
> One of the main goals of my general vlan changes was to remove as much
> logic as possible from the drivers and put it in the networking core,
> so we should in theory see consistent behavior. However, in 2.6.36
> and earlier, each driver knows about what vlan devices are configured
> and does different things with that information.
>
> Given all of that, the most logical step to me is simply to convert
> tg3 to use the new vlan infrastructure. It should be done regardless
> and it will probably solve this problem. Maybe you can convince the
> Broadcom guys to do that? It would be a lot faster for them to do it
> than me.
Below is the patch that converts the tg3 driver over to the new API. I
don't see how it could fix the problem though. Maybe the presence of
NETIF_F_HW_VLAN_TX changes things.
Compile tested only.
----
Subject: [PATCH] tg3: Use new VLAN code
This patch pivots the tg3 driver to the new VLAN infrastructure.
---
drivers/net/tg3.c | 42 ++++++++----------------------------------
1 files changed, 8 insertions(+), 34 deletions(-)
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 5faa87d..2a3f83d 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -134,9 +134,6 @@
TG3_TX_RING_SIZE)
#define NEXT_TX(N) (((N) + 1) & (TG3_TX_RING_SIZE - 1))
-#define TG3_RX_DMA_ALIGN 16
-#define TG3_RX_HEADROOM ALIGN(VLAN_HLEN, TG3_RX_DMA_ALIGN)
-
#define TG3_DMA_BYTE_ENAB 64
#define TG3_RX_STD_DMA_SZ 1536
@@ -4725,8 +4722,6 @@ static int tg3_rx(struct tg3_napi *tnapi, int budget)
struct sk_buff *skb;
dma_addr_t dma_addr;
u32 opaque_key, desc_idx, *post_ptr;
- bool hw_vlan __maybe_unused = false;
- u16 vtag __maybe_unused = 0;
desc_idx = desc->opaque & RXD_OPAQUE_INDEX_MASK;
opaque_key = desc->opaque & RXD_OPAQUE_RING_MASK;
@@ -4785,12 +4780,12 @@ static int tg3_rx(struct tg3_napi *tnapi, int budget)
tg3_recycle_rx(tnapi, tpr, opaque_key,
desc_idx, *post_ptr);
- copy_skb = netdev_alloc_skb(tp->dev, len + VLAN_HLEN +
+ copy_skb = netdev_alloc_skb(tp->dev, len +
TG3_RAW_IP_ALIGN);
if (copy_skb == NULL)
goto drop_it_no_recycle;
- skb_reserve(copy_skb, TG3_RAW_IP_ALIGN + VLAN_HLEN);
+ skb_reserve(copy_skb, TG3_RAW_IP_ALIGN);
skb_put(copy_skb, len);
pci_dma_sync_single_for_cpu(tp->pdev, dma_addr, len, PCI_DMA_FROMDEVICE);
skb_copy_from_linear_data(skb, copy_skb->data, len);
@@ -4817,30 +4812,11 @@ static int tg3_rx(struct tg3_napi *tnapi, int budget)
}
if (desc->type_flags & RXD_FLAG_VLAN &&
- !(tp->rx_mode & RX_MODE_KEEP_VLAN_TAG)) {
- vtag = desc->err_vlan & RXD_VLAN_MASK;
-#if TG3_VLAN_TAG_USED
- if (tp->vlgrp)
- hw_vlan = true;
- else
-#endif
- {
- struct vlan_ethhdr *ve = (struct vlan_ethhdr *)
- __skb_push(skb, VLAN_HLEN);
-
- memmove(ve, skb->data + VLAN_HLEN,
- ETH_ALEN * 2);
- ve->h_vlan_proto = htons(ETH_P_8021Q);
- ve->h_vlan_TCI = htons(vtag);
- }
- }
+ !(tp->rx_mode & RX_MODE_KEEP_VLAN_TAG))
+ __vlan_hwaccel_put_tag(skb,
+ desc->err_vlan & RXD_VLAN_MASK);
-#if TG3_VLAN_TAG_USED
- if (hw_vlan)
- vlan_gro_receive(&tnapi->napi, tp->vlgrp, vtag, skb);
- else
-#endif
- napi_gro_receive(&tnapi->napi, skb);
+ napi_gro_receive(&tnapi->napi, skb);
received++;
budget--;
@@ -13866,11 +13842,11 @@ static int __devinit tg3_get_invariants(struct tg3 *tp)
else
tp->tg3_flags &= ~TG3_FLAG_POLL_SERDES;
- tp->rx_offset = NET_IP_ALIGN + TG3_RX_HEADROOM;
+ tp->rx_offset = NET_IP_ALIGN;
tp->rx_copy_thresh = TG3_RX_COPY_THRESHOLD;
if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5701 &&
(tp->tg3_flags & TG3_FLAG_PCIX_MODE) != 0) {
- tp->rx_offset -= NET_IP_ALIGN;
+ tp->rx_offset = 0;
#ifndef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
tp->rx_copy_thresh = ~(u16)0;
#endif
@@ -14705,9 +14681,7 @@ static int __devinit tg3_init_one(struct pci_dev *pdev,
SET_NETDEV_DEV(dev, &pdev->dev);
-#if TG3_VLAN_TAG_USED
dev->features |= NETIF_F_HW_VLAN_TX | NETIF_F_HW_VLAN_RX;
-#endif
tp = netdev_priv(dev);
tp->pdev = pdev;
--
1.7.2.2
^ permalink raw reply related
* [PATCH update 3] firewire: net: add carrier detection
From: Stefan Richter @ 2010-12-13 23:01 UTC (permalink / raw)
To: Maxim Levitsky; +Cc: Ben Hutchings, netdev, linux1394-devel, Peter Stuge
In-Reply-To: <20101213014602.6bc2727b@stein>
From: Maxim Levitsky <maximlevitsky@gmail.com>
To make userland, e.g. NetworkManager work with firewire, we need to
detect whether cable is plugged or not. Simple and correct way of doing
that is just counting number of peers. No peers - no link and vice
versa.
(Stefan R.: Combined peer_count inc/dec with tests, added link-down
recognition in fwnet_open, added include.)
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
---
Update 3: added fwnet_open (ifup) hunk
drivers/firewire/net.c | 29 +++++++++++++++++++++++++----
1 file changed, 25 insertions(+), 4 deletions(-)
Index: b/drivers/firewire/net.c
===================================================================
--- a/drivers/firewire/net.c
+++ b/drivers/firewire/net.c
@@ -9,6 +9,7 @@
#include <linux/bug.h>
#include <linux/delay.h>
#include <linux/device.h>
+#include <linux/ethtool.h>
#include <linux/firewire.h>
#include <linux/firewire-constants.h>
#include <linux/highmem.h>
@@ -179,6 +180,7 @@ struct fwnet_device {
/* Number of tx datagrams that have been queued but not yet acked */
int queued_datagrams;
+ int peer_count;
struct list_head peer_list;
struct fw_card *card;
struct net_device *netdev;
@@ -1234,6 +1236,13 @@ static int fwnet_open(struct net_device
}
netif_start_queue(net);
+ mutex_lock(&fwnet_device_mutex);
+ if (dev->peer_count > 1)
+ netif_carrier_on(net);
+ else
+ netif_carrier_off(net);
+ mutex_unlock(&fwnet_device_mutex);
+
return 0;
}
@@ -1412,6 +1421,10 @@ static const struct net_device_ops fwnet
.ndo_change_mtu = fwnet_change_mtu,
};
+static const struct ethtool_ops fwnet_ethtool_ops = {
+ .get_link = ethtool_op_get_link,
+};
+
static void fwnet_init_dev(struct net_device *net)
{
net->header_ops = &fwnet_header_ops;
@@ -1423,6 +1436,7 @@ static void fwnet_init_dev(struct net_de
net->hard_header_len = FWNET_HLEN;
net->type = ARPHRD_IEEE1394;
net->tx_queue_len = FWNET_TX_QUEUE_LEN;
+ net->ethtool_ops = &fwnet_ethtool_ops;
}
/* caller must hold fwnet_device_mutex */
@@ -1465,6 +1479,10 @@ static int fwnet_add_peer(struct fwnet_d
list_add_tail(&peer->peer_link, &dev->peer_list);
spin_unlock_irq(&dev->lock);
+ /* serialized by fwnet_device_mutex */
+ if (++dev->peer_count > 1)
+ netif_carrier_on(dev->netdev);
+
return 0;
}
@@ -1543,13 +1561,16 @@ static int fwnet_probe(struct device *_d
return ret;
}
-static void fwnet_remove_peer(struct fwnet_peer *peer)
+static void fwnet_remove_peer(struct fwnet_peer *peer, struct fwnet_device *dev)
{
struct fwnet_partial_datagram *pd, *pd_next;
- spin_lock_irq(&peer->dev->lock);
+ if (--dev->peer_count == 1)
+ netif_carrier_off(dev->netdev);
+
+ spin_lock_irq(&dev->lock);
list_del(&peer->peer_link);
- spin_unlock_irq(&peer->dev->lock);
+ spin_unlock_irq(&dev->lock);
list_for_each_entry_safe(pd, pd_next, &peer->pd_list, pd_link)
fwnet_pd_delete(pd);
@@ -1566,7 +1587,7 @@ static int fwnet_remove(struct device *_
mutex_lock(&fwnet_device_mutex);
- fwnet_remove_peer(peer);
+ fwnet_remove_peer(peer, dev);
if (list_empty(&dev->peer_list)) {
net = dev->netdev;
--
Stefan Richter
-=====-==-=- ==-- -==-=
http://arcgraph.de/sr/
------------------------------------------------------------------------------
Lotusphere 2011
Register now for Lotusphere 2011 and learn how
to connect the dots, take your collaborative environment
to the next level, and enter the era of Social Business.
http://p.sf.net/sfu/lotusphere-d2d
^ permalink raw reply
* Re: [PATCH net-next-2.6 v2] net: factorize sync-rcu call in unregister_netdevice_many
From: Stephen Hemminger @ 2010-12-13 23:32 UTC (permalink / raw)
To: Octavian Purdila; +Cc: netdev, Lucian Adrian Grijincu, Vlad Dogaru
In-Reply-To: <1292277293-6565-1-git-send-email-opurdila@ixiacom.com>
On Mon, 13 Dec 2010 23:54:53 +0200
Octavian Purdila <opurdila@ixiacom.com> wrote:
> + /*
> + * Tell people we are going down, so that they can
> + * prepare to death, when device is still operating.
> + */
> + call_netdevice_notifiers(NETDEV_GOING_DOWN, dev);
Never liked the repeated notifier. It was a dumb idea, there is
no reason to believe that repeatedly whacking a notifier is going
to make device get released.
--
^ permalink raw reply
* Re: [PATCH net-next-2.6] net: add dev_close_many
From: Stephen Hemminger @ 2010-12-13 23:34 UTC (permalink / raw)
To: Octavian Purdila
Cc: Eric Dumazet, netdev, Lucian Adrian Grijincu, Vlad Dogaru
In-Reply-To: <201012132254.24267.opurdila@ixiacom.com>
On Mon, 13 Dec 2010 22:54:24 +0200
Octavian Purdila <opurdila@ixiacom.com> wrote:
> From: Stephen Hemminger <shemminger@vyatta.com>
> Date: Monday 13 December 2010, 20:04:47
>
> > I assume the need for dev_close_many is coming from a user space
> > application?
> >
> > I expect that for this kind of special need, you would be better off not
> > using the normal iproute utilities and instead have a custom device manager
> > that is doing netlink directly.
> >
> > Rather than doing synchronous send request and wait for ack. The utility
> > could use a sender and collector thread.
>
> Actually we need dev_close_many in order to speed up netdev_unregister_many
> since in the netdev_unregister_many path there is still one more sync-rcu
> operation which is not factorized.
>
> I will prepare v2 to address David's comment and I will also be more explicit
> in the commit message.
That makes sense.
--
^ permalink raw reply
* Re: [PATCH 4/5] ifb: add multiqueue support
From: Changli Gao @ 2010-12-13 23:42 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Jamal Hadi Salim, David S. Miller, netdev
In-Reply-To: <1292257573.2759.41.camel@edumazet-laptop>
On Tue, Dec 14, 2010 at 12:26 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le lundi 13 décembre 2010 à 22:43 +0800, Changli Gao a écrit :
>> Each ifb NIC has nr_cpu_ids rx queues and nr_cpu_ids queues. Packets
>> transmitted to ifb are enqueued to the corresponding per cpu tx queues,
>> and processed in the corresponding per cpu tasklet latter.
>>
>> The stats are converted to the u64 ones.
>>
>> tq is a stack variable now. It makes ifb_q_private smaller and tx queue
>> locked only once in ri_tasklet.
>>
>
> Might be good to say the tx_queue_len is multiplied by number of online
> cpus ;)
Thanks for completion.
>
>> Signed-off-by: Changli Gao <xiaosuo@gmail.com>
>> ---
>> drivers/net/ifb.c | 211 ++++++++++++++++++++++++++++++++++++------------------
>> 1 file changed, 141 insertions(+), 70 deletions(-)
>> diff --git a/drivers/net/ifb.c b/drivers/net/ifb.c
>> index 57c5cfb..16c767b 100644
>> --- a/drivers/net/ifb.c
>> +++ b/drivers/net/ifb.c
>> @@ -37,56 +37,63 @@
>> #include <net/net_namespace.h>
>>
>> #define TX_Q_LIMIT 32
>> +struct ifb_q_private {
>> + struct tasklet_struct ifb_tasklet;
>> + struct sk_buff_head rq;
>> + struct u64_stats_sync syncp;
>> + u64 rx_packets;
>> + u64 rx_bytes;
>> + u64 rx_dropped;
>> +};
>> +
>> struct ifb_private {
>> - struct tasklet_struct ifb_tasklet;
>> - int tasklet_pending;
>> - struct sk_buff_head rq;
>> - struct sk_buff_head tq;
>> + struct ifb_q_private __percpu *q;
>
> You probably could use dev->ml_priv (lstats/tstats/dstats)
> so that ifb_private just disapears (we save a full cache line)
Good idea. Thanks.
>
>> };
>>
>> static int numifbs = 2;
>>
>> -static void ri_tasklet(unsigned long dev)
>> +static void ri_tasklet(unsigned long _dev)
>> {
>> -
>> - struct net_device *_dev = (struct net_device *)dev;
>> - struct ifb_private *dp = netdev_priv(_dev);
>> - struct net_device_stats *stats = &_dev->stats;
>> + struct net_device *dev = (struct net_device *)_dev;
>> + struct ifb_private *p = netdev_priv(dev);
>> + struct ifb_q_private *qp;
>> struct netdev_queue *txq;
>> struct sk_buff *skb;
>> -
>> - txq = netdev_get_tx_queue(_dev, 0);
>> - skb = skb_peek(&dp->tq);
>> - if (skb == NULL) {
>> - if (__netif_tx_trylock(txq)) {
>> - skb_queue_splice_tail_init(&dp->rq, &dp->tq);
>> - __netif_tx_unlock(txq);
>> - } else {
>> - /* reschedule */
>> - goto resched;
>> - }
>> + struct sk_buff_head tq;
>> +
>> + __skb_queue_head_init(&tq);
>> + txq = netdev_get_tx_queue(dev, raw_smp_processor_id());
>> + qp = per_cpu_ptr(p->q, raw_smp_processor_id());
>
> qp = this_cpu_ptr(dev->ifb_qp); is faster
and less, thanks. :)
>
>> + if (!__netif_tx_trylock(txq)) {
>> + tasklet_schedule(&qp->ifb_tasklet);
>> + return;
>> }
>> + skb_queue_splice_tail_init(&qp->rq, &tq);
>> + if (netif_tx_queue_stopped(txq))
>> + netif_tx_wake_queue(txq);
>> + __netif_tx_unlock(txq);
>>
>> - while ((skb = skb_dequeue(&dp->tq)) != NULL) {
>> + while ((skb = __skb_dequeue(&tq)) != NULL) {
>> u32 from = G_TC_FROM(skb->tc_verd);
>>
>> skb->tc_verd = 0;
>> skb->tc_verd = SET_TC_NCLS(skb->tc_verd);
>> - stats->tx_packets++;
>> - stats->tx_bytes += skb->len;
>> + u64_stats_update_begin(&qp->syncp);
>> + txq->tx_packets++;
>> + txq->tx_bytes += skb->len;
>>
>> rcu_read_lock();
>> skb->dev = dev_get_by_index_rcu(&init_net, skb->skb_iif);
>> if (!skb->dev) {
>> rcu_read_unlock();
>> + txq->tx_dropped++;
>> + u64_stats_update_end(&qp->syncp);
>> dev_kfree_skb(skb);
>> - stats->tx_dropped++;
>> - if (skb_queue_len(&dp->tq) != 0)
>> - goto resched;
>> - break;
>> + continue;
>> }
>> rcu_read_unlock();
>> - skb->skb_iif = _dev->ifindex;
>> + u64_stats_update_end(&qp->syncp);
>> + skb->skb_iif = dev->ifindex;
>
> Why is this necessary ? shouldnt skb->skb_iif already be dev->ifindex ?
No. In fact, act_mirred use skb_iff to save the original dev.
skb2->skb_iif = skb->dev->ifindex;
skb2->dev = dev;
>
>>
>> if (from & AT_EGRESS) {
>> dev_queue_xmit(skb);
>> @@ -96,48 +103,32 @@ static void ri_tasklet(unsigned long dev)
>> } else
>> BUG();
>> }
>> -
>> - if (__netif_tx_trylock(txq)) {
>> - skb = skb_peek(&dp->rq);
>> - if (skb == NULL) {
>> - dp->tasklet_pending = 0;
>> - if (netif_queue_stopped(_dev))
>> - netif_wake_queue(_dev);
>> - } else {
>> - __netif_tx_unlock(txq);
>> - goto resched;
>> - }
>> - __netif_tx_unlock(txq);
>> - } else {
>> -resched:
>> - dp->tasklet_pending = 1;
>> - tasklet_schedule(&dp->ifb_tasklet);
>> - }
>> -
>> }
>>
>> static netdev_tx_t ifb_xmit(struct sk_buff *skb, struct net_device *dev)
>> {
>> - struct ifb_private *dp = netdev_priv(dev);
>> - struct net_device_stats *stats = &dev->stats;
>> + struct ifb_private *p = netdev_priv(dev);
>> + struct ifb_q_private *qp = per_cpu_ptr(p->q,
>> + skb_get_queue_mapping(skb));
>
> Would be good to add a
>
> WARN_ON(skb_get_queue_mapping(skb) != smp_processor_id());
I think it maybe what Jamal wants too. Thanks.
>
>
>> u32 from = G_TC_FROM(skb->tc_verd);
>>
>> - stats->rx_packets++;
>> - stats->rx_bytes += skb->len;
>> + u64_stats_update_begin(&qp->syncp);
>> + qp->rx_packets++;
>> + qp->rx_bytes += skb->len;
>>
>> if (!(from & (AT_INGRESS|AT_EGRESS)) || !skb->skb_iif) {
>> + qp->rx_dropped++;
>> + u64_stats_update_end(&qp->syncp);
>> dev_kfree_skb(skb);
>> - stats->rx_dropped++;
>> return NETDEV_TX_OK;
>> }
>> + u64_stats_update_end(&qp->syncp);
>>
>> - __skb_queue_tail(&dp->rq, skb);
>> - if (!dp->tasklet_pending) {
>> - dp->tasklet_pending = 1;
>> - tasklet_schedule(&dp->ifb_tasklet);
>> - }
>> + __skb_queue_tail(&qp->rq, skb);
>> + if (skb_queue_len(&qp->rq) == 1)
>> + tasklet_schedule(&qp->ifb_tasklet);
>>
>> - if (skb_queue_len(&dp->rq) >= dev->tx_queue_len)
>> + if (skb_queue_len(&qp->rq) >= dev->tx_queue_len)
>
> This seems wrong...
> You need to change to netif_tx_stop_queue(txq)
Thanks for catching this. I missed it.
>
>> netif_stop_queue(dev);
>>
>> return NETDEV_TX_OK;
>> @@ -145,33 +136,103 @@ static netdev_tx_t ifb_xmit(struct sk_buff *skb, struct net_device *dev)
>>
>> static int ifb_close(struct net_device *dev)
>> {
>> - struct ifb_private *dp = netdev_priv(dev);
>> -
>> - tasklet_kill(&dp->ifb_tasklet);
>> - netif_stop_queue(dev);
>> - __skb_queue_purge(&dp->rq);
>> - __skb_queue_purge(&dp->tq);
>> + struct ifb_private *p = netdev_priv(dev);
>> + struct ifb_q_private *qp;
>> + int cpu;
>> +
>> + for_each_possible_cpu(cpu) {
>> + qp = per_cpu_ptr(p->q, cpu);
>> + tasklet_kill(&qp->ifb_tasklet);
>> + netif_tx_stop_queue(netdev_get_tx_queue(dev, cpu));
>> + __skb_queue_purge(&qp->rq);
>> + }
>>
>> return 0;
>> }
>>
>> static int ifb_open(struct net_device *dev)
>> {
>> - struct ifb_private *dp = netdev_priv(dev);
>> + int cpu;
>> +
>
>
>
>> + for_each_possible_cpu(cpu)
>> + netif_tx_start_queue(netdev_get_tx_queue(dev, cpu));
>> +
>> + return 0;
>> +}
>> +
>> +static int ifb_init(struct net_device *dev)
>> +{
>> + struct ifb_private *p = netdev_priv(dev);
>> + struct ifb_q_private *q;
>> + int cpu;
>>
>> - tasklet_init(&dp->ifb_tasklet, ri_tasklet, (unsigned long)dev);
>> - __skb_queue_head_init(&dp->rq);
>> - __skb_queue_head_init(&dp->tq);
>> - netif_start_queue(dev);
>> + p->q = alloc_percpu(struct ifb_q_private);
>> + if (!p->q)
>> + return -ENOMEM;
>
> Hmm, maybe use netdev_queue_numa_node_write() somewhere, so that
> qdisc_alloc() can use NUMA affinities.
I'll add it, thanks.
--
Regards,
Changli Gao(xiaosuo@gmail.com)
^ permalink raw reply
* Re: [PATCH 4/5] ifb: add multiqueue support
From: Changli Gao @ 2010-12-13 23:46 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Jamal Hadi Salim, David S. Miller, netdev
In-Reply-To: <1292259931.2759.66.camel@edumazet-laptop>
On Tue, Dec 14, 2010 at 1:05 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
>
> Hmm, this wont work with CPU HOTPLUG.
>
> When we put a cpu offline, we can transfert tasklets from this cpu to
> another 'online cpu'
>
> To solve this, you need that ri_tasklet() not use a "device pointer"
> parameter but a pointer to 'cpu' private data, since it can be different
> than the data of the current cpu.
>
> static void ri_tasklet(unsigned long arg)
> {
> struct ifb_q_private *qp = (struct ifb_q_private *)arg;
>
> ...
> }
>
You are right, and it was my original way. Thanks.
--
Regards,
Changli Gao(xiaosuo@gmail.com)
^ permalink raw reply
* Re: [PATCH 5/5] net: add skb.old_queue_mapping
From: Changli Gao @ 2010-12-13 23:58 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Jamal Hadi Salim, David S. Miller, netdev
In-Reply-To: <1292259412.2759.57.camel@edumazet-laptop>
On Tue, Dec 14, 2010 at 12:56 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le lundi 13 décembre 2010 à 22:43 +0800, Changli Gao a écrit :
>> For the skbs returned from ifb, we should use the queue_mapping
>> saved before ifb.
>>
>> We save old queue_mapping in old_queue_mapping just before calling
>> dev_queue_xmit, and restore the old_queue_mapping to queue_mapping
>> just before reinjecting the skb.
>>
>> dev_pick_tx() use the current queue_mapping for the skbs reinjected
>> by ifb.
>>
>> Signed-off-by: Changli Gao <xiaosuo@gmail.com>
>> ---
>> drivers/net/ifb.c | 1 +
>> include/linux/skbuff.h | 3 +++
>> net/core/dev.c | 5 +++++
>> net/sched/act_mirred.c | 1 +
>> 4 files changed, 10 insertions(+)
>> diff --git a/drivers/net/ifb.c b/drivers/net/ifb.c
>> index 16c767b..481e4b1 100644
>> --- a/drivers/net/ifb.c
>> +++ b/drivers/net/ifb.c
>> @@ -95,6 +95,7 @@ static void ri_tasklet(unsigned long _dev)
>> u64_stats_update_end(&qp->syncp);
>> skb->skb_iif = dev->ifindex;
>>
>> + skb->queue_mapping = skb->old_queue_mapping;
>> if (from & AT_EGRESS) {
>> dev_queue_xmit(skb);
>> } else if (from & AT_INGRESS) {
>> diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
>> index 19f37a6..2ce2a96 100644
>> --- a/include/linux/skbuff.h
>> +++ b/include/linux/skbuff.h
>> @@ -403,6 +403,9 @@ struct sk_buff {
>> };
>>
>> __u16 vlan_tci;
>> +#ifdef CONFIG_NET_CLS_ACT
>> + __u16 old_queue_mapping;
>> +#endif
>>
>
> Are you sure we need this field here ? Why not using cb[] for example ?
>
skb->cb can only be used in the same layer, so we can't use it to save
a value crossing layers. A quick grep finds sch_netem just uses
skb->cb. Maybe we can put all the skb->cb in the qdisc layer and
old_queue_mapping in a structure as a new skb->cb. Is it OK? Thanks.
--
Regards,
Changli Gao(xiaosuo@gmail.com)
^ permalink raw reply
* Re: Fw: [Bug 24842] New: Compatibility issue with uggly Windows RFC1323 implementation.
From: Дмитрий Балакин @ 2010-12-14 0:35 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, Stephen Hemminger, netdev
In-Reply-To: <1292279462.2679.146.camel@edumazet-laptop>
14 декабря 2010 г. 1:31 пользователь Eric Dumazet
<eric.dumazet@gmail.com> написал:
> Le lundi 13 décembre 2010 à 23:44 +0300, Дмитрий Балакин a écrit :
>> 2010/12/13 Eric Dumazet <eric.dumazet@gmail.com>:
>> > Le lundi 13 décembre 2010 à 08:59 -0800, Stephen Hemminger a écrit :
>> >>
>> >> Begin forwarded message:
>> >>
>> >> Date: Mon, 13 Dec 2010 14:29:58 GMT
>> >> From: bugzilla-daemon@bugzilla.kernel.org
>> >> To: shemminger@linux-foundation.org
>> >> Subject: [Bug 24842] New: Compatibility issue with uggly Windows RFC1323 implementation.
>> >>
>> >>
>> >> https://bugzilla.kernel.org/show_bug.cgi?id=24842
>> >>
>> >> Summary: Compatibility issue with uggly Windows RFC1323
>> >> implementation.
>> >> Product: Networking
>> >> Version: 2.5
>> >> Kernel Version: All
>> >> Platform: All
>> >> OS/Version: Linux
>> >> Tree: Mainline
>> >> Status: NEW
>> >> Severity: normal
>> >> Priority: P1
>> >> Component: IPV4
>> >> AssignedTo: shemminger@linux-foundation.org
>> >> ReportedBy: dmitriy.balakin@nicneiron.ru
>> >> Regression: No
>> >>
>> >>
>> >> Created an attachment (id=40012)
>> >> --> (https://bugzilla.kernel.org/attachment.cgi?id=40012)
>> >> Patch
>> >>
>> >> First, sorry for my bad english.
>> >>
>> >> The issue is that Linux-based OS sometimes can't make an tcp connection to some
>> >> Windows servers with switched on buggy implementation of rfc1323, that
>> >> described on this forum:
>> >> http://www.network-builders.com/windows-tcp-timestamp-not-compliant-rfc-1323-a-t80898.html.
>> >>
>> >> Because some Windows hosts implementation of rfc1323 bases on randomly
>> >> generated TSval and sent first value of TSval as 0, the difference of recent
>> >> and new TSval sometimes has been affected by a sign magic issue and the PAWS
>> >> mechanism has been triggered. Anyway, the rfc1323 has discribes the condition
>> >> of PAWS as "0 < (t - s) < 2**31", that has been right implementation in current
>> >> linux kernel, but incompatible with Windows bug.
>> >>
>> >> For example, the one of affected to this issue Windows host is behind
>> >> relay.n-l-e.ru:80
>> >>
>> >> I think that my small patch makes the kernel more compatible with this windows
>> >> bug.
>> >>
>> >> -
>> >
>> > I have no problem connecting my linux client to relay.n-l-e.ru:80
>> >
>> > Could you elaborate please ?
>> >
>> > 18:13:12.444250 IP 10.150.51.215.51781 > 212.176.201.162.80: Flags [S],
>> > seq 665972386, win 5840, options [mss 1460,sackOK,TS val 1746885 ecr
>> > 0,nop,wscale 7], length 0
>> > 18:13:12.473912 IP 212.176.201.162.80 > 10.150.51.215.51781: Flags [S.],
>> > seq 190215045, ack 665972387, win 5792, options [mss 1460,sackOK,TS val
>> > 730697107 ecr 1746885,nop,wscale 0], length 0
>> > 18:13:12.473976 IP 10.150.51.215.51781 > 212.176.201.162.80: Flags [.],
>> > ack 1, win 46, options [nop,nop,TS val 1746888 ecr 730697107], length 0
>> > 18:13:14.984153 IP 10.150.51.215.51781 > 212.176.201.162.80: Flags [P.],
>> > seq 1:8, ack 1, win 46, options [nop,nop,TS val 1747139 ecr 730697107],
>> > length 7
>> > 18:13:15.013901 IP 212.176.201.162.80 > 10.150.51.215.51781: Flags [.],
>> > ack 8, win 5792, options [nop,nop,TS val 730697360 ecr 1747139], length
>> > 0
>> > 18:13:15.377879 IP 10.150.51.215.51781 > 212.176.201.162.80: Flags [P.],
>> > seq 8:10, ack 1, win 46, options [nop,nop,TS val 1747178 ecr 730697360],
>> > length 2
>> > 18:13:15.403900 IP 212.176.201.162.80 > 10.150.51.215.51781: Flags [.],
>> > ack 10, win 5792, options [nop,nop,TS val 730697399 ecr 1747178], length
>> > 0
>> > 18:13:15.461384 IP 212.176.201.162.80 > 10.150.51.215.51781: Flags [P.],
>> > seq 1:159, ack 10, win 5792, options [nop,nop,TS val 730697405 ecr
>> > 1747178], length 158
>> > 18:13:15.461429 IP 10.150.51.215.51781 > 212.176.201.162.80: Flags [.],
>> > ack 159, win 54, options [nop,nop,TS val 1747186 ecr 730697405], length
>> > 0
>> > 18:13:15.461448 IP 212.176.201.162.80 > 10.150.51.215.51781: Flags [F.],
>> > seq 159, ack 10, win 5792, options [nop,nop,TS val 730697405 ecr
>> > 1747178], length 0
>> > 18:13:15.461607 IP 10.150.51.215.51781 > 212.176.201.162.80: Flags [F.],
>> > seq 10, ack 160, win 54, options [nop,nop,TS val 1747186 ecr 730697405],
>> > length 0
>> > 18:13:15.533846 IP 212.176.201.162.80 > 10.150.51.215.51781: Flags [.],
>> > ack 11, win 5792, options [nop,nop,TS val 730697412 ecr 1747186], length
>> > 0
>> >
>> >
>> >
>>
>> Problems occur only when the remote side sets the TC val > 2147483647,
>> ie when there is a sign:
>>
>
> You mean a windows machine with a big uptime ?
> That must be quite rare indeed ;)
>
> Anyway, we can not test values like suggested patch, or risk a problem
> when wrap around occurs...
>
> However, testing the special ts_recent=0 case would be possible (we
> already did a change to accept a windows initiated connect to a linux
> server and still activate tcp timestamps)
>
> (commit fc1ad92dfc4e363a055 tcp: allow timestamps even if SYN packet has
> tsval=0)
>
> Something like following patch ?
>
> Thanks
>
>
> [PATCH net-next-2.6] tcp: relax tcp_paws_check()
>
> Some windows versions have wrong RFC1323 implementations, with SYN and
> SYNACKS messages containing zero tcp timestamps.
>
> We relaxed in commit fc1ad92dfc4e363 the passive connection case
> (Windows connects to a linux machine), but the reverse case (linux
> connects to a Windows machine) has an analogue problem when tsvals from
> windows machine are 'negative' (high order bit set) : PAWS triggers and
> we drops incoming messages.
>
> Fix this by making zero ts_recent value special, allowing frame to be
> processed.
>
> Based on a report and initial patch from Dmitiy Balakin
>
> Bugzilla reference : https://bugzilla.kernel.org/show_bug.cgi?id=24842
>
> Reported-by: dmitriy.balakin@nicneiron.ru
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> ---
> include/net/tcp.h | 8 +++++++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/include/net/tcp.h b/include/net/tcp.h
> index 3f227ba..2ab6c9c 100644
> --- a/include/net/tcp.h
> +++ b/include/net/tcp.h
> @@ -1038,7 +1038,13 @@ static inline int tcp_paws_check(const struct tcp_options_received *rx_opt,
> return 1;
> if (unlikely(get_seconds() >= rx_opt->ts_recent_stamp + TCP_PAWS_24DAYS))
> return 1;
> -
> + /*
> + * Some OSes send SYN and SYNACK messages with tsval=0 tsecr=0,
> + * then following tcp messages have valid values. Ignore 0 value,
> + * or else 'negative' tsval might forbid us to accept their packets.
> + */
> + if (!rx_opt->ts_recent)
> + return 1;
> return 0;
> }
>
>
>
>
In Windows uptime should be about 7 years old to sign is appear in a
TS value, it really should be quite rare. But there is such a systems,
where the TS value has nothing to do with uptime and randomly
generated for each TCP connection, such as the one referred to
earlier.
Yes, you're right, my patch breaks the PAWS. Your patch is the right way.
Thanks!
^ permalink raw reply
* [RFC PATCH net-next] if_ether.h: Add #define ETH_P_LARQ for HPNA/LARQ
From: Joe Perches @ 2010-12-14 0:47 UTC (permalink / raw)
To: netdev; +Cc: Brett Rudley, Henry Ptasinski, Dowan Kim
LARQ seems to be used by Broadcom's staging driver.
Might as well add a #define for it to the normal location.
Signed-off-by: Joe Perches <joe@perches.com>
---
include/linux/if_ether.h | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/include/linux/if_ether.h b/include/linux/if_ether.h
index f9c3df0..b257e99 100644
--- a/include/linux/if_ether.h
+++ b/include/linux/if_ether.h
@@ -71,6 +71,8 @@
#define ETH_P_PPP_SES 0x8864 /* PPPoE session messages */
#define ETH_P_MPLS_UC 0x8847 /* MPLS Unicast traffic */
#define ETH_P_MPLS_MC 0x8848 /* MPLS Multicast traffic */
+#define ETH_P_LARQ 0x886c /* HPNA / Broadcom
+ * Limited Automatic Repeat reQuest */
#define ETH_P_ATMMPOA 0x884c /* MultiProtocol Over ATM */
#define ETH_P_ATMFATE 0x8884 /* Frame-based ATM Transport
* over Ethernet
^ permalink raw reply related
* Re: [PATCH] fragment locally-generated IPsec6 packets that need it
From: Herbert Xu @ 2010-12-14 1:09 UTC (permalink / raw)
To: David L Stevens; +Cc: davem, netdev
In-Reply-To: <1292271571.8593.9.camel@w-dls.beaverton.ibm.com>
On Mon, Dec 13, 2010 at 12:19:31PM -0800, David L Stevens wrote:
> This patch modifies IPsec6 to fragment IPv6 packets that are
> locally generated as needed.
>
> Signed-off-by: David L Stevens <dlstevens@us.ibm.com>
Thanks for the patch!
> +EXPORT_SYMBOL_GPL(ip6_fragment);
There is no need to export this as xfrm6_output.c is always part
of ipv6.o.
Cheers,
--
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: [RFC PATCH net-next] if_ether.h: Add #define ETH_P_LARQ for HPNA/LARQ
From: Henry Ptasinski @ 2010-12-14 1:49 UTC (permalink / raw)
To: Joe Perches
Cc: netdev, Brett Rudley, Dowan Kim, Henry Ptasinski, arend, rvossen
In-Reply-To: <1292287667.26970.114.camel@Joe-Laptop>
On Mon, Dec 13, 2010 at 04:47:47PM -0800, Joe Perches wrote:
> LARQ seems to be used by Broadcom's staging driver.
> Might as well add a #define for it to the normal location.
>
> Signed-off-by: Joe Perches <joe@perches.com>
> ---
> include/linux/if_ether.h | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/include/linux/if_ether.h b/include/linux/if_ether.h
> index f9c3df0..b257e99 100644
> --- a/include/linux/if_ether.h
> +++ b/include/linux/if_ether.h
> @@ -71,6 +71,8 @@
> #define ETH_P_PPP_SES 0x8864 /* PPPoE session messages */
> #define ETH_P_MPLS_UC 0x8847 /* MPLS Unicast traffic */
> #define ETH_P_MPLS_MC 0x8848 /* MPLS Multicast traffic */
> +#define ETH_P_LARQ 0x886c /* HPNA / Broadcom
> + * Limited Automatic Repeat reQuest */
That should be ETH_P_BRCM (or ETH_P_EPIGRAM). HPNA/ILCP used a range of
subtypes for LARQ and other HPNA protocols. The brcmfmac driver uses a
different subypte for encapsulating some event signals between the device and
the host, but doesn't implement any of the HPNA protocols.
- Henry
^ permalink raw reply
* Re: [PATCH net-next-2.6 v9 20/20] pch_can: Replace netif_rx to netif_receive_skb
From: Tomoya MORINAGA @ 2010-12-14 2:16 UTC (permalink / raw)
To: David Miller
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, wg-5Yr1BZd7O62+XT7JhA+gdA
In-Reply-To: <20101213.122826.27813399.davem@davemloft.net>
Hi David,
Thank you for your acceptance.
> Hi Marc and Wolfgang
Until now, thank you for your much help!
---
Tomoya MORINAGA
OKI SEMICONDUCTOR CO., LTD.
----- Original Message -----
From: "David Miller" <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
To: <tomoya-linux-ECg8zkTtlr0C6LszWs/t0g@public.gmane.org>
Cc: <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>; <w.sang-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>; <chripell-VaTbYqLCNhc@public.gmane.org>;
<21cnbao-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>; <sameo-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>;
<socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org>; <netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>;
<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>; <qi.wang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>;
<yong.y.wang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>; <andrew.chih.howe.khor-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>;
<joel.clark-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>; <kok.howg.ewe-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>; <margie.foster-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Sent: Tuesday, December 14, 2010 5:28 AM
Subject: Re: [PATCH net-next-2.6 v9 20/20] pch_can: Replace netif_rx to
netif_receive_skb
> From: Tomoya MORINAGA <tomoya-linux-ECg8zkTtlr0C6LszWs/t0g@public.gmane.org>
> Date: Mon, 13 Dec 2010 15:24:26 +0900
>
>> Since this driver is implemented as NAPI,
>> netif_receive_skb must be used not netif_rx.
>>
>> Signed-off-by: Tomoya MORINAGA <tomoya-linux-ECg8zkTtlr0C6LszWs/t0g@public.gmane.org>
>> Acked-by: Marc Kleine-Budde <mkl-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
>
> Applied.
>
^ permalink raw reply
* Re: [PATCH 10/27] ixgb: Don't check for vlan group on transmit
From: Jesse Gross @ 2010-12-14 3:40 UTC (permalink / raw)
To: Tantilov, Emil S
Cc: Kirsher, Jeffrey T, davem@davemloft.net, netdev@vger.kernel.org,
gospo@redhat.com, bphilips@novell.com
In-Reply-To: <EA929A9653AAE14F841771FB1DE5A136602D607104@rrsmsx501.amr.corp.intel.com>
On Mon, Dec 13, 2010 at 10:43 AM, Tantilov, Emil S
<emil.s.tantilov@intel.com> wrote:
>>-----Original Message-----
>>From: Jesse Gross [mailto:jesse@nicira.com]
>>Sent: Sunday, December 12, 2010 5:01 PM
>>To: Kirsher, Jeffrey T
>>Cc: davem@davemloft.net; Tantilov, Emil S; netdev@vger.kernel.org;
>>gospo@redhat.com; bphilips@novell.com
>>Subject: Re: [PATCH 10/27] ixgb: Don't check for vlan group on transmit
>>
>>On Fri, Dec 10, 2010 at 10:17 PM, Jeff Kirsher
>><jeffrey.t.kirsher@intel.com> wrote:
>>> From: Emil Tantilov <emil.s.tantilov@intel.com>
>>>
>>> Based on a patch from Jesse Gross.
>>>
>>> Enable vlan tag insertion even when vlan group is not configured.
>>>
>>> For ixgb HW both CTRL0.VME and VLE bit in the Tx descriptor need to be
>>set
>>> in order to enable HW acceleration.
>>>
>>> Introduced separate functions for enabling/disabling of vlan tag
>>stripping
>>> similar to ixgbe.
>>
>>Thanks for working on this. However, I don't think that this patch
>>actually does what it says.
>>
>>In ixgb_xmit_frame() it's still checking whether adapter->vlgrp is
>>non-null before inserting a tag, so it will drop tags unless a vlan
>>group is configured. Also, since it's not currently possible to
>>toggle NETIF_F_HW_VLAN_RX, vlan stripping will never get disabled.
>>This is actually a regression since before vlan stripping would get
>>disabled if no vlan group was configured. Now, vlan headers will get
>>silently dropped if there is no vlan group.
> I'm sorry. This patch was supposed to include your original patch that
> removed the vlgrp check on Tx. Somehow that didn't make it (I may have generated the patch from the wrong branch).
>
>>Regardless of that, I still think this is a useful change on the road
>>towards adopting the new vlan interfaces, the problem is just that
>>currently it's halfway in between the old and the new. Given that, it
>>would obviously be much better to move all the way over the new when
>>addressing this.
> Since this patch is already applied can you submit your change again?
Sure. I think it's probably best to just complete the conversion to
the new vlan interfaces, so I went ahead and did that. It's much
easier now that you've pulled the hardware specific bits out for
enabling/disabling vlan offloading. I'll send out that patch shortly
- please take a look since I don't have the hardware to test it.
>
>>Out of curiosity, is the implication of this that vlan insertion on
>>transmit and stripping on receive are always configured together? I
>>don't have hardware supported by this driver but when I worked on
>>ixgbe (which is at least superficially similar in this area) I didn't
>>have any problems configuring them independently.
>
> Yes - the design of the original 10GB HW supported in ixgb does not allow
> setting Tx and Rx independently. As you mentioned ixgbe does not have
> this problem.
OK, thanks for the explanation.
^ permalink raw reply
* [PATCH] ixgb: Convert to new vlan model.
From: Jesse Gross @ 2010-12-14 3:42 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Emil Tantilov, Jeff Kirsher, Alex Duyck
This switches the ixgb driver to use the new vlan interfaces.
In doing this, it completes the work begun in
ae54496f9e8d40c89e5668205c181dccfa9ecda1 allowing the use of
hardware vlan insertion without having a vlan group configured.
Signed-off-by: Jesse Gross <jesse@nicira.com>
CC: Emil Tantilov <emil.s.tantilov@intel.com>
CC: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
CC: Alex Duyck <alexander.h.duyck@intel.com>
---
drivers/net/ixgb/ixgb.h | 2 +-
drivers/net/ixgb/ixgb_ethtool.c | 41 +++++++++++++++++++++++++++++
drivers/net/ixgb/ixgb_main.c | 54 ++++++++------------------------------
3 files changed, 54 insertions(+), 43 deletions(-)
diff --git a/drivers/net/ixgb/ixgb.h b/drivers/net/ixgb/ixgb.h
index 521c0c7..8f3df04 100644
--- a/drivers/net/ixgb/ixgb.h
+++ b/drivers/net/ixgb/ixgb.h
@@ -149,7 +149,7 @@ struct ixgb_desc_ring {
struct ixgb_adapter {
struct timer_list watchdog_timer;
- struct vlan_group *vlgrp;
+ unsigned long active_vlans[BITS_TO_LONGS(VLAN_N_VID)];
u32 bd_number;
u32 rx_buffer_len;
u32 part_num;
diff --git a/drivers/net/ixgb/ixgb_ethtool.c b/drivers/net/ixgb/ixgb_ethtool.c
index 43994c1..0e4c527 100644
--- a/drivers/net/ixgb/ixgb_ethtool.c
+++ b/drivers/net/ixgb/ixgb_ethtool.c
@@ -706,6 +706,45 @@ ixgb_get_strings(struct net_device *netdev, u32 stringset, u8 *data)
}
}
+static int ixgb_set_flags(struct net_device *netdev, u32 data)
+{
+ struct ixgb_adapter *adapter = netdev_priv(netdev);
+ bool need_reset;
+ int rc;
+
+ /* The hardware requires that RX vlan stripping and TX vlan insertion
+ * be configured together. Therefore, if one setting changes adjust the
+ * other one to match.
+ */
+ if (!!(data & ETH_FLAG_RXVLAN) != !!(data & ETH_FLAG_TXVLAN)) {
+ if ((data & ETH_FLAG_RXVLAN) !=
+ (netdev->features & NETIF_F_HW_VLAN_RX))
+ data ^= ETH_FLAG_TXVLAN;
+ else if ((data & ETH_FLAG_TXVLAN) !=
+ (netdev->features & NETIF_F_HW_VLAN_TX))
+ data ^= ETH_FLAG_RXVLAN;
+ }
+
+ need_reset = (data & ETH_FLAG_RXVLAN) !=
+ (netdev->features & NETIF_F_HW_VLAN_RX);
+
+ rc = ethtool_op_set_flags(netdev, data, ETH_FLAG_RXVLAN |
+ ETH_FLAG_TXVLAN);
+ if (rc)
+ return rc;
+
+ if (need_reset) {
+ if (netif_running(netdev)) {
+ ixgb_down(adapter, true);
+ ixgb_up(adapter);
+ ixgb_set_speed_duplex(netdev);
+ } else
+ ixgb_reset(adapter);
+ }
+
+ return 0;
+}
+
static const struct ethtool_ops ixgb_ethtool_ops = {
.get_settings = ixgb_get_settings,
.set_settings = ixgb_set_settings,
@@ -732,6 +771,8 @@ static const struct ethtool_ops ixgb_ethtool_ops = {
.phys_id = ixgb_phys_id,
.get_sset_count = ixgb_get_sset_count,
.get_ethtool_stats = ixgb_get_ethtool_stats,
+ .get_flags = ethtool_op_get_flags,
+ .set_flags = ixgb_set_flags,
};
void ixgb_set_ethtool_ops(struct net_device *netdev)
diff --git a/drivers/net/ixgb/ixgb_main.c b/drivers/net/ixgb/ixgb_main.c
index b021798..053ae02 100644
--- a/drivers/net/ixgb/ixgb_main.c
+++ b/drivers/net/ixgb/ixgb_main.c
@@ -100,8 +100,6 @@ static void ixgb_tx_timeout_task(struct work_struct *work);
static void ixgb_vlan_strip_enable(struct ixgb_adapter *adapter);
static void ixgb_vlan_strip_disable(struct ixgb_adapter *adapter);
-static void ixgb_vlan_rx_register(struct net_device *netdev,
- struct vlan_group *grp);
static void ixgb_vlan_rx_add_vid(struct net_device *netdev, u16 vid);
static void ixgb_vlan_rx_kill_vid(struct net_device *netdev, u16 vid);
static void ixgb_restore_vlan(struct ixgb_adapter *adapter);
@@ -336,7 +334,6 @@ static const struct net_device_ops ixgb_netdev_ops = {
.ndo_set_mac_address = ixgb_set_mac,
.ndo_change_mtu = ixgb_change_mtu,
.ndo_tx_timeout = ixgb_tx_timeout,
- .ndo_vlan_rx_register = ixgb_vlan_rx_register,
.ndo_vlan_rx_add_vid = ixgb_vlan_rx_add_vid,
.ndo_vlan_rx_kill_vid = ixgb_vlan_rx_kill_vid,
#ifdef CONFIG_NET_POLL_CONTROLLER
@@ -1508,7 +1505,7 @@ ixgb_xmit_frame(struct sk_buff *skb, struct net_device *netdev)
DESC_NEEDED)))
return NETDEV_TX_BUSY;
- if (adapter->vlgrp && vlan_tx_tag_present(skb)) {
+ if (vlan_tx_tag_present(skb)) {
tx_flags |= IXGB_TX_FLAGS_VLAN;
vlan_id = vlan_tx_tag_get(skb);
}
@@ -2049,12 +2046,11 @@ ixgb_clean_rx_irq(struct ixgb_adapter *adapter, int *work_done, int work_to_do)
ixgb_rx_checksum(adapter, rx_desc, skb);
skb->protocol = eth_type_trans(skb, netdev);
- if (adapter->vlgrp && (status & IXGB_RX_DESC_STATUS_VP)) {
- vlan_hwaccel_receive_skb(skb, adapter->vlgrp,
- le16_to_cpu(rx_desc->special));
- } else {
- netif_receive_skb(skb);
- }
+ if (status & IXGB_RX_DESC_STATUS_VP)
+ __vlan_hwaccel_put_tag(skb,
+ le16_to_cpu(rx_desc->special));
+
+ netif_receive_skb(skb);
rxdesc_done:
/* clean up descriptor, might be written over by hw */
@@ -2152,20 +2148,6 @@ map_skb:
}
}
-/**
- * ixgb_vlan_rx_register - enables or disables vlan tagging/stripping.
- *
- * @param netdev network interface device structure
- * @param grp indicates to enable or disable tagging/stripping
- **/
-static void
-ixgb_vlan_rx_register(struct net_device *netdev, struct vlan_group *grp)
-{
- struct ixgb_adapter *adapter = netdev_priv(netdev);
-
- adapter->vlgrp = grp;
-}
-
static void
ixgb_vlan_strip_enable(struct ixgb_adapter *adapter)
{
@@ -2200,6 +2182,7 @@ ixgb_vlan_rx_add_vid(struct net_device *netdev, u16 vid)
vfta = IXGB_READ_REG_ARRAY(&adapter->hw, VFTA, index);
vfta |= (1 << (vid & 0x1F));
ixgb_write_vfta(&adapter->hw, index, vfta);
+ set_bit(vid, adapter->active_vlans);
}
static void
@@ -2208,35 +2191,22 @@ ixgb_vlan_rx_kill_vid(struct net_device *netdev, u16 vid)
struct ixgb_adapter *adapter = netdev_priv(netdev);
u32 vfta, index;
- ixgb_irq_disable(adapter);
-
- vlan_group_set_device(adapter->vlgrp, vid, NULL);
-
- /* don't enable interrupts unless we are UP */
- if (adapter->netdev->flags & IFF_UP)
- ixgb_irq_enable(adapter);
-
/* remove VID from filter table */
index = (vid >> 5) & 0x7F;
vfta = IXGB_READ_REG_ARRAY(&adapter->hw, VFTA, index);
vfta &= ~(1 << (vid & 0x1F));
ixgb_write_vfta(&adapter->hw, index, vfta);
+ clear_bit(vid, adapter->active_vlans);
}
static void
ixgb_restore_vlan(struct ixgb_adapter *adapter)
{
- ixgb_vlan_rx_register(adapter->netdev, adapter->vlgrp);
-
- if (adapter->vlgrp) {
- u16 vid;
- for (vid = 0; vid < VLAN_N_VID; vid++) {
- if (!vlan_group_get_device(adapter->vlgrp, vid))
- continue;
- ixgb_vlan_rx_add_vid(adapter->netdev, vid);
- }
- }
+ u16 vid;
+
+ for_each_set_bit(vid, adapter->active_vlans, VLAN_N_VID)
+ ixgb_vlan_rx_add_vid(adapter->netdev, vid);
}
#ifdef CONFIG_NET_POLL_CONTROLLER
--
1.7.1
^ permalink raw reply related
* Re: [PATCH net-next-2.6 v9 20/20] pch_can: Replace netif_rx to netif_receive_skb
From: David Miller @ 2010-12-14 3:45 UTC (permalink / raw)
To: socketcan; +Cc: tomoya-linux, netdev, mkl, wg
In-Reply-To: <4D069564.8070204@hartkopp.net>
From: Oliver Hartkopp <socketcan@hartkopp.net>
Date: Mon, 13 Dec 2010 22:51:32 +0100
> On 13.12.2010 21:28, David Miller wrote:
>> From: Tomoya MORINAGA <tomoya-linux@dsn.okisemi.com>
>> Date: Mon, 13 Dec 2010 15:24:26 +0900
>>
>>> Since this driver is implemented as NAPI,
>>> netif_receive_skb must be used not netif_rx.
>>>
>>> Signed-off-by: Tomoya MORINAGA <tomoya-linux@dsn.okisemi.com>
>>> Acked-by: Marc Kleine-Budde <mkl@pengutronix.de>
>>
>> Applied.
>
> Do you plan to push this huge patchset to Linus' 2.6.37-rc5 tree?
>
> I wonder if the pch_can driver in linux-2.6 tree is already usable without
> these latest patches that have been applied only to net-next-2.6.
I'm happy to take the changes for a backport once all of this settles
down which I don't believe it has yet.
^ permalink raw reply
* Re: [RFC PATCH net-next] if_ether.h: Add #define ETH_P_LARQ for HPNA/LARQ
From: Joe Perches @ 2010-12-14 3:53 UTC (permalink / raw)
To: Henry Ptasinski; +Cc: netdev, Brett Rudley, Dowan Kim, arend, rvossen
In-Reply-To: <20101214014920.GA2453@broadcom.com>
On Mon, 2010-12-13 at 17:49 -0800, Henry Ptasinski wrote:
> On Mon, Dec 13, 2010 at 04:47:47PM -0800, Joe Perches wrote:
> > LARQ seems to be used by Broadcom's staging driver.
> > Might as well add a #define for it to the normal location.
> > diff --git a/include/linux/if_ether.h b/include/linux/if_ether.h
[]
> > +#define ETH_P_LARQ 0x886c /* HPNA / Broadcom
> That should be ETH_P_BRCM (or ETH_P_EPIGRAM). HPNA/ILCP used a range of
> subtypes for LARQ and other HPNA protocols. The brcmfmac driver uses a
> different subypte for encapsulating some event signals between the device and
> the host, but doesn't implement any of the HPNA protocols.
Another choice might be ETH_P_LINK_CTL
^ permalink raw reply
* Re: [PATCH 2.6.36] vlan: Avoid hwaccel vlan packets when vid not used
From: Jesse Gross @ 2010-12-14 4:07 UTC (permalink / raw)
To: Matt Carlson
Cc: Michael Leun, Michael Chan, Eric Dumazet, David Miller,
Ben Greear, linux-kernel@vger.kernel.org, netdev@vger.kernel.org
In-Reply-To: <20101213224510.GB17400@mcarlson.broadcom.com>
On Mon, Dec 13, 2010 at 2:45 PM, Matt Carlson <mcarlson@broadcom.com> wrote:
> On Sun, Dec 12, 2010 at 04:11:13PM -0800, Jesse Gross wrote:
>> On Mon, Dec 6, 2010 at 1:27 PM, Michael Leun
>> <lkml20101129@newton.leun.net> wrote:
>> > On Mon, 6 Dec 2010 12:04:48 -0800
>> > Jesse Gross <jesse@nicira.com> wrote:
>> >
>> >> On Mon, Dec 6, 2010 at 11:34 AM, Michael Leun
>> >> <lkml20101129@newton.leun.net> wrote:
>> >> > On Mon, 6 Dec 2010 10:14:55 -0800
>> >> > Jesse Gross <jesse@nicira.com> wrote:
>> >> >
>> >> >> On Sun, Dec 5, 2010 at 2:44 AM, Michael Leun
>> >> >> <lkml20101129@newton.leun.net> wrote:
>> >> >> > Hi Jesse,
>> >> >> >
>> >> >> > On Sun, 5 Dec 2010 10:55:28 +0100
>> >> >> > Michael Leun <lkml20101129@newton.leun.net> wrote:
>> >> >> >
>> >> >> >> On Sun, 05 Dec 2010 09:03:53 +0100
>> >> >> >> Eric Dumazet <eric.dumazet@gmail.com> wrote:
>> >> >> >>
>> >> >> >> > > But on
>> >> >> >> > >
>> >> >> >> > > hpdl320g5:/home/ml # lspci | grep Eth
>> >> >> >> > > 03:04.0 Ethernet controller: Broadcom Corporation NetXtreme
>> >> >> >> > > BCM5714 Gigabit Ethernet (rev a3) 03:04.1 Ethernet
>> >> >> >> > > controller: Broadcom Corporation NetXtreme BCM5714 Gigabit
>> >> >> >> > > Ethernet (rev a3)
>> >> >> >> > >
>> >> >> >> > > the good message is that it also does not crash, but with
>> >> >> >> > > tcpdump I see vlan tags when no vlan devices configured on
>> >> >> >> > > the respective eth, if so I do not see tags anymore vlan
>> >> >> >> > > tags on the trunk interface.
>> >> >> >> > >
>> >> >> >> >
>> >> >> >> > For all these very specific needs, you'll have to try 2.6.37
>> >> >> >> > I am afraid. Jesse did huge changes to exactly make this
>> >> >> >> > working, we wont backport this to 2.6.36, but only avoid
>> >> >> >> > crashes.
>> >> >> >>
>> >> >> >> OK, I'm perfectly fine with that, of course, actually nice to
>> >> >> >> hear that the issue already is addressed.
>> >> >> >>
>> >> >> >> Likely I'll give some rc an shot on this machine (maybe over
>> >> >> >> christmas), but it is an production machine (acutally testing
>> >> >> >> other devices is the "product" produced on this machine), so
>> >> >> >> unfortunately I'm not that free in when and what I can do (but
>> >> >> >> the possibility to, for example, bridge the trunk interface
>> >> >> >> would make testing easier, that justifies something...).
>> >> >> >>
>> >> >> >> Thank you all very much for your work.
>> >> >> >
>> >> >> > Are these changes already in 2.6.37-rc4? Or, if not are they
>> >> >> > somewhere publically available already?
>> >> >> >
>> >> >> > I looked into various changelogs but have some difficulties to
>> >> >> > identify them...
>> >> >> >
>> >> >> > Maybe I have some time next days to give them an try...
>> >> >>
>> >> >> Yes, all of the existing vlan changes are in 2.6.37-rc4. ?There
>> >> >> were a number of patches but the main one was
>> >> >> 3701e51382a026cba10c60b03efabe534fba4ca4
>> >> >
>> >> > Then, I'm afraid, this (seeing vlan tags even if vlan interfaces are
>> >> > configured) does not work on HP DL320G5 (for exact description and
>> >> > examples please see my mail a few days ago).
>> >>
>> >> What driver are you using? ?Is it tg3?
>> >>
>> >> The vlan changes that I made unfortunately require updating drivers to
>> >> get the full benefit. ?I've been busy lately so tg3 hasn't yet been
>> >> updated.
>> >>
>> >> I know that tg3 does some things differently depending on whether a
>> >> vlan group is configured, so that would likely be the cause of what
>> >> you are seeing. ?I'd have to look at it in more detail to be sure
>> >> though.
>> >>
>> >> You said that everything works on the other Broadcom NIC that you
>> >> tested? ?Maybe it uses bnx2 instead?
>> >>
>> >
>> > Both machines use tg3 / 2.6.36.1 - one is opensuse, one ubuntu (but
>> > this should not matter, I think).
>> >
>> > If I can do anything to support your investigations / work (most
>> > likely testing / providing information) please let me know.
>>
>> Unfortunately, I probably won't have time to look at this in the near
>> future. Given that the test works on one NIC but not another that
>> strongly suggests that it is a driver problem, even if both NICs use
>> the same driver. I see tg3 can do different things with vlans
>> depending on the model and what features are enabled. I also ran a
>> quick test on some of my machines and I didn't experience this issue.
>> They are running net-next with ixgbe.
>>
>> One of the main goals of my general vlan changes was to remove as much
>> logic as possible from the drivers and put it in the networking core,
>> so we should in theory see consistent behavior. However, in 2.6.36
>> and earlier, each driver knows about what vlan devices are configured
>> and does different things with that information.
>>
>> Given all of that, the most logical step to me is simply to convert
>> tg3 to use the new vlan infrastructure. It should be done regardless
>> and it will probably solve this problem. Maybe you can convince the
>> Broadcom guys to do that? It would be a lot faster for them to do it
>> than me.
>
> Below is the patch that converts the tg3 driver over to the new API. I
> don't see how it could fix the problem though. Maybe the presence of
> NETIF_F_HW_VLAN_TX changes things.
Thanks Matt.
There's actually a little bit more that needs to be done for
conversion. All references to the vlan group should be gone since
that logic has been moved to the networking core.
tg3_vlan_rx_register() completely disappears and all other code
contained in TG3_VLAN_TAG_USED is unconditionally active. Ideally,
there would be an Ethtool set_flags function so that the vlan
offloading features could be enabled/disabled for situations like this
to help with debugging.
The reason why I think that this might help is that the problem
manifests when a vlan group is configured, even if that vlan isn't
used. Since this removes all logic about vlan groups from the driver,
it should avoid any problems in that area. It's possible that the
actual issue is somewhere else but then it should be easier to find
since we can separate out the different components.
^ permalink raw reply
* Re: [GIT PULL net-next-2.6] vhost-net: tools, cleanups, optimizations
From: Rusty Russell @ 2010-12-14 5:48 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: David Miller, kvm, virtualization, netdev, linux-kernel
In-Reply-To: <20101213172447.GA8560@redhat.com>
On Tue, 14 Dec 2010 03:54:47 am Michael S. Tsirkin wrote:
> On Mon, Dec 13, 2010 at 12:44:13PM +0200, Michael S. Tsirkin wrote:
> > Please merge the following tree for 2.6.38.
> > Thanks!
>
> Um, I sent this out before I noticed the mail from Rusty
> with some questions on the test code. I missed that and
> assumed no comments -> no issues, perhaps wrongly.
>
> Rusty - I tried answering the questions there - any issues
> with merging this? It's just a test so won't be hard to remove
> later if it's not helpful ...
Traditionally this stuff has not gone in tree. However, I think it
should be...
Rusty.
^ permalink raw reply
* Re: [*v2 PATCH 08/22] IPVS: netns preparation for proto_sctp
From: Hans Schillstrom @ 2010-12-14 6:27 UTC (permalink / raw)
To: Simon Horman
Cc: Hans Schillstrom, ja, daniel.lezcano, wensong, lvs-devel, netdev,
netfilter-devel
In-Reply-To: <20101213222300.GK3221@verge.net.au>
On Monday, December 13, 2010 23:23:01 Simon Horman wrote:
> On Mon, Dec 13, 2010 at 02:38:16PM +0100, Hans Schillstrom wrote:
> > In this phase (one), all local vars will be moved to ipvs struct.
> >
> > Remaining work, add param struct net *net to a couple of
> > functions that is common for all protos and use ip_vs_proto_data
> >
> > Signed-off-by: Hans Schillstrom <hans.schillstrom@ericsson.com>
>
> [ snip ]
>
> > diff --git a/net/netfilter/ipvs/ip_vs_proto_sctp.c b/net/netfilter/ipvs/ip_vs_proto_sctp.c
> > index 521b827..108ae0c 100644
> > --- a/net/netfilter/ipvs/ip_vs_proto_sctp.c
> > +++ b/net/netfilter/ipvs/ip_vs_proto_sctp.c
>
> [ snip ]
>
> > @@ -1101,43 +1098,51 @@ static int sctp_app_conn_bind(struct ip_vs_conn *cp)
> > goto out;
> > }
> > }
> > - spin_unlock(&sctp_app_lock);
> > + spin_unlock(&ipvs->sctp_app_lock);
> > out:
> > return result;
> > }
> >
> > -static void ip_vs_sctp_init(struct ip_vs_protocol *pp)
> > +/* ---------------------------------------------
> > + * timeouts is netns related now.
> > + * ---------------------------------------------
> > + */
> > +static void __ip_vs_sctp_init(struct net *net, struct ip_vs_proto_data *pd)
> > {
> > - IP_VS_INIT_HASH_TABLE(sctp_apps);
> > - pp->timeout_table = sctp_timeouts;
> > -}
> > + struct netns_ipvs *ipvs = net_ipvs(net);
> >
> > + ip_vs_init_hash_table(ipvs->sctp_apps, SCTP_APP_TAB_SIZE);
> > + spin_lock_init(&ipvs->tcp_app_lock);
> > + pd->timeout_table = ip_vs_create_timeout_table((int*)sctp_timeouts,
> > + sizeof(sctp_timeouts));
> > +}
> >
> > -static void ip_vs_sctp_exit(struct ip_vs_protocol *pp)
> > +static void __ip_vs_sctp_exit(struct net *net, struct ip_vs_proto_data *pd)
> > {
> > -
> > + kfree(pd->timeout_table);
> > }
> >
> > struct ip_vs_protocol ip_vs_protocol_sctp = {
> > - .name = "SCTP",
> > - .protocol = IPPROTO_SCTP,
> > - .num_states = IP_VS_SCTP_S_LAST,
> > - .dont_defrag = 0,
> > - .appcnt = ATOMIC_INIT(0),
> > - .init = ip_vs_sctp_init,
> > - .exit = ip_vs_sctp_exit,
init & exit changed to NULL
> > - .register_app = sctp_register_app,
> > + .name = "SCTP",
> > + .protocol = IPPROTO_SCTP,
> > + .num_states = IP_VS_SCTP_S_LAST,
> > + .dont_defrag = 0,
> > + .init = NULL,
> > + .exit = NULL,
> > + .init_netns = __ip_vs_sctp_init,
> > + .exit_netns = __ip_vs_sctp_exit,
init_netns and exit_netns added
> > + .register_app = sctp_register_app,
> > .unregister_app = sctp_unregister_app,
> > - .conn_schedule = sctp_conn_schedule,
> > - .conn_in_get = ip_vs_conn_in_get_proto,
> > - .conn_out_get = ip_vs_conn_out_get_proto,
> > - .snat_handler = sctp_snat_handler,
> > - .dnat_handler = sctp_dnat_handler,
> > - .csum_check = sctp_csum_check,
> > - .state_name = sctp_state_name,
> > + .conn_schedule = sctp_conn_schedule,
> > + .conn_in_get = ip_vs_conn_in_get_proto,
> > + .conn_out_get = ip_vs_conn_out_get_proto,
> > + .snat_handler = sctp_snat_handler,
> > + .dnat_handler = sctp_dnat_handler,
> > + .csum_check = sctp_csum_check,
> > + .state_name = sctp_state_name,
> > .state_transition = sctp_state_transition,
> > - .app_conn_bind = sctp_app_conn_bind,
> > - .debug_packet = ip_vs_tcpudp_debug_packet,
> > - .timeout_change = sctp_timeout_change,
> > - .set_state_timeout = sctp_set_state_timeout,
> > + .app_conn_bind = sctp_app_conn_bind,
> > + .debug_packet = ip_vs_tcpudp_debug_packet,
> > + .timeout_change = NULL,
> > +/* .set_state_timeout = sctp_set_state_timeout, */
set_state_timout removed or comment-out
> > };
>
> While I'm not a big fan or the original formatting,
> the whitespace changes above make it rather difficult to see
> what is really being changed. Could you either drop
> the whitespace changes or move them into a separate patch?
I do agree that the changes is hard to see,
It's the same changes that's in tcp and udp.
I don't think it's worth the effort to make a new patch just for that,
but if you still insists ...
^ permalink raw reply
* Re: [*v2 PATCH 06/22] IPVS: netns preparation for proto_tcp
From: Hans Schillstrom @ 2010-12-14 6:42 UTC (permalink / raw)
To: Simon Horman
Cc: Hans Schillstrom, ja, daniel.lezcano, wensong, lvs-devel, netdev,
netfilter-devel
In-Reply-To: <20101213221831.GI3221@verge.net.au>
--
Mvh
Hasse Schillstrom
070-699 7150
On Monday, December 13, 2010 23:18:32 Simon Horman wrote:
> Hi Hans,
>
> I'm not all the way through yet but this series is looking good.
> Some minor nits below.
>
> On Mon, Dec 13, 2010 at 02:38:14PM +0100, Hans Schillstrom wrote:
> > In this phase (one), all local vars will be moved to ipvs struct.
> >
> > Remaining work, add param struct net *net to a couple of
> > functions that is common for all protos and use all
> > ip_vs_proto_data
> >
> > Signed-off-by: Hans Schillstrom <hans.schillstrom@ericsson.com>
> > ---
> > include/net/ip_vs.h | 7 ++-
> > include/net/netns/ip_vs.h | 8 +++
> > net/netfilter/ipvs/ip_vs_ftp.c | 9 ++-
> > net/netfilter/ipvs/ip_vs_proto.c | 13 ++++-
> > net/netfilter/ipvs/ip_vs_proto_tcp.c | 99 +++++++++++++++++++--------------
> > 5 files changed, 87 insertions(+), 49 deletions(-)
> >
> > diff --git a/include/net/ip_vs.h b/include/net/ip_vs.h
> > index 528c5e8..3765add 100644
> > --- a/include/net/ip_vs.h
> > +++ b/include/net/ip_vs.h
> > @@ -40,11 +40,12 @@ static inline struct netns_ipvs * net_ipvs(struct net* net) {
> > return init_net.ipvs;
> > #endif
> > }
> > +
>
> This blank line change is spurious here.
> There seem to be other cases of blank lines being
> spuriously added and removed in this patch set.
> They tend to just add noise.
>
Yes, but in this case it's a blank line that separate two blocks.
> > /*
> > * Get net ptr from skb in traffic cases
> > * use skb_sknet when call is from userland (ioctl or netlink)
> > */
> > -static inline struct net *skb_net(struct sk_buff *skb) {
> > +static inline struct net *skb_net(const struct sk_buff *skb) {
> > #ifdef CONFIG_NET_NS
> > #ifdef CONFIG_IP_VS_DEBUG
> > /*
>
> [ snip ]
>
> > diff --git a/include/net/netns/ip_vs.h b/include/net/netns/ip_vs.h
> > index b7d7815..512cdd0 100644
> > --- a/include/net/netns/ip_vs.h
> > +++ b/include/net/netns/ip_vs.h
> > @@ -32,6 +32,14 @@ struct netns_ipvs {
> > /* ip_vs_proto */
> > #define IP_VS_PROTO_TAB_SIZE 32 /* must be power of 2 */
> > struct ip_vs_proto_data *proto_data_table[IP_VS_PROTO_TAB_SIZE];
> > + /* ip_vs_proto_tcp */
> > +#ifdef CONFIG_IP_VS_PROTO_TCP
> > + #define TCP_APP_TAB_BITS 4
> > + #define TCP_APP_TAB_SIZE (1 << TCP_APP_TAB_BITS)
> > + #define TCP_APP_TAB_MASK (TCP_APP_TAB_SIZE - 1)
> > + struct list_head tcp_apps[TCP_APP_TAB_SIZE];
>
> There is a space (not tab) after head.
>
> > + spinlock_t tcp_app_lock;
> > +#endif
> >
> > /* ip_vs_lblc */
> > int sysctl_lblc_expiration;
> > diff --git a/net/netfilter/ipvs/ip_vs_proto_tcp.c b/net/netfilter/ipvs/ip_vs_proto_tcp.c
> > index 5e4da60..8986b25 100644
> > --- a/net/netfilter/ipvs/ip_vs_proto_tcp.c
> > +++ b/net/netfilter/ipvs/ip_vs_proto_tcp.c
>
> [ snip ]
>
> > @@ -459,13 +463,13 @@ static void tcp_timeout_change(struct ip_vs_protocol *pp, int flags)
> > */
> > tcp_state_table = (on? tcp_states_dos : tcp_states);
> > }
> > -
> > +/* Remove dot used
> > static int
> > tcp_set_state_timeout(struct ip_vs_protocol *pp, char *sname, int to)
> > {
> > return ip_vs_set_state_timeout(pp->timeout_table, IP_VS_TCP_S_LAST,
> > tcp_state_name_table, sname, to);
> > -}
> > +} */
>
> Can we just remove tcp_set_state_timeout ?
Sure, anyone that disagree ?
>
> [ snip ]
>
> > @@ -699,8 +712,10 @@ struct ip_vs_protocol ip_vs_protocol_tcp = {
> > .num_states = IP_VS_TCP_S_LAST,
> > .dont_defrag = 0,
> > .appcnt = ATOMIC_INIT(0),
> > - .init = ip_vs_tcp_init,
> > - .exit = ip_vs_tcp_exit,
> > + .init = NULL,
> > + .exit = NULL,
> > + .init_netns = __ip_vs_tcp_init,
> > + .exit_netns = __ip_vs_tcp_exit,
> > .register_app = tcp_register_app,
> > .unregister_app = tcp_unregister_app,
> > .conn_schedule = tcp_conn_schedule,
> > @@ -714,5 +729,5 @@ struct ip_vs_protocol ip_vs_protocol_tcp = {
> > .app_conn_bind = tcp_app_conn_bind,
> > .debug_packet = ip_vs_tcpudp_debug_packet,
> > .timeout_change = tcp_timeout_change,
> > - .set_state_timeout = tcp_set_state_timeout,
> > +/* .set_state_timeout = tcp_set_state_timeout, */
> > };
>
> Can this the commented-out line just be removed?
^ permalink raw reply
* question on ebtables and iptables, relating to conntrack-zones
From: Ben Greear @ 2010-12-14 7:01 UTC (permalink / raw)
To: NetDev
I'm trying to do something a bit weird with two bridges and a transparent
squid proxy.
I think I want the network diagram to look a bit like:
{ internet } -- eth0 - br0 - veth2 - veth1 - br1 - eth1 -- { client-side network }
The idea is to have br1 act just as a bridge, but have br0 have an IP and
do the squid re-direct logic. This is because I need to see packets from clients
to squid on the two br1 ports, as if squid were somewhere in the {internet}.
I was thinking that setting br1 and it's ports to one conntrack zone
and br0 and it's ports to another would do the trick, but when I do
add those, the squid redirect nat seems to break. I am thinking now
that maybe I'd need to implement conntrack zones for ebtables BROUTING, perhaps?
My current attempted setup file looks like:
#!/bin/bash
# Clean up any old rules.
/etc/init.d/stopbrouting
/sbin/ebtables -t broute -A BROUTING -i br0 -p IPv4 --ip-protocol 6 --ip-destination-port 80 -j redirect --redirect-target ACCEPT
/sbin/iptables -t nat -A PREROUTING -i br0 -p tcp --dport 80 -j REDIRECT --to-port 3128
echo 0 > /proc/sys/net/bridge/bridge-nf-call-arptables
echo 0 > /proc/sys/net/bridge/bridge-nf-call-ip6tables
echo 1 > /sys/class/net/br0/bridge/nf_call_ip6tables
echo 1 > /sys/class/net/br0/bridge/nf_call_iptables
/usr/local/sbin/iptables -t raw -A PREROUTING -i eth1 -j CT --zone 2
/usr/local/sbin/iptables -t raw -A PREROUTING -i veth1 -j CT --zone 2
/usr/local/sbin/iptables -t raw -A PREROUTING -i br1 -j CT --zone 2
/usr/local/sbin/iptables -t raw -A PREROUTING -i eth0 -j CT --zone 3
/usr/local/sbin/iptables -t raw -A PREROUTING -i veth2 -j CT --zone 3
/usr/local/sbin/iptables -t raw -A PREROUTING -i br0 -j CT --zone 3
Any ideas are welcome.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* [PATCH] via-velocity: fix the WOL bug on 1000M full duplex forced mode
From: David Lv @ 2010-12-14 7:36 UTC (permalink / raw)
To: netdev, romieu, DavidLv, ShirleyHu, AndersMa
This patch isn't based on the first patch of the sleep speed 10M.
The VIA velocity card can't be waken up by WOL tool on 1000M full
duplex forced mode.
This patch fixes the bug.
Thanks!
Signed-off-by: David Lv <DavidLv@viatech.com.cn>
Acked-by: Francois Romieu <romieu@fr.zoreil.com>
---
drivers/net/via-velocity.c | 37 +++++++++++++++++++++++--------------
1 files changed, 23 insertions(+), 14 deletions(-)
diff --git a/drivers/net/via-velocity.c b/drivers/net/via-velocity.c
index cab96ad..947af49 100755
--- a/drivers/net/via-velocity.c
+++ b/drivers/net/via-velocity.c
@@ -2925,6 +2925,7 @@ static int velocity_set_wol(struct velocity_info *vptr)
struct mac_regs __iomem *regs = vptr->mac_regs;
static u8 buf[256];
int i;
+ u8 GCR;
static u32 mask_pattern[2][4] = {
{0x00203000, 0x000003C0, 0x00000000, 0x0000000}, /* ARP */
@@ -2968,23 +2969,31 @@ static int velocity_set_wol(struct velocity_info *vptr)
writew(0x0FFF, ®s->WOLSRClr);
- if (vptr->mii_status & VELOCITY_AUTONEG_ENABLE) {
- if (PHYID_GET_PHY_ID(vptr->phy_id) == PHYID_CICADA_CS8201)
- MII_REG_BITS_ON(AUXCR_MDPPS, MII_NCONFIG, vptr->mac_regs);
-
- MII_REG_BITS_OFF(ADVERTISE_1000FULL | ADVERTISE_1000HALF,
MII_CTRL1000, vptr->mac_regs);
- }
+ if (SPD_DPX_1000_FULL != pInfo->hw.sOpts.spd_dpx) {
+ if (SPD_DPX_AUTO == pInfo->hw.sOpts.spd_dpx) {
+ if (vptr->mii_status & VELOCITY_AUTONEG_ENABLE) {
+ if (PHYID_GET_PHY_ID(vptr->phy_id) ==
+ PHYID_CICADA_CS8201)
+ MII_REG_BITS_ON(AUXCR_MDPPS,
+ MII_NCONFIG, vptr->mac_regs);
+
+ MII_REG_BITS_OFF(ADVERTISE_1000FULL |
+ ADVERTISE_1000HALF, MII_CTRL1000,
+ vptr->mac_regs);
+ }
- if (vptr->mii_status & VELOCITY_SPEED_1000)
- MII_REG_BITS_ON(BMCR_ANRESTART, MII_BMCR, vptr->mac_regs);
+ if (vptr->mii_status & VELOCITY_SPEED_1000)
+ MII_REG_BITS_ON(BMCR_ANRESTART, MII_BMCR,
+ vptr->mac_regs);
+ }
- BYTE_REG_BITS_ON(CHIPGCR_FCMODE, ®s->CHIPGCR);
+ BYTE_REG_BITS_ON(CHIPGCR_FCMODE, ®s->CHIPGCR);
- {
- u8 GCR;
- GCR = readb(®s->CHIPGCR);
- GCR = (GCR & ~CHIPGCR_FCGMII) | CHIPGCR_FCFDX;
- writeb(GCR, ®s->CHIPGCR);
+ {
+ GCR = readb(®s->CHIPGCR);
+ GCR = (GCR & ~CHIPGCR_FCGMII) | CHIPGCR_FCFDX;
+ writeb(GCR, ®s->CHIPGCR);
+ }
}
BYTE_REG_BITS_OFF(ISR_PWEI, ®s->ISR);
--
1.7.0.4
^ 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