* Re: [iproute2] tc pedit modify ethhdr ?
From: jamal @ 2010-03-25 3:21 UTC (permalink / raw)
To: Xiaofei Wu; +Cc: linux netdev
In-Reply-To: <326421.66567.qm@web111606.mail.gq1.yahoo.com>
I put some effort in responding to you. Please put some
effort in testing it.
cheers,
jamal
On Wed, 2010-03-24 at 19:59 -0700, Xiaofei Wu wrote:
>
>
> I made a test like your example.
> The terminal prints:
> parse_cmd argc 20 set offset -14 length 2
> pack_key16: Final val 90000000 mask 0000ffff
> parse_cmd done argc 18 munge offset -16 length 2
>
> what's the meaning of the above 3 lines; It modify the value of -16,-15,-14,-13 , or just modify -14,-13 ?
> If it modified -16,-15 , would it cause any problems?
>
> Thanks.
>
>
> --
> Wu
>
>
>
> ----- Original Message ----
> > but the size of ethhdr is 14 bytes, 14 is not multiple of 4 .
> > How to use 'tc ... pedit ...' modify a packet's h_dest and h_source
> > of ethhdr ?
> > Use ' ... pedit munge offset -14 u16 set 0x0090 munge offset -12 u32 set 0x9600030a ... ' or
> > use ' ... pedit munge offset -16 u32 ... munge offset -12 ... ' ?
> >
>
> 0 is at ip header.
> dst MAC starts at -14
> src MAC at -8
> ethertype at -2
>
> Example:
> tc filter add dev eth0 parent ffff: protocol ip prio 10 u32 \
> match ip src 192.168.1.10/32 flowid 1:2 \
> action pedit munge offset -14 u16 set 0x0000 \
> munge offset -12 u32 set 0x00010100 \
> munge offset -8 u32 set 0x0aaf0100 \
> munge offset -4 u32 set 0x0008ec06 pipe \
> action mirred egress redirect dev eth1
>
>
>
^ permalink raw reply
* why does the tcp_time_wait() call tcp_done(sk)?
From: 杨硕 @ 2010-03-25 3:24 UTC (permalink / raw)
To: netdev
that means the connection has been closed?
Does kernel think like that???
we can use "STATE_TRACE" to see FIN_WAIT_2--->CLOSE rather than
FIN_WAIT_2-->TIME_WAIT-->CLOSE.
TIA.
void tcp_time_wait(struct sock *sk, int state, int timeo)
{
struct inet_timewait_sock *tw = NULL;
const struct inet_connection_sock *icsk = inet_csk(sk);
const struct tcp_sock *tp = tcp_sk(sk);
int recycle_ok = 0;
if (tcp_death_row.sysctl_tw_recycle && tp->rx_opt.ts_recent_stamp)
recycle_ok = icsk->icsk_af_ops->remember_stamp(sk);
if (tcp_death_row.tw_count < tcp_death_row.sysctl_max_tw_buckets)
tw = inet_twsk_alloc(sk, state);
if (tw != NULL) {
struct tcp_timewait_sock *tcptw = tcp_twsk((struct sock *)tw);
const int rto = (icsk->icsk_rto << 2) - (icsk->icsk_rto >> 1);
tw->tw_rcv_wscale = tp->rx_opt.rcv_wscale;
tcptw->tw_rcv_nxt = tp->rcv_nxt;
tcptw->tw_snd_nxt = tp->snd_nxt;
tcptw->tw_rcv_wnd = tcp_receive_window(tp);
tcptw->tw_ts_recent = tp->rx_opt.ts_recent;
tcptw->tw_ts_recent_stamp = tp->rx_opt.ts_recent_stamp;
#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
if (tw->tw_family == PF_INET6) {
struct ipv6_pinfo *np = inet6_sk(sk);
struct inet6_timewait_sock *tw6;
tw->tw_ipv6_offset = inet6_tw_offset(sk->sk_prot);
tw6 = inet6_twsk((struct sock *)tw);
ipv6_addr_copy(&tw6->tw_v6_daddr, &np->daddr);
ipv6_addr_copy(&tw6->tw_v6_rcv_saddr, &np->rcv_saddr);
tw->tw_ipv6only = np->ipv6only;
}
#endif
#ifdef CONFIG_TCP_MD5SIG
/*
* The timewait bucket does not have the key DB from the
* sock structure. We just make a quick copy of the
* md5 key being used (if indeed we are using one)
* so the timewait ack generating code has the key.
*/
do {
struct tcp_md5sig_key *key;
memset(tcptw->tw_md5_key, 0, sizeof(tcptw->tw_md5_key));
tcptw->tw_md5_keylen = 0;
key = tp->af_specific->md5_lookup(sk, sk);
if (key != NULL) {
memcpy(&tcptw->tw_md5_key, key->key, key->keylen);
tcptw->tw_md5_keylen = key->keylen;
if (tcp_alloc_md5sig_pool() == NULL)
BUG();
}
} while (0);
#endif
/* Linkage updates. */
__inet_twsk_hashdance(tw, sk, &tcp_hashinfo);
/* Get the TIME_WAIT timeout firing. */
if (timeo < rto)
timeo = rto;
if (recycle_ok) {
tw->tw_timeout = rto;
} else {
tw->tw_timeout = TCP_TIMEWAIT_LEN;
if (state == TCP_TIME_WAIT)
timeo = TCP_TIMEWAIT_LEN;
}
inet_twsk_schedule(tw, &tcp_death_row, timeo,
TCP_TIMEWAIT_LEN);
inet_twsk_put(tw);
} else {
/* Sorry, if we're out of memory, just CLOSE this
* socket up. We've got bigger problems than
* non-graceful socket closings.
*/
LIMIT_NETDEBUG(KERN_INFO "TCP: time wait bucket table overflow\n");
}
tcp_update_metrics(sk);
tcp_done(sk);
}
^ permalink raw reply
* Re: Seeing new kernel unaligned access messages in linux-next on ia64
From: David Miller @ 2010-03-25 3:32 UTC (permalink / raw)
To: tony.luck; +Cc: jengelh, schwab, netdev
In-Reply-To: <987664A83D2D224EAE907B061CE93D53B30F00F1@orsmsx505.amr.corp.intel.com>
From: "Luck, Tony" <tony.luck@intel.com>
Date: Wed, 24 Mar 2010 16:19:38 -0700
>> No more unaligned messages - but is this an acceptable solution?
>
> There are a bunch of macros in include/linux/unaligned/*.h to
> handle this sort of thing.
It's totally unnecessary here and it would be overkill to
use those interfaces one at a time on every struct member
when a proper memcpy() fro ma type-pruned void pointer
suffices.
^ permalink raw reply
* Re: Seeing new kernel unaligned access messages in linux-next on ia64
From: David Miller @ 2010-03-25 3:32 UTC (permalink / raw)
To: jengelh; +Cc: schwab, tony.luck, netdev
In-Reply-To: <alpine.LSU.2.01.1003250014400.16715@obet.zrqbmnf.qr>
From: Jan Engelhardt <jengelh@medozas.de>
Date: Thu, 25 Mar 2010 00:17:01 +0100 (CET)
> No more unaligned messages - but is this an acceptable solution?
We already rely on this elsewhere, particularly in the
xfrm_user code.
^ permalink raw reply
* Re: [RFC PATCH net-next 0/7 v2]IPv6:netfilter: defragment
From: YOSHIFUJI Hideaki @ 2010-03-25 4:19 UTC (permalink / raw)
To: Shan Wei
Cc: Patrick McHardy, YOSHIFUJI Hideaki, David Miller, Alexey Dobriyan,
Yasuyuki KOZAKAI, netdev@vger.kernel.org, netfilter-devel,
YOSHIFUJI Hideaki
In-Reply-To: <4BAACA44.6010306@cn.fujitsu.com>
(2010/03/25 11:28), Shan Wei wrote:
> Patrick McHardy wrote, at 03/23/2010 11:05 PM:
>> Shan Wei wrote:
>>>> On the other hand, I'd even say we should NOT send
>>>> icmp here (at least by default) because standard routers
>>>> never send such packet.
>>>>
>>> Yes，for routers, the patch-set does not send icmp message to
>>> source host. It only does on destination host with IPv6 connection
>>> track enable.
>>>
>>
>> The nf-next tree is open again, now would be a good time to resubmit
>> these patches.
>> Thanks!
>
> If no body opposes them, i will resubmit these patches with v3.
>
I still disagree 4-7.
--yoshfuji
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC PATCH net-next 0/7 v2]IPv6:netfilter: defragment
From: YOSHIFUJI Hideaki @ 2010-03-25 4:20 UTC (permalink / raw)
To: Jozsef Kadlecsik
Cc: Patrick McHardy, Shan Wei, YOSHIFUJI Hideaki, David Miller,
Alexey Dobriyan, Yasuyuki KOZAKAI, netdev@vger.kernel.org,
netfilter-devel, YOSHIFUJI Hideaki
In-Reply-To: <alpine.DEB.2.00.1003232050540.18241@blackhole.kfki.hu>
(2010/03/24 5:10), Jozsef Kadlecsik wrote:
> On Wed, 24 Mar 2010, YOSHIFUJI Hideaki wrote:
>
>>> In this case without conntrack, IPv6 would send an ICMPv6 message,
>>> so in my opinion the transparent thing to do would be to still send
>>> them. Of course only if reassembly is done on an end host.
>>
>> Well, no. conntrack should just forward even uncompleted fragments
>> to next process (e.g. core ipv6 code), and then the core would send
>> ICMP error back. ICMP should be sent by the core ipv6 code according
>> to decision of itself, not according to netfilter.
>
> But what state could be associated by conntrack to the uncompleted
> fragments but the INVALID state? In consequence, in any sane setup, the
> uncompleted fragments will be dropped silently by a filter table rule
> and no ICMP error message will be sent back.
>
> Therefore I think iff the destination of the fragments is the host
> itself, then conntrack should generate an ICMP error message. But that
> error message must be processed by conntrack to set its state and then
> the fate of the generated packet can be decided by a rule.
Well.... no.
First of all. in "sane" setup, people should configure according
to their own requirements. They may or may not want send back
icmp packet. And, even if the core is to send icmp back, the
state would be correctly assigned.
We cannot (and should not) do something "cleaver" (excluding
packet drops) in conntrack in PRE_ROUTING chain.
One reason is that in PRE_ROUTING context, we can NOT determine
if the address we see in the IP header is really the final
destination. The overall situation is the same even if the
routing entry corresponding the "current" destination points
the node itself, or even if the node is configured as host.
It might seems that we could do something in the "filter"
table in LOCAL_IN, FORWARD or LOCAL_OUT (after routing header
process).
But well, we unfortunately cannot do this (at least
automatically) because even in LOCAL_IN, the final
destination has not been decided until we process all
of extension headers.
Sending ICMP in netfilter (especially in conntrack) is too
patchy, and is not right. If we do the right thing (and
I believe we should do so), I'd propose to have hooks
around handlers inside ip6_input_finish().
...I remember that I was thinking about this before.
For my conclusion, first option is just to drop
uncompleted fragments as we do today. Second option
would be to forward them to the next process so that
core code could send ICMPv6 etc. or, we could have
new code to send ICMPV6_TIME_EXCEED in REJECT target.
In longer term, I think it is better to introduce
per-exthdr hooks.
Regards,
--yoshfuji
^ permalink raw reply
* [PATCH] RPS: support 802.1q and pppoe session
From: Changli Gao @ 2010-03-25 4:30 UTC (permalink / raw)
To: David S. Miller; +Cc: Tom Herbert, xiaosuo, netdev
support 802.1q and pppoe session
Support 802.1q and pppoe session, and these two protocols can get the
benefit from RPS.
Signed-off-by: Changli Gao <xiaosuo@gmail.com>
----
net/core/dev.c | 38 ++++++++++++++++++++++++++++++--------
1 file changed, 30 insertions(+), 8 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index a03aab4..647ecc4 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -130,6 +130,10 @@
#include <linux/random.h>
#include <trace/events/napi.h>
+#ifdef CONFIG_SMP
+#include <linux/if_pppox.h>
+#endif
+
#include "net-sysfs.h"
/* Instead of increasing this, you should create a hash table. */
@@ -2190,7 +2194,8 @@ static int get_rps_cpu(struct net_device *dev, struct sk_buff *skb)
struct rps_map *map;
int cpu = -1;
u8 ip_proto;
- u32 addr1, addr2, ports, ihl;
+ __be16 protocol;
+ u32 addr1, addr2, ports, offset;
rcu_read_lock();
@@ -2214,26 +2219,43 @@ static int get_rps_cpu(struct net_device *dev, struct sk_buff *skb)
if (skb->rxhash)
goto got_hash; /* Skip hash computation on packet header */
- switch (skb->protocol) {
+ offset = 0;
+ protocol = skb->protocol;
+nest:
+ switch (protocol) {
+ case __constant_htons(ETH_P_8021Q):
+ if (!pskb_may_pull(skb, offset + VLAN_HLEN))
+ goto done;
+ protocol = ((struct vlan_hdr*)(skb->data +
+ offset))->h_vlan_encapsulated_proto;
+ offset += VLAN_HLEN;
+ goto nest;
+ case __constant_htons(ETH_P_PPP_SES):
+ if (!pskb_may_pull(skb, offset + PPPOE_SES_HLEN))
+ goto done;
+ protocol = *((__be16 *)(skb->data + offset +
+ sizeof(struct pppoe_hdr)));
+ offset += PPPOE_SES_HLEN;
+ goto nest;
case __constant_htons(ETH_P_IP):
- if (!pskb_may_pull(skb, sizeof(*ip)))
+ if (!pskb_may_pull(skb, offset + sizeof(*ip)))
goto done;
ip = (struct iphdr *) skb->data;
ip_proto = ip->protocol;
addr1 = ip->saddr;
addr2 = ip->daddr;
- ihl = ip->ihl;
+ offset += ip->ihl << 2;
break;
case __constant_htons(ETH_P_IPV6):
- if (!pskb_may_pull(skb, sizeof(*ip6)))
+ if (!pskb_may_pull(skb, offset + sizeof(*ip6)))
goto done;
ip6 = (struct ipv6hdr *) skb->data;
ip_proto = ip6->nexthdr;
addr1 = ip6->saddr.s6_addr32[3];
addr2 = ip6->daddr.s6_addr32[3];
- ihl = (40 >> 2);
+ offset += 40;
break;
default:
goto done;
@@ -2247,8 +2269,8 @@ static int get_rps_cpu(struct net_device *dev, struct sk_buff *skb)
case IPPROTO_AH:
case IPPROTO_SCTP:
case IPPROTO_UDPLITE:
- if (pskb_may_pull(skb, (ihl * 4) + 4))
- ports = *((u32 *) (skb->data + (ihl * 4)));
+ if (pskb_may_pull(skb, offset + 4))
+ ports = *((u32 *) (skb->data + offset));
break;
default:
^ permalink raw reply related
* Re: bug 15606: register_netdevice: Kobject changed too ealier
From: Eric Dumazet @ 2010-03-25 4:35 UTC (permalink / raw)
To: Richard Zhao; +Cc: netdev
In-Reply-To: <4e090d471003241944v6e1b6712h740f79f522514ca4@mail.gmail.com>
Le jeudi 25 mars 2010 à 10:44 +0800, Richard Zhao a écrit :
> Hi,
>
> Could someone take bug 15606?
> https://bugzilla.kernel.org/show_bug.cgi?id=15606
>
But...
What's the point of opening a bugzilla report if you already have a
patch ?
Just send here a formal patch and we can discuss it directly, Ack it or
reject it...
Thanks
^ permalink raw reply
* Re: [PATCH] RPS: support 802.1q and pppoe session
From: David Miller @ 2010-03-25 4:50 UTC (permalink / raw)
To: xiaosuo; +Cc: therbert, netdev
In-Reply-To: <4BAAE6E9.6030103@gmail.com>
From: Changli Gao <xiaosuo@gmail.com>
Date: Thu, 25 Mar 2010 12:30:33 +0800
> support 802.1q and pppoe session
>
> Support 802.1q and pppoe session, and these two protocols can get the
> benefit from RPS.
>
> Signed-off-by: Changli Gao <xiaosuo@gmail.com>
This is getting rediculious.
The TX hasher doesn't support this, neither should RPS.
Most of the patches you've been posting to RPS are very specialized
hacks and frankly not very welcome.
^ permalink raw reply
* Re: [PATCH] RPS: support 802.1q and pppoe session
From: Eric Dumazet @ 2010-03-25 5:03 UTC (permalink / raw)
To: xiaosuo; +Cc: David S. Miller, Tom Herbert, netdev
In-Reply-To: <4BAAE6E9.6030103@gmail.com>
Le jeudi 25 mars 2010 à 12:30 +0800, Changli Gao a écrit :
> support 802.1q and pppoe session
>
> Support 802.1q and pppoe session, and these two protocols can get the
> benefit from RPS.
>
> Signed-off-by: Changli Gao <xiaosuo@gmail.com>
> ----
> net/core/dev.c | 38 ++++++++++++++++++++++++++++++--------
> 1 file changed, 30 insertions(+), 8 deletions(-)
>
> diff --git a/net/core/dev.c b/net/core/dev.c
> index a03aab4..647ecc4 100644
While this might sounds a good idea, you really should split this in two
parts.
By the way, why not handling IPIP too ?
Because I believe 802.1q part has no added value for instance, since
packet handled by CPUX will be decoded and passed to VLAN device, having
a chance to be fully taken by RPS, since we go back to netif_rx().
Probably same thing for IPIP / PPPOE can be discussed.
I agree we might need a flag or something to reset rxhash to 0 somewhere
(probably in non accelerated vlan rx handling) to force second
get_rps_cpu() invocation to recompute it. This small correction has no
cost if put outside of get_rps_cpus().
If get_rps_cpus() is too complex, it might become too slow for typical
use. We should find smart ways to solve your performance problem if they
ever exist.
^ permalink raw reply
* Re: [PATCH] RPS: support 802.1q and pppoe session
From: Changli Gao @ 2010-03-25 5:12 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David S. Miller, Tom Herbert, netdev
In-Reply-To: <1269493402.15280.29.camel@edumazet-laptop>
On Thu, Mar 25, 2010 at 1:03 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
> While this might sounds a good idea, you really should split this in two
> parts.
>
> By the way, why not handling IPIP too ?
I'm not sure if it is a good idea to support VLAN and PPPOE, and
actually David don't like it. :(
>
> Because I believe 802.1q part has no added value for instance, since
> packet handled by CPUX will be decoded and passed to VLAN device, having
> a chance to be fully taken by RPS, since we go back to netif_rx().
>
> Probably same thing for IPIP / PPPOE can be discussed.
It is useful when Linux is run as a bridge.
>
> I agree we might need a flag or something to reset rxhash to 0 somewhere
> (probably in non accelerated vlan rx handling) to force second
> get_rps_cpu() invocation to recompute it. This small correction has no
> cost if put outside of get_rps_cpus().
>
> If get_rps_cpus() is too complex, it might become too slow for typical
> use. We should find smart ways to solve your performance problem if they
> ever exist.
>
It means that more than one IPI will be sent for just a single
packets, I don't think the cost is acceptable.
--
Regards，
Changli Gao(xiaosuo@gmail.com)
^ permalink raw reply
* Re: [PATCH] RPS: support 802.1q and pppoe session
From: Eric Dumazet @ 2010-03-25 5:13 UTC (permalink / raw)
To: xiaosuo, David Miller; +Cc: Tom Herbert, netdev
In-Reply-To: <4BAAE6E9.6030103@gmail.com>
Le jeudi 25 mars 2010 à 12:30 +0800, Changli Gao a écrit :
> +#ifdef CONFIG_SMP
> +#include <linux/if_pppox.h>
> +#endif
BTW, when I see this kind of illogical thing, I do think we should have
a CONFIG_RPS setting...
David, may I submit again my former patch adding CONFIG_RPS, but not a
user selectable boolean ?
[PATCH net-next-2.6] rps: add CONFIG_RPS
RPS currently depends on SMP and SYSFS
Adding a CONFIG_RPS makes sense in case this requirement changes in the
future. This patch saves about 1500 bytes of kernel text in case SMP is
on but SYSFS is off.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
include/linux/netdevice.h | 4 ++++
net/Kconfig | 5 +++++
net/core/dev.c | 29 +++++++++++++++++++----------
3 files changed, 28 insertions(+), 10 deletions(-)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index c96c41e..53c272f 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -531,6 +531,7 @@ struct netdev_queue {
unsigned long tx_dropped;
} ____cacheline_aligned_in_smp;
+#ifdef CONFIG_RPS
/*
* This structure holds an RPS map which can be of variable length. The
* map is an array of CPUs.
@@ -549,6 +550,7 @@ struct netdev_rx_queue {
struct netdev_rx_queue *first;
atomic_t count;
} ____cacheline_aligned_in_smp;
+#endif
/*
* This structure defines the management hooks for network devices.
@@ -897,12 +899,14 @@ struct net_device {
unsigned char broadcast[MAX_ADDR_LEN]; /* hw bcast add */
+#ifdef CONFIG_RPS
struct kset *queues_kset;
struct netdev_rx_queue *_rx;
/* Number of RX queues allocated at alloc_netdev_mq() time */
unsigned int num_rx_queues;
+#endif
struct netdev_queue rx_queue;
diff --git a/net/Kconfig b/net/Kconfig
index 041c35e..6851464 100644
--- a/net/Kconfig
+++ b/net/Kconfig
@@ -203,6 +203,11 @@ source "net/ieee802154/Kconfig"
source "net/sched/Kconfig"
source "net/dcb/Kconfig"
+config RPS
+ boolean
+ depends on SMP && SYSFS
+ default y
+
menu "Network testing"
config NET_PKTGEN
diff --git a/net/core/dev.c b/net/core/dev.c
index 5e3dc28..bcb3ed2 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2177,7 +2177,7 @@ int weight_p __read_mostly = 64; /* old backlog weight */
DEFINE_PER_CPU(struct netif_rx_stats, netdev_rx_stat) = { 0, };
-#ifdef CONFIG_SMP
+#ifdef CONFIG_RPS
/*
* get_rps_cpu is called from netif_receive_skb and returns the target
* CPU from the RPS map of the receiving queue for a given skb.
@@ -2325,7 +2325,7 @@ enqueue:
/* Schedule NAPI for backlog device */
if (napi_schedule_prep(&queue->backlog)) {
-#ifdef CONFIG_SMP
+#ifdef CONFIG_RPS
if (cpu != smp_processor_id()) {
struct rps_remote_softirq_cpus *rcpus =
&__get_cpu_var(rps_remote_softirq_cpus);
@@ -2376,7 +2376,7 @@ int netif_rx(struct sk_buff *skb)
if (!skb->tstamp.tv64)
net_timestamp(skb);
-#ifdef CONFIG_SMP
+#ifdef CONFIG_RPS
cpu = get_rps_cpu(skb->dev, skb);
if (cpu < 0)
cpu = smp_processor_id();
@@ -2750,7 +2750,7 @@ out:
*/
int netif_receive_skb(struct sk_buff *skb)
{
-#ifdef CONFIG_SMP
+#ifdef CONFIG_RPS
int cpu;
cpu = get_rps_cpu(skb->dev, skb);
@@ -3189,7 +3189,7 @@ void netif_napi_del(struct napi_struct *napi)
}
EXPORT_SYMBOL(netif_napi_del);
-#ifdef CONFIG_SMP
+#ifdef CONFIG_RPS
/*
* net_rps_action sends any pending IPI's for rps. This is only called from
* softirq and interrupts must be enabled.
@@ -3214,7 +3214,7 @@ static void net_rx_action(struct softirq_action *h)
unsigned long time_limit = jiffies + 2;
int budget = netdev_budget;
void *have;
-#ifdef CONFIG_SMP
+#ifdef CONFIG_RPS
int select;
struct rps_remote_softirq_cpus *rcpus;
#endif
@@ -3280,7 +3280,7 @@ static void net_rx_action(struct softirq_action *h)
netpoll_poll_unlock(have);
}
out:
-#ifdef CONFIG_SMP
+#ifdef CONFIG_RPS
rcpus = &__get_cpu_var(rps_remote_softirq_cpus);
select = rcpus->select;
rcpus->select ^= 1;
@@ -5277,6 +5277,7 @@ int register_netdevice(struct net_device *dev)
dev->iflink = -1;
+#ifdef CONFIG_RPS
if (!dev->num_rx_queues) {
/*
* Allocate a single RX queue if driver never called
@@ -5293,7 +5294,7 @@ int register_netdevice(struct net_device *dev)
atomic_set(&dev->_rx->count, 1);
dev->num_rx_queues = 1;
}
-
+#endif
/* Init, if this function is available */
if (dev->netdev_ops->ndo_init) {
ret = dev->netdev_ops->ndo_init(dev);
@@ -5653,11 +5654,13 @@ struct net_device *alloc_netdev_mq(int sizeof_priv, const char *name,
void (*setup)(struct net_device *), unsigned int queue_count)
{
struct netdev_queue *tx;
- struct netdev_rx_queue *rx;
struct net_device *dev;
size_t alloc_size;
struct net_device *p;
+#ifdef CONFIG_RPS
+ struct netdev_rx_queue *rx;
int i;
+#endif
BUG_ON(strlen(name) >= sizeof(dev->name));
@@ -5683,6 +5686,7 @@ struct net_device *alloc_netdev_mq(int sizeof_priv, const char *name,
goto free_p;
}
+#ifdef CONFIG_RPS
rx = kcalloc(queue_count, sizeof(struct netdev_rx_queue), GFP_KERNEL);
if (!rx) {
printk(KERN_ERR "alloc_netdev: Unable to allocate "
@@ -5698,6 +5702,7 @@ struct net_device *alloc_netdev_mq(int sizeof_priv, const char *name,
*/
for (i = 0; i < queue_count; i++)
rx[i].first = rx;
+#endif
dev = PTR_ALIGN(p, NETDEV_ALIGN);
dev->padded = (char *)dev - (char *)p;
@@ -5713,8 +5718,10 @@ struct net_device *alloc_netdev_mq(int sizeof_priv, const char *name,
dev->num_tx_queues = queue_count;
dev->real_num_tx_queues = queue_count;
+#ifdef CONFIG_RPS
dev->_rx = rx;
dev->num_rx_queues = queue_count;
+#endif
dev->gso_max_size = GSO_MAX_SIZE;
@@ -5731,8 +5738,10 @@ struct net_device *alloc_netdev_mq(int sizeof_priv, const char *name,
return dev;
free_rx:
+#ifdef CONFIG_RPS
kfree(rx);
free_tx:
+#endif
kfree(tx);
free_p:
kfree(p);
@@ -6236,7 +6245,7 @@ static int __init net_dev_init(void)
queue->completion_queue = NULL;
INIT_LIST_HEAD(&queue->poll_list);
-#ifdef CONFIG_SMP
+#ifdef CONFIG_RPS
queue->csd.func = trigger_softirq;
queue->csd.info = queue;
queue->csd.flags = 0;
^ permalink raw reply related
* Re: [PATCH] RPS: support 802.1q and pppoe session
From: Eric Dumazet @ 2010-03-25 5:24 UTC (permalink / raw)
To: Changli Gao; +Cc: David S. Miller, Tom Herbert, netdev
In-Reply-To: <412e6f7f1003242212t242a30e0k635bdfb861c324e4@mail.gmail.com>
Le jeudi 25 mars 2010 à 13:12 +0800, Changli Gao a écrit :
> On Thu, Mar 25, 2010 at 1:03 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> >
> > While this might sounds a good idea, you really should split this in two
> > parts.
> >
> > By the way, why not handling IPIP too ?
>
> I'm not sure if it is a good idea to support VLAN and PPPOE, and
> actually David don't like it. :(
>
> >
> > Because I believe 802.1q part has no added value for instance, since
> > packet handled by CPUX will be decoded and passed to VLAN device, having
> > a chance to be fully taken by RPS, since we go back to netif_rx().
> >
> > Probably same thing for IPIP / PPPOE can be discussed.
>
> It is useful when Linux is run as a bridge.
>
I am not saying its not useful. BTW, for routers/bridges, RPS is not a
good idea, unless you must add netfilter complex rules.
> >
> > I agree we might need a flag or something to reset rxhash to 0 somewhere
> > (probably in non accelerated vlan rx handling) to force second
> > get_rps_cpu() invocation to recompute it. This small correction has no
> > cost if put outside of get_rps_cpus().
> >
> > If get_rps_cpus() is too complex, it might become too slow for typical
> > use. We should find smart ways to solve your performance problem if they
> > ever exist.
> >
>
> It means that more than one IPI will be sent for just a single
> packets, I don't think the cost is acceptable.
>
I believe you dont _fully_ understand how RPS currently works.
I am very surprised you send RPS patches if you dont master it.
Please read again get_rps_cpus(), line 2238
default:
goto done; <<<< HERE skb->rxhash unchanged >>>>
}
ports = 0;
switch (ip_proto) {
This means that unknown protocols are directly handled by THIS cpu, and
not given to another cpu. No IPI involved.
In case of tunnels or vlan, we then reenter lowlevel stack and at this
point, we can fully use RPS, because we are able to find IPV4/IPV6
headers.
Your patch is not necessary, since next time we call get_rps_cpus(),
rxhash being still null, we compute the correct non null hash and at
this point can choose an appropriate target cpu.
(All you need is to set /sys/class/net/vlan.825/queues/rx-0/rps_cpus to
needed mask)
^ permalink raw reply
* Re: [PATCH] RPS: support 802.1q and pppoe session
From: Changli Gao @ 2010-03-25 5:47 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David S. Miller, Tom Herbert, netdev
In-Reply-To: <1269494668.15280.72.camel@edumazet-laptop>
On Thu, Mar 25, 2010 at 1:24 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le jeudi 25 mars 2010 à 13:12 +0800, Changli Gao a écrit :
>>
>> It is useful when Linux is run as a bridge.
>>
>
> I am not saying its not useful. BTW, for routers/bridges, RPS is not a
> good idea, unless you must add netfilter complex rules.
>
Yea, we do DPI in netfilter. And for a stateful fireware, connection
tracking isn't cheap. As bandwidth increases, we find one CPU can't
handle all the traffic from a single NIC. We currently use dynamic
weighted packets distributing algorithm with patched Linux-2.6.18, and
it works very well.
>> >
>> > I agree we might need a flag or something to reset rxhash to 0 somewhere
>> > (probably in non accelerated vlan rx handling) to force second
>> > get_rps_cpu() invocation to recompute it. This small correction has no
>> > cost if put outside of get_rps_cpus().
>> >
>> > If get_rps_cpus() is too complex, it might become too slow for typical
>> > use. We should find smart ways to solve your performance problem if they
>> > ever exist.
>> >
>>
>> It means that more than one IPI will be sent for just a single
>> packets, I don't think the cost is acceptable.
>>
>
> I believe you dont _fully_ understand how RPS currently works.
>
> I am very surprised you send RPS patches if you dont master it.
>
> Please read again get_rps_cpus(), line 2238
>
> default:
> goto done; <<<< HERE skb->rxhash unchanged >>>>
> }
> ports = 0;
> switch (ip_proto) {
>
>
> This means that unknown protocols are directly handled by THIS cpu, and
> not given to another cpu. No IPI involved.
>
> In case of tunnels or vlan, we then reenter lowlevel stack and at this
> point, we can fully use RPS, because we are able to find IPV4/IPV6
> headers.
>
> Your patch is not necessary, since next time we call get_rps_cpus(),
> rxhash being still null, we compute the correct non null hash and at
> this point can choose an appropriate target cpu.
>
> (All you need is to set /sys/class/net/vlan.825/queues/rx-0/rps_cpus to
> needed mask)
>
I knew the current code is OK, and no additional IPI is needed. I said
that because you said:
>> > I agree we might need a flag or something to reset rxhash to 0 somewhere
>> > (probably in non accelerated vlan rx handling) to force second
>> > get_rps_cpu() invocation to recompute it. This small correction has no
>> > cost if put outside of get_rps_cpus().
Oh, maybe I misunderstood you words. I thought the rxhash you want to
clear is computed by get_rps_cpu()? I remembered some NIC itself can
get 5-tuple from vlan and pppoe packets to compute hash. In that case,
we should not clear rxhash.
--
Regards，
Changli Gao(xiaosuo@gmail.com)
^ permalink raw reply
* Re: [PATCH] RPS: support 802.1q and pppoe session
From: Eric Dumazet @ 2010-03-25 5:58 UTC (permalink / raw)
To: Changli Gao; +Cc: David S. Miller, Tom Herbert, netdev
In-Reply-To: <412e6f7f1003242247h79dd3ce0u449a1e71bf4ec742@mail.gmail.com>
Le jeudi 25 mars 2010 à 13:47 +0800, Changli Gao a écrit :
> Yea, we do DPI in netfilter. And for a stateful fireware, connection
> tracking isn't cheap. As bandwidth increases, we find one CPU can't
> handle all the traffic from a single NIC. We currently use dynamic
> weighted packets distributing algorithm with patched Linux-2.6.18, and
> it works very well.
>
Hmm... we added RCU to conntrack last year only, so with 2.6.18
conntrack hits a global lock.
tcp conntrack also uses another global lock, this is not yet converted,
even in 2.6.33.
How can this scale ?
> Oh, maybe I misunderstood you words. I thought the rxhash you want to
> clear is computed by get_rps_cpu()? I remembered some NIC itself can
> get 5-tuple from vlan and pppoe packets to compute hash. In that case,
> we should not clear rxhash.
>
rxhash is provided/computed only if its possible, and stay 0 if its not
possible to compute it :)
AFAIK, at this point, no network driver currently provides a rxhash. If
you know some NIC can provide it, please submit a patch :)
^ permalink raw reply
* Re: [PATCH] RPS: support 802.1q and pppoe session
From: Changli Gao @ 2010-03-25 6:09 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David S. Miller, Tom Herbert, netdev
In-Reply-To: <1269496705.15280.89.camel@edumazet-laptop>
On Thu, Mar 25, 2010 at 1:58 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le jeudi 25 mars 2010 à 13:47 +0800, Changli Gao a écrit :
>
>
> Hmm... we added RCU to conntrack last year only, so with 2.6.18
> conntrack hits a global lock.
>
> tcp conntrack also uses another global lock, this is not yet converted,
> even in 2.6.33.
> How can this scale ?
>
In our case, conntrack isn't a big issue, but DPI is. So we use per
connrack lock other than the global conntrack lock, and distributing
the two sides traffic belongs to the same conntrack to the same CPU,
so in normal case, there isn't any lock contention.
>
> rxhash is provided/computed only if its possible, and stay 0 if its not
> possible to compute it :)
>
> AFAIK, at this point, no network driver currently provides a rxhash. If
> you know some NIC can provide it, please submit a patch :)
>
It is a part of a private NP, and its code isn't in mainline. :(
--
Regards，
Changli Gao(xiaosuo@gmail.com)
^ permalink raw reply
* [PATCHv1 0/4]netxen: bug fixes
From: Amit Kumar Salecha @ 2010-03-25 7:06 UTC (permalink / raw)
To: davem; +Cc: netdev, ameen.rahman
Hi David,
Series of 4 patch to fix important bugs.
These are v1 patches, incorporating your comments.
Apply them on net-2.6 branch.
-Amit
^ permalink raw reply
* [PATCHv1 1/4] netxen: fix bios version calculation
From: Amit Kumar Salecha @ 2010-03-25 7:06 UTC (permalink / raw)
To: davem; +Cc: netdev, ameen.rahman
In-Reply-To: <1269500806-15383-1-git-send-email-amit.salecha@qlogic.com>
Bios sub version from unified fw image is calculated incorrect.
Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
---
drivers/net/netxen/netxen_nic_init.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/netxen/netxen_nic_init.c b/drivers/net/netxen/netxen_nic_init.c
index 1c63610..7eb925a 100644
--- a/drivers/net/netxen/netxen_nic_init.c
+++ b/drivers/net/netxen/netxen_nic_init.c
@@ -761,7 +761,7 @@ nx_get_bios_version(struct netxen_adapter *adapter)
if (adapter->fw_type == NX_UNIFIED_ROMIMAGE) {
bios_ver = cpu_to_le32(*((u32 *) (&fw->data[prd_off])
+ NX_UNI_BIOS_VERSION_OFF));
- return (bios_ver << 24) + ((bios_ver >> 8) & 0xff00) +
+ return (bios_ver << 16) + ((bios_ver >> 8) & 0xff00) +
(bios_ver >> 24);
} else
return cpu_to_le32(*(u32 *)&fw->data[NX_BIOS_VERSION_OFFSET]);
--
1.6.0.2
^ permalink raw reply related
* [PATCHv1 2/4] netxen: fix warning in ioaddr for NX3031 chip
From: Amit Kumar Salecha @ 2010-03-25 7:06 UTC (permalink / raw)
To: davem; +Cc: netdev, ameen.rahman
In-Reply-To: <1269500806-15383-1-git-send-email-amit.salecha@qlogic.com>
Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
crb_intr_mask/crb_sts_consumer is predefined for NX2031 not for
NX3031. For NX3031, these values get defined in rx context creation.
---
drivers/net/netxen/netxen_nic_ctx.c | 14 ++++++++------
1 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/net/netxen/netxen_nic_ctx.c b/drivers/net/netxen/netxen_nic_ctx.c
index 2a8ef5f..f26e547 100644
--- a/drivers/net/netxen/netxen_nic_ctx.c
+++ b/drivers/net/netxen/netxen_nic_ctx.c
@@ -669,13 +669,15 @@ int netxen_alloc_hw_resources(struct netxen_adapter *adapter)
}
sds_ring->desc_head = (struct status_desc *)addr;
- sds_ring->crb_sts_consumer =
- netxen_get_ioaddr(adapter,
- recv_crb_registers[port].crb_sts_consumer[ring]);
+ if (NX_IS_REVISION_P2(adapter->ahw.revision_id)) {
+ sds_ring->crb_sts_consumer =
+ netxen_get_ioaddr(adapter,
+ recv_crb_registers[port].crb_sts_consumer[ring]);
- sds_ring->crb_intr_mask =
- netxen_get_ioaddr(adapter,
- recv_crb_registers[port].sw_int_mask[ring]);
+ sds_ring->crb_intr_mask =
+ netxen_get_ioaddr(adapter,
+ recv_crb_registers[port].sw_int_mask[ring]);
+ }
}
--
1.6.0.2
^ permalink raw reply related
* [PATCHv1 3/4] netxen: added sanity check for pci map
From: Amit Kumar Salecha @ 2010-03-25 7:06 UTC (permalink / raw)
To: davem; +Cc: netdev, ameen.rahman
In-Reply-To: <1269500806-15383-1-git-send-email-amit.salecha@qlogic.com>
Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
Return value of ioremap is not checked, NULL check added.
---
drivers/net/netxen/netxen_nic_main.c | 14 ++++++++++++++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/drivers/net/netxen/netxen_nic_main.c b/drivers/net/netxen/netxen_nic_main.c
index 9a7a0f3..cf06a51 100644
--- a/drivers/net/netxen/netxen_nic_main.c
+++ b/drivers/net/netxen/netxen_nic_main.c
@@ -636,10 +636,24 @@ netxen_setup_pci_map(struct netxen_adapter *adapter)
mem_ptr2 = ioremap(mem_base + THIRD_PAGE_GROUP_START,
THIRD_PAGE_GROUP_SIZE);
pci_len0 = FIRST_PAGE_GROUP_SIZE;
+
+ if (mem_ptr0 == NULL || mem_ptr1 == NULL || mem_ptr2 == NULL) {
+ dev_err(&pdev->dev, "failed to map PCI bar 0\n");
+ err = -EIO;
+ goto err_out;
+ }
+
} else if (mem_len == NETXEN_PCI_32MB_SIZE) {
mem_ptr1 = ioremap(mem_base, SECOND_PAGE_GROUP_SIZE);
mem_ptr2 = ioremap(mem_base + THIRD_PAGE_GROUP_START -
SECOND_PAGE_GROUP_START, THIRD_PAGE_GROUP_SIZE);
+
+ if (mem_ptr1 == NULL || mem_ptr2 == NULL) {
+ dev_err(&pdev->dev, "failed to map PCI bar 0\n");
+ err = -EIO;
+ goto err_out;
+ }
+
} else if (mem_len == NETXEN_PCI_2MB_SIZE) {
mem_ptr0 = pci_ioremap_bar(pdev, 0);
--
1.6.0.2
^ permalink raw reply related
* [PATCHv1 4/4] netxen: update version to 4.0.73
From: Amit Kumar Salecha @ 2010-03-25 7:06 UTC (permalink / raw)
To: davem; +Cc: netdev, ameen.rahman
In-Reply-To: <1269500806-15383-1-git-send-email-amit.salecha@qlogic.com>
Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
---
drivers/net/netxen/netxen_nic.h | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/netxen/netxen_nic.h b/drivers/net/netxen/netxen_nic.h
index 144d2e8..0f70383 100644
--- a/drivers/net/netxen/netxen_nic.h
+++ b/drivers/net/netxen/netxen_nic.h
@@ -53,8 +53,8 @@
#define _NETXEN_NIC_LINUX_MAJOR 4
#define _NETXEN_NIC_LINUX_MINOR 0
-#define _NETXEN_NIC_LINUX_SUBVERSION 72
-#define NETXEN_NIC_LINUX_VERSIONID "4.0.72"
+#define _NETXEN_NIC_LINUX_SUBVERSION 73
+#define NETXEN_NIC_LINUX_VERSIONID "4.0.73"
#define NETXEN_VERSION_CODE(a, b, c) (((a) << 24) + ((b) << 16) + (c))
#define _major(v) (((v) >> 24) & 0xff)
--
1.6.0.2
^ permalink raw reply related
* Re: [PATCH 2/2] ipv4: Restart rt_intern_hash after emergency rebuild
From: Pavel Emelyanov @ 2010-03-25 7:44 UTC (permalink / raw)
To: Neil Horman; +Cc: David Miller, Eric Dumazet, Linux Netdev List
In-Reply-To: <20100324195725.GC29364@hmsreliant.think-freely.org>
>> @@ -1217,6 +1217,12 @@ restart:
>> rt->u.dst.dev->name, num);
>> }
>> rt_emergency_hash_rebuild(net);
>> + spin_unlock_bh(rt_hash_lock_addr(hash));
>> +
>> + hash = rt_hash(rt->fl.fl4_dst, rt->fl.fl4_src,
>> + in ? rt->fl.iif : rt->fl.oif,
>> + rt_genid(net));
>> + goto restart;
>> }
>> }
> Why pass in a flag here? Perhaps it would be easier just to pass in the ifindex
> that was origionally used by the caller of rt_intern_hash so that the hash could
> be redone without needing to toggle on the value of the flag.
That's perfectly fine with me. I'll resend the patch shortly.
> Regards
> Neil
>
>>
>
^ permalink raw reply
* [PATCH 2/2] ipv4: Restart rt_intern_hash after emergency rebuild (v2)
From: Pavel Emelyanov @ 2010-03-25 7:51 UTC (permalink / raw)
To: David Miller; +Cc: Eric Dumazet, Neil Horman, Linux Netdev List
In-Reply-To: <4BAA4F3F.70703@openvz.org>
The the rebuild changes the genid which in turn is used at
the hash calculation. Thus if we don't restart and go on with
inserting the rt will happen in wrong chain.
(Fixed Neil's comment about the index passed into the rt_intern_hash)
Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
---
net/ipv4/route.c | 17 +++++++++++------
1 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index 28c1c2f..54ddc84 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -1097,7 +1097,7 @@ static int slow_chain_length(const struct rtable *head)
}
static int rt_intern_hash(unsigned hash, struct rtable *rt,
- struct rtable **rp, struct sk_buff *skb)
+ struct rtable **rp, struct sk_buff *skb, int ifindex)
{
struct rtable *rth, **rthp;
unsigned long now;
@@ -1217,6 +1217,11 @@ restart:
rt->u.dst.dev->name, num);
}
rt_emergency_hash_rebuild(net);
+ spin_unlock_bh(rt_hash_lock_addr(hash));
+
+ hash = rt_hash(rt->fl.fl4_dst, rt->fl.fl4_src,
+ ifindex, rt_genid(net));
+ goto restart;
}
}
@@ -1477,7 +1482,7 @@ void ip_rt_redirect(__be32 old_gw, __be32 daddr, __be32 new_gw,
&netevent);
rt_del(hash, rth);
- if (!rt_intern_hash(hash, rt, &rt, NULL))
+ if (!rt_intern_hash(hash, rt, &rt, NULL, rt->fl.oif))
ip_rt_put(rt);
goto do_next;
}
@@ -1930,7 +1935,7 @@ static int ip_route_input_mc(struct sk_buff *skb, __be32 daddr, __be32 saddr,
in_dev_put(in_dev);
hash = rt_hash(daddr, saddr, dev->ifindex, rt_genid(dev_net(dev)));
- return rt_intern_hash(hash, rth, NULL, skb);
+ return rt_intern_hash(hash, rth, NULL, skb, dev->ifindex);
e_nobufs:
in_dev_put(in_dev);
@@ -2097,7 +2102,7 @@ static int ip_mkroute_input(struct sk_buff *skb,
/* put it into the cache */
hash = rt_hash(daddr, saddr, fl->iif,
rt_genid(dev_net(rth->u.dst.dev)));
- return rt_intern_hash(hash, rth, NULL, skb);
+ return rt_intern_hash(hash, rth, NULL, skb, fl->iif);
}
/*
@@ -2254,7 +2259,7 @@ local_input:
}
rth->rt_type = res.type;
hash = rt_hash(daddr, saddr, fl.iif, rt_genid(net));
- err = rt_intern_hash(hash, rth, NULL, skb);
+ err = rt_intern_hash(hash, rth, NULL, skb, fl.iif);
goto done;
no_route:
@@ -2501,7 +2506,7 @@ static int ip_mkroute_output(struct rtable **rp,
if (err == 0) {
hash = rt_hash(oldflp->fl4_dst, oldflp->fl4_src, oldflp->oif,
rt_genid(dev_net(dev_out)));
- err = rt_intern_hash(hash, rth, rp, NULL);
+ err = rt_intern_hash(hash, rth, rp, NULL, oldflp->oif);
}
return err;
--
1.5.5.6
^ permalink raw reply related
* Re: [RFC PATCH net-next 0/7 v2]IPv6:netfilter: defragment
From: Pascal Hambourg @ 2010-03-25 8:38 UTC (permalink / raw)
To: Jozsef Kadlecsik
Cc: YOSHIFUJI Hideaki, Patrick McHardy, Shan Wei, David Miller,
Alexey Dobriyan, Yasuyuki KOZAKAI, netdev@vger.kernel.org,
netfilter-devel
In-Reply-To: <alpine.DEB.2.00.1003232050540.18241@blackhole.kfki.hu>
Hello,
Jozsef Kadlecsik a écrit :
>
> On Wed, 24 Mar 2010, YOSHIFUJI Hideaki wrote:
>
>>> In this case without conntrack, IPv6 would send an ICMPv6 message,
>>> so in my opinion the transparent thing to do would be to still send
>>> them. Of course only if reassembly is done on an end host.
>> Well, no. conntrack should just forward even uncompleted fragments
>> to next process (e.g. core ipv6 code), and then the core would send
>> ICMP error back. ICMP should be sent by the core ipv6 code according
>> to decision of itself, not according to netfilter.
>
> But what state could be associated by conntrack to the uncompleted
> fragments but the INVALID state? In consequence, in any sane setup, the
> uncompleted fragments will be dropped silently by a filter table rule
> and no ICMP error message will be sent back.
AFAIK, in the IPv4 stack the reassembly takes place before the INPUT
chains (NF_IP_LOCAL_IN hook). Is it different in the IPv6 stack ?
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC PATCH net-next 0/7 v2]IPv6:netfilter: defragment
From: Shan Wei @ 2010-03-25 9:13 UTC (permalink / raw)
To: Pascal Hambourg
Cc: Jozsef Kadlecsik, YOSHIFUJI Hideaki, Patrick McHardy,
David Miller, Alexey Dobriyan, Yasuyuki KOZAKAI,
netdev@vger.kernel.org, netfilter-devel
In-Reply-To: <4BAB2121.2030503@plouf.fr.eu.org>
Pascal Hambourg wrote, at 03/25/2010 04:38 PM:
> Hello,
>
> Jozsef Kadlecsik a écrit :
>> On Wed, 24 Mar 2010, YOSHIFUJI Hideaki wrote:
>>
>>>> In this case without conntrack, IPv6 would send an ICMPv6 message,
>>>> so in my opinion the transparent thing to do would be to still send
>>>> them. Of course only if reassembly is done on an end host.
>>> Well, no. conntrack should just forward even uncompleted fragments
>>> to next process (e.g. core ipv6 code), and then the core would send
>>> ICMP error back. ICMP should be sent by the core ipv6 code according
>>> to decision of itself, not according to netfilter.
>> But what state could be associated by conntrack to the uncompleted
>> fragments but the INVALID state? In consequence, in any sane setup, the
>> uncompleted fragments will be dropped silently by a filter table rule
>> and no ICMP error message will be sent back.
>
> AFAIK, in the IPv4 stack the reassembly takes place before the INPUT
> chains (NF_IP_LOCAL_IN hook). Is it different in the IPv6 stack ?
Yes, they are different.
In IPv4 stack，for an end host, ip_local_deliver() reassemble
fragments before LOCAL_IN hook .
But in IPv6 stack, ip6_input_finish() handles fragment extension headers
and try to reassemble them *after* LOCAL_IN hook.
--
Best Regards
-----
Shan Wei
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
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