* Re: Handling receive packets with limited buffer space
From: Andi Kleen @ 2010-03-20 15:01 UTC (permalink / raw)
To: Amit Uttamchandani; +Cc: netdev
In-Reply-To: <20100319094118.GA30249@debian>
Amit Uttamchandani <amit.uttam@gmail.com> writes:
> In my modified ethoc.c driver, I am using only one receive buffer
> descriptor due to limited space. This works fairly well for small
> packets (arp, pings, etc.).
>
> However, doing a 'wget' and downloading a file causes lots of drops and
> thus results in a terminated connection.
>
> How do I go about dealing with this? I tried stopping the queue
> (netif_stop_queue) while I'm processing the rx skb and then resuming it
> once I'm done, but this did not seem to help.
>
> Any ideas on this?
You'll need to allocate a new skb and copy into it before
passing the data up the stack.
-Andi
--
ak@linux.intel.com -- Speaking for myself only.
^ permalink raw reply
* Re: [PATCH] ip_gre: include route header_len in max_headroom calculation
From: Herbert Xu @ 2010-03-20 15:00 UTC (permalink / raw)
To: Timo Teräs; +Cc: netdev
In-Reply-To: <4BA4E000.1030206@iki.fi>
On Sat, Mar 20, 2010 at 04:47:28PM +0200, Timo Teräs wrote:
>
> Actually, isn't the above right?
>
> max_headroom is calculated with LL_RESERVED_SPACE of the tdev, which
> is the interface to which the gre packet is being sent to, not the
> gre interface. Thus, max_headroom won't include gre devices
> previous needed_headroom.
Indeed you're right. Sorry for the confusion.
Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] ip_gre: include route header_len in max_headroom calculation
From: Timo Teräs @ 2010-03-20 14:47 UTC (permalink / raw)
To: Herbert Xu; +Cc: netdev
In-Reply-To: <4BA4C2ED.9090701@iki.fi>
Timo Teräs wrote:
> Herbert Xu wrote:
>> On Sat, Mar 20, 2010 at 02:27:58PM +0200, Timo Teras wrote:
>>> diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
>>> index f47c9f7..f78402d 100644
>>> --- a/net/ipv4/ip_gre.c
>>> +++ b/net/ipv4/ip_gre.c
>>> @@ -810,11 +810,13 @@ static netdev_tx_t ipgre_tunnel_xmit(struct
>>> sk_buff *skb, struct net_device *dev
>>> tunnel->err_count = 0;
>>> }
>>>
>>> - max_headroom = LL_RESERVED_SPACE(tdev) + gre_hlen;
>>> + max_headroom = LL_RESERVED_SPACE(tdev) + gre_hlen +
>>> rt->u.dst.header_len;
>>>
>>> if (skb_headroom(skb) < max_headroom || skb_shared(skb)||
>>> (skb_cloned(skb) && !skb_clone_writable(skb, 0))) {
>>> struct sk_buff *new_skb = skb_realloc_headroom(skb,
>>> max_headroom);
>>> + if (max_headroom > dev->needed_headroom)
>>> + dev->needed_headroom = max_headroom;
>>
>> Are you sure about this? LL_RESERVED_SPACE already includes
>> dev->needed_headroom so won't this get bigger each time?
>
> Whoops. Must've been after-midnight issue. And not noticed since the
> max_headroom won't change many times.
>
> dev->needed_headroom should be compared against
> gre_hlen+rt->u.dst.header_len.
> I'll send a fixed patch in a jiffy.
Actually, isn't the above right?
max_headroom is calculated with LL_RESERVED_SPACE of the tdev, which
is the interface to which the gre packet is being sent to, not the
gre interface. Thus, max_headroom won't include gre devices
previous needed_headroom.
- Timo
^ permalink raw reply
* Re: [PATCH] xfrm: implement basic garbage collection for bundles
From: Timo Teräs @ 2010-03-20 13:34 UTC (permalink / raw)
To: Herbert Xu; +Cc: netdev, Neil Horman
In-Reply-To: <20100320131340.GB2243@gondor.apana.org.au>
Herbert Xu wrote:
> On Sat, Mar 20, 2010 at 02:54:31PM +0200, Timo Teräs wrote:
>> Those are more or less timer based too. I guess it would be
>> better to put to dst core's function then. It can see hanging
>> refs, and call xfrm gc in that case.
>
> The IPv4 one appears to be invoked from dst_alloc just like
> xfrm.
Yes. But under normal circumstances that's not used. It also
has a separate timer based gc that goes through the buckets
periodically. That e.g. how the expired pmtu routes are kicked
out and how routes with old genid are purged before we start
to reach the gc_thresh limit. This happens in
rt_worker_func() which is called every ip_rt_gc_interval
(defaults to one minute).
>> To even minimize that it would help a lot if xfrm_bundle_ok
>> could release (or swap to dummies) the referenced dst->route
>> and dst->child entries. xfrm_bundle_ok is mostly called for
>> all bundles regularly by xfrm_find_bundle before new ones are
>> created.
>
> Yes I agree that's what we should do once your other patch is
> applied.
>
> So every top-level xfrm_dst that's not referenced by some user
> should sit in the flow cache. When it's needed and we find it
> to be stale we kick it out of the cache and free it along with
> the rest of its constituents.
Right. Ok, just to get road map of what I should do and in which
order and how.
xfrm gc:
- should dst core call it?
- should xfrm do it periodically?
- or do we rely that we get new bundles and let
xfrm[46]_find_bundle do the clean up?
- should xfrm_bundle_ok() release the inner dst's right away
instead of waiting any of the above to happen?
caching of bundles instead of policies for outgoing traffic:
- should flow cache be per-netns?
- since it will now have two types of objects, would it make
sense to have virtual put and get callbacks instead of
atomic_t pointer. this way qw can BUG_ON() if the refcount
goes to zero unexpectedly (or call the appropriate destructor)
and call the real _put function anway (e.g. dst_release does
WARN_ON stuff); the _get function can also do additional
checking if the object is valid or not; this way the flow
cache resolver output is always a valid object
- resolver to have "resolve_fast" and "resolve_slow". if fast
fails, the slow gets called with bh enabled so it can sleep,
since bundle creation needs that.
- it would probably be then useful to have dummy xfrm_dst for
policy reference when the policy forbids traffic?
- Timo
^ permalink raw reply
* Re: [PATCH] xfrm: implement basic garbage collection for bundles
From: Neil Horman @ 2010-03-20 13:26 UTC (permalink / raw)
To: Herbert Xu; +Cc: Timo Teras, netdev
In-Reply-To: <20100320123247.GB1930@gondor.apana.org.au>
On Sat, Mar 20, 2010 at 08:32:48PM +0800, Herbert Xu wrote:
> On Sat, Mar 20, 2010 at 02:15:41PM +0200, Timo Teras wrote:
> > The dst core calls garbage collection only from dst_alloc when
> > the dst entry threshold is exceeded. Xfrm core currently checks
> > bundles only on NETDEV_DOWN event.
> >
> > Previously this has not been a big problem since xfrm gc threshold
> > was small, and they were generated all the time due to another bug.
> >
> > Since after a33bc5c15154c835aae26f16e6a3a7d9ad4acb45
> > ("xfrm: select sane defaults for xfrm[4|6] gc_thresh") we can have
> > large gc threshold sizes (>200000 on machines with normal amount
> > of memory) the garbage collection does not get triggered under
> > normal circumstances. This can result in enormous amount of stale
> > bundles. Further more, each of these stale bundles keep a reference
> > to ipv4/ipv6 rtable entries which are already gargage collected and
> > put to dst core "destroy free'd dst's" list. Now this list can grow
> > to be very large, and the dst core periodic job can bring even a fast
> > machine to it's knees.
>
> So why do we need this larger threshold in the first place? Neil?
My initial reasoning is here:
http://git.kernel.org/?p=linux/kernel/git/davem/net-next-2.6.git;a=commit;h=a33bc5c15154c835aae26f16e6a3a7d9ad4acb45
I'd had a bug claiming that ipsec didn't scale to thousands of SA's, and the
reason turned out to be that xfrm code capped their entry threshold at 1024
entries:
https://bugzilla.redhat.com/show_bug.cgi?id=253053
I exported the gc thresholds via sysctls, and then used the above commit to
select sane values, reasoning that we should be able to support as many tunnels
as routes when possible.
If its too high, I have no qualm with lowering it, given that those that need it
can bump it up higher via the sysctl.
Regards
Neil
> --
> Visit Openswan at http://www.openswan.org/
> Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
>
>
^ permalink raw reply
* Re: [PATCH] xfrm: implement basic garbage collection for bundles
From: Herbert Xu @ 2010-03-20 13:13 UTC (permalink / raw)
To: Timo Teräs; +Cc: netdev, Neil Horman
In-Reply-To: <4BA4C587.60504@iki.fi>
On Sat, Mar 20, 2010 at 02:54:31PM +0200, Timo Teräs wrote:
>
> Those are more or less timer based too. I guess it would be
> better to put to dst core's function then. It can see hanging
> refs, and call xfrm gc in that case.
The IPv4 one appears to be invoked from dst_alloc just like
xfrm.
> To even minimize that it would help a lot if xfrm_bundle_ok
> could release (or swap to dummies) the referenced dst->route
> and dst->child entries. xfrm_bundle_ok is mostly called for
> all bundles regularly by xfrm_find_bundle before new ones are
> created.
Yes I agree that's what we should do once your other patch is
applied.
So every top-level xfrm_dst that's not referenced by some user
should sit in the flow cache. When it's needed and we find it
to be stale we kick it out of the cache and free it along with
the rest of its constituents.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] xfrm: implement basic garbage collection for bundles
From: Timo Teräs @ 2010-03-20 12:54 UTC (permalink / raw)
To: Herbert Xu; +Cc: netdev, Neil Horman
In-Reply-To: <20100320124919.GA2243@gondor.apana.org.au>
Herbert Xu wrote:
> On Sat, Mar 20, 2010 at 02:42:02PM +0200, Timo Teräs wrote:
>> But even if we have the gc_thresh back to 1024 or similar size,
>> it is still a good thing to do some basic gc on xfrm bundles so
>> that the underlaying rtable dst's can be freed before they end up
>> in the dst core list.
>
> But I'm not sure if a timer-based one really makes sense though.
>
> If you're worried about stale entries preventing IPv4/IPv6 rt
> entries from being collected, perhaps we should invoke the xfrm
> GC process from the IPv4/IPv6 GC function?
Those are more or less timer based too. I guess it would be
better to put to dst core's function then. It can see hanging
refs, and call xfrm gc in that case.
To even minimize that it would help a lot if xfrm_bundle_ok
could release (or swap to dummies) the referenced dst->route
and dst->child entries. xfrm_bundle_ok is mostly called for
all bundles regularly by xfrm_find_bundle before new ones are
created.
- Timo
^ permalink raw reply
* Re: [PATCH] xfrm: implement basic garbage collection for bundles
From: Herbert Xu @ 2010-03-20 12:49 UTC (permalink / raw)
To: Timo Teräs; +Cc: netdev, Neil Horman
In-Reply-To: <4BA4C29A.8000806@iki.fi>
On Sat, Mar 20, 2010 at 02:42:02PM +0200, Timo Teräs wrote:
>
> But even if we have the gc_thresh back to 1024 or similar size,
> it is still a good thing to do some basic gc on xfrm bundles so
> that the underlaying rtable dst's can be freed before they end up
> in the dst core list.
But I'm not sure if a timer-based one really makes sense though.
If you're worried about stale entries preventing IPv4/IPv6 rt
entries from being collected, perhaps we should invoke the xfrm
GC process from the IPv4/IPv6 GC function?
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] ip_gre: include route header_len in max_headroom calculation
From: Timo Teräs @ 2010-03-20 12:43 UTC (permalink / raw)
To: Herbert Xu; +Cc: netdev
In-Reply-To: <20100320123736.GC1930@gondor.apana.org.au>
Herbert Xu wrote:
> On Sat, Mar 20, 2010 at 02:27:58PM +0200, Timo Teras wrote:
>> diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
>> index f47c9f7..f78402d 100644
>> --- a/net/ipv4/ip_gre.c
>> +++ b/net/ipv4/ip_gre.c
>> @@ -810,11 +810,13 @@ static netdev_tx_t ipgre_tunnel_xmit(struct sk_buff *skb, struct net_device *dev
>> tunnel->err_count = 0;
>> }
>>
>> - max_headroom = LL_RESERVED_SPACE(tdev) + gre_hlen;
>> + max_headroom = LL_RESERVED_SPACE(tdev) + gre_hlen + rt->u.dst.header_len;
>>
>> if (skb_headroom(skb) < max_headroom || skb_shared(skb)||
>> (skb_cloned(skb) && !skb_clone_writable(skb, 0))) {
>> struct sk_buff *new_skb = skb_realloc_headroom(skb, max_headroom);
>> + if (max_headroom > dev->needed_headroom)
>> + dev->needed_headroom = max_headroom;
>
> Are you sure about this? LL_RESERVED_SPACE already includes
> dev->needed_headroom so won't this get bigger each time?
Whoops. Must've been after-midnight issue. And not noticed since the
max_headroom won't change many times.
dev->needed_headroom should be compared against gre_hlen+rt->u.dst.header_len.
I'll send a fixed patch in a jiffy.
- timo
^ permalink raw reply
* Re: [PATCH] xfrm: implement basic garbage collection for bundles
From: Timo Teräs @ 2010-03-20 12:42 UTC (permalink / raw)
To: Herbert Xu; +Cc: netdev, Neil Horman
In-Reply-To: <20100320123247.GB1930@gondor.apana.org.au>
Herbert Xu wrote:
> On Sat, Mar 20, 2010 at 02:15:41PM +0200, Timo Teras wrote:
>> The dst core calls garbage collection only from dst_alloc when
>> the dst entry threshold is exceeded. Xfrm core currently checks
>> bundles only on NETDEV_DOWN event.
>>
>> Previously this has not been a big problem since xfrm gc threshold
>> was small, and they were generated all the time due to another bug.
>>
>> Since after a33bc5c15154c835aae26f16e6a3a7d9ad4acb45
>> ("xfrm: select sane defaults for xfrm[4|6] gc_thresh") we can have
>> large gc threshold sizes (>200000 on machines with normal amount
>> of memory) the garbage collection does not get triggered under
>> normal circumstances. This can result in enormous amount of stale
>> bundles. Further more, each of these stale bundles keep a reference
>> to ipv4/ipv6 rtable entries which are already gargage collected and
>> put to dst core "destroy free'd dst's" list. Now this list can grow
>> to be very large, and the dst core periodic job can bring even a fast
>> machine to it's knees.
>
> So why do we need this larger threshold in the first place? Neil?
Actually it looks like that on ipv6 side the gc_thresh is something
more normal. On ipv4 side it's insanely big. The 1/2 ratio is not
what ipv4 rtable uses for it's own gc_thresh. Looks like it's using
1/16 ratio which yields much better value.
But even if we have the gc_thresh back to 1024 or similar size,
it is still a good thing to do some basic gc on xfrm bundles so
that the underlaying rtable dst's can be freed before they end up
in the dst core list.
- Timo
^ permalink raw reply
* Re: [PATCH] ip_gre: include route header_len in max_headroom calculation
From: Herbert Xu @ 2010-03-20 12:37 UTC (permalink / raw)
To: Timo Teras; +Cc: netdev
In-Reply-To: <1269088078-7343-1-git-send-email-timo.teras@iki.fi>
On Sat, Mar 20, 2010 at 02:27:58PM +0200, Timo Teras wrote:
>
> diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
> index f47c9f7..f78402d 100644
> --- a/net/ipv4/ip_gre.c
> +++ b/net/ipv4/ip_gre.c
> @@ -810,11 +810,13 @@ static netdev_tx_t ipgre_tunnel_xmit(struct sk_buff *skb, struct net_device *dev
> tunnel->err_count = 0;
> }
>
> - max_headroom = LL_RESERVED_SPACE(tdev) + gre_hlen;
> + max_headroom = LL_RESERVED_SPACE(tdev) + gre_hlen + rt->u.dst.header_len;
>
> if (skb_headroom(skb) < max_headroom || skb_shared(skb)||
> (skb_cloned(skb) && !skb_clone_writable(skb, 0))) {
> struct sk_buff *new_skb = skb_realloc_headroom(skb, max_headroom);
> + if (max_headroom > dev->needed_headroom)
> + dev->needed_headroom = max_headroom;
Are you sure about this? LL_RESERVED_SPACE already includes
dev->needed_headroom so won't this get bigger each time?
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] xfrm: implement basic garbage collection for bundles
From: Herbert Xu @ 2010-03-20 12:32 UTC (permalink / raw)
To: Timo Teras; +Cc: netdev, Neil Horman
In-Reply-To: <1269087341-7009-1-git-send-email-timo.teras@iki.fi>
On Sat, Mar 20, 2010 at 02:15:41PM +0200, Timo Teras wrote:
> The dst core calls garbage collection only from dst_alloc when
> the dst entry threshold is exceeded. Xfrm core currently checks
> bundles only on NETDEV_DOWN event.
>
> Previously this has not been a big problem since xfrm gc threshold
> was small, and they were generated all the time due to another bug.
>
> Since after a33bc5c15154c835aae26f16e6a3a7d9ad4acb45
> ("xfrm: select sane defaults for xfrm[4|6] gc_thresh") we can have
> large gc threshold sizes (>200000 on machines with normal amount
> of memory) the garbage collection does not get triggered under
> normal circumstances. This can result in enormous amount of stale
> bundles. Further more, each of these stale bundles keep a reference
> to ipv4/ipv6 rtable entries which are already gargage collected and
> put to dst core "destroy free'd dst's" list. Now this list can grow
> to be very large, and the dst core periodic job can bring even a fast
> machine to it's knees.
So why do we need this larger threshold in the first place? Neil?
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <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
* [PATCH] ip_gre: include route header_len in max_headroom calculation
From: Timo Teras @ 2010-03-20 12:27 UTC (permalink / raw)
To: netdev; +Cc: Timo Teras, Herbert Xu
Taking route's header_len into account, and updating gre device
needed_headroom will give better hints on upper bound of required
headroom. This is useful if the gre traffic is xfrm'ed.
Signed-off-by: Timo Teras <timo.teras@iki.fi>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
---
net/ipv4/ip_gre.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
This was earlier discussed in netdev thread:
http://marc.info/?t=124470870200004&r=1&w=2
I just never got to writing the patch until now.
diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
index f47c9f7..f78402d 100644
--- a/net/ipv4/ip_gre.c
+++ b/net/ipv4/ip_gre.c
@@ -810,11 +810,13 @@ static netdev_tx_t ipgre_tunnel_xmit(struct sk_buff *skb, struct net_device *dev
tunnel->err_count = 0;
}
- max_headroom = LL_RESERVED_SPACE(tdev) + gre_hlen;
+ max_headroom = LL_RESERVED_SPACE(tdev) + gre_hlen + rt->u.dst.header_len;
if (skb_headroom(skb) < max_headroom || skb_shared(skb)||
(skb_cloned(skb) && !skb_clone_writable(skb, 0))) {
struct sk_buff *new_skb = skb_realloc_headroom(skb, max_headroom);
+ if (max_headroom > dev->needed_headroom)
+ dev->needed_headroom = max_headroom;
if (!new_skb) {
ip_rt_put(rt);
txq->tx_dropped++;
--
1.6.3.3
^ permalink raw reply related
* [PATCH] xfrm: implement basic garbage collection for bundles
From: Timo Teras @ 2010-03-20 12:15 UTC (permalink / raw)
To: netdev; +Cc: Timo Teras, Neil Horman, Herbert Xu
The dst core calls garbage collection only from dst_alloc when
the dst entry threshold is exceeded. Xfrm core currently checks
bundles only on NETDEV_DOWN event.
Previously this has not been a big problem since xfrm gc threshold
was small, and they were generated all the time due to another bug.
Since after a33bc5c15154c835aae26f16e6a3a7d9ad4acb45
("xfrm: select sane defaults for xfrm[4|6] gc_thresh") we can have
large gc threshold sizes (>200000 on machines with normal amount
of memory) the garbage collection does not get triggered under
normal circumstances. This can result in enormous amount of stale
bundles. Further more, each of these stale bundles keep a reference
to ipv4/ipv6 rtable entries which are already gargage collected and
put to dst core "destroy free'd dst's" list. Now this list can grow
to be very large, and the dst core periodic job can bring even a fast
machine to it's knees.
Signed-off-by: Timo Teras <timo.teras@iki.fi>
Cc: Neil Horman <nhorman@tuxdriver.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
---
net/xfrm/xfrm_policy.c | 20 +++++++++++++++++++-
1 files changed, 19 insertions(+), 1 deletions(-)
diff --git a/net/xfrm/xfrm_policy.c b/net/xfrm/xfrm_policy.c
index 843e066..f3f3d36 100644
--- a/net/xfrm/xfrm_policy.c
+++ b/net/xfrm/xfrm_policy.c
@@ -44,6 +44,9 @@ static struct xfrm_policy_afinfo *xfrm_policy_afinfo[NPROTO];
static struct kmem_cache *xfrm_dst_cache __read_mostly;
+static int xfrm_gc_interval __read_mostly = 5 * 60 * HZ;
+static struct delayed_work expires_work;
+
static HLIST_HEAD(xfrm_policy_gc_list);
static DEFINE_SPINLOCK(xfrm_policy_gc_lock);
@@ -2203,6 +2206,16 @@ static int xfrm_flush_bundles(struct net *net)
return 0;
}
+static void xfrm_gc_worker_func(struct work_struct *work)
+{
+ struct net *net;
+
+ for_each_net(net)
+ xfrm_flush_bundles(net);
+
+ schedule_delayed_work(&expires_work, xfrm_gc_interval);
+}
+
static void xfrm_init_pmtu(struct dst_entry *dst)
{
do {
@@ -2498,8 +2511,13 @@ static int __net_init xfrm_policy_init(struct net *net)
INIT_LIST_HEAD(&net->xfrm.policy_all);
INIT_WORK(&net->xfrm.policy_hash_work, xfrm_hash_resize);
- if (net_eq(net, &init_net))
+ if (net_eq(net, &init_net)) {
register_netdevice_notifier(&xfrm_dev_notifier);
+
+ INIT_DELAYED_WORK_DEFERRABLE(&expires_work, xfrm_gc_worker_func);
+ schedule_delayed_work(&expires_work,
+ net_random() % xfrm_gc_interval + xfrm_gc_interval);
+ }
return 0;
out_bydst:
--
1.6.3.3
^ permalink raw reply related
* Re: lartc is dead?
From: ctxspi @ 2010-03-20 12:04 UTC (permalink / raw)
To: netdev; +Cc: ahu
Hi, my name is Marco.
I want know how I can have help for small question about bug (nexthdr in u32).
Can you give me a small help?
Thanks
^ permalink raw reply
* Re: [patch] bridge: cleanup: remove unused assignment
From: Herbert Xu @ 2010-03-20 11:57 UTC (permalink / raw)
To: Dan Carpenter
Cc: David S. Miller, Stephen Hemminger, YOSHIFUJI Hideaki,
Paul E. McKenney, Michael Braun, bridge, netdev, kernel-janitors
In-Reply-To: <20100320112049.GU5331@bicker>
On Sat, Mar 20, 2010 at 02:20:49PM +0300, Dan Carpenter wrote:
> We never actually use iph again so this assignment can be removed.
>
> Signed-off-by: Dan Carpenter <error27@gmail.com>
Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <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
* [patch] bridge: cleanup: remove unused assignment
From: Dan Carpenter @ 2010-03-20 11:20 UTC (permalink / raw)
To: Herbert Xu
Cc: David S. Miller, Stephen Hemminger, YOSHIFUJI Hideaki,
Paul E. McKenney, Michael Braun, bridge, netdev, kernel-janitors
We never actually use iph again so this assignment can be removed.
Signed-off-by: Dan Carpenter <error27@gmail.com>
diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c
index 6980625..9f0c4f0 100644
--- a/net/bridge/br_multicast.c
+++ b/net/bridge/br_multicast.c
@@ -1003,8 +1003,6 @@ static int br_multicast_ipv4_rcv(struct net_bridge *br,
if (!pskb_may_pull(skb2, sizeof(*ih)))
goto out;
- iph = ip_hdr(skb2);
-
switch (skb2->ip_summed) {
case CHECKSUM_COMPLETE:
if (!csum_fold(skb2->csum))
^ permalink raw reply related
* LRO (Large Receice Offload) and UDP
From: Mark Ryden @ 2010-03-20 11:15 UTC (permalink / raw)
To: netdev; +Cc: themann
Hello,
I have a question about LRO ("Large Receive Offload") and I will
appreciate if somebody can answer in short (for me, 2-3 sentences are
enough). I have
noticed that LRO handles only TCP packets. Thus, the TCP flag is checked and
non TCP packets are not handled by LRO.
(see the check of LRO_TCP in __lro_proc_skb(), net/ipv4/inet_lro.c).
My question is: why can't the LRO mechanism be applied to UDP ? Or can
it be applied, but is not implemented yet or does not worth to be applied ?
Rgs,
Mark
^ permalink raw reply
* Re: [PATCH 2/3] can: add support for Janz VMOD-ICAN3 Intelligent CAN module
From: Wolfgang Grandegger @ 2010-03-20 7:55 UTC (permalink / raw)
To: Ira W. Snyder
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, sameo-VuQAYsv1563Yd54FQh9/CA
In-Reply-To: <20100319215227.GF13672-lulEs6mt1IksTUYHLfqkUA@public.gmane.org>
Ira W. Snyder wrote:
> On Fri, Mar 19, 2010 at 09:13:37PM +0100, Wolfgang Grandegger wrote:
>> Ira W. Snyder wrote:
>>> On Fri, Mar 19, 2010 at 04:45:09PM +0100, Wolfgang Grandegger wrote:
>>>> Ira W. Snyder wrote:
>>>>> On Fri, Mar 19, 2010 at 10:01:14AM +0100, Wolfgang Grandegger wrote:
>>>>>> Hi Ira,
>>>>>>
>>>>>> we already discussed this patch on the SocketCAN mailing list and there
>>>>>> are just a few minor issues and the request to add support for the new
>>>>>> "berr-reporting" option, if feasible. See:
>>>>>>
>>>>>> commit 52c793f24054f5dc30d228e37e0e19cc8313f086
>>>>>> Author: Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
>>>>>> Date: Mon Feb 22 22:21:17 2010 +0000
>>>>>>
>>>>>> can: netlink support for bus-error reporting and counters
>>>>>>
>>>>>> This patch makes the bus-error reporting configurable and allows to
>>>>>> retrieve the CAN TX and RX bus error counters via netlink interface.
>>>>>> I have added support for the SJA1000. The TX and RX bus error counters
>>>>>> are also copied to the data fields 6..7 of error messages when state
>>>>>> changes are reported.
>>>>>>
>>>>>> Should not be a big deal.
>>>>>>
>>>>> I think this patch came along since my last post of the driver. I must
>>>>> have missed it. I'll try and add support.
>>>> No problem, it's really new. Just just need to enable BEI depending on
>>>> CAN_CTRLMODE_BERR_REPORTING.
>>>>
>>> I have one final question about this.
>>>
>>> The documentation for the firmware isn't very specific here. I believe
>>> that in order to get any kind of error messages, I need the bus error
>>> feature turned on. What is the expected behavior of an SJA1000 with the
>>> BEI (bus error interrupt) turned off? Will you still get warning
>>> messages for ERROR_ACTIVE -> ERROR_PASSIVE state transitions?
>> Yes. State transitions are enabled with EI and EPI.
>>
>
> I cannot set the registers directly, but I think I got it right. See
> below.
>
>>> I'm not sure how I would go about testing this feature, either. Ideas?
>> Send messages without cable connected and watch the error messages with
>> "candump any,0:0,#ffffffff". With "ip ... berr-reporting on" you should
>> see additional bus-errors.
>>
>
> Ok, I tried this. On one controller, I turned on bus-error reporting. On
> the other, I turn off bus-error reporting. I then tried sending lots of
> messages with the cable unplugged. Here is what happened:
>
> bus-error reporting on:
> Lots of CAN_ERR_BUSERR messages are flooded in candump. There is also a
> CAN_ERR_CRTL_TX_WARNING message, when there are too many TX errors.
OK, you will now also understand why bus-error reporting is off by
default. On low-end systems bus-error flooding may even hang the system.
> bus-error reporting off:
> There was only one message reported before the controller went into
> ERROR-WARNING state. It was the same CAN_ERR_CRTL_TX_WARNING message as
> above. There was no flooding of CAN_ERR_BUSERR messages.
>
> Does this seem right? It seems pretty good to me.
Yes, I'm just missing an error-passive message. What state does "ip -d
link show can0" report.
>>> I also noticed that I can enable "self test mode" and "listen only mode"
>>> using the same firmware command. It appears that there are netlink
>>> messages for this as well. Should I try and support these, too? I don't
>>> really have any use for them (yet). I assume "self test mode" is
>>> equivalent to "loopback mode" in the netlink messages.
>> List-only is straight forward while "self test mode" is not exactly like
>> "loopback mode", IIRC. Feel free to send a follow-up patch when you have
>> time for a thorough implementation and testing. It's also on my to-do
>> list for the SJA1000.
>>
>
> Ok, then I'll put this off for a while. Feel free to pester me about it
> when there is a working implementation in the SJA1000 driver for me to
> borrow from. :)
I will let you know when I have something working.
Wolfgang.
^ permalink raw reply
* Re: [PATCH 00/12] l2tp: Introduce L2TPv3 support
From: David Miller @ 2010-03-20 6:23 UTC (permalink / raw)
To: jchapman; +Cc: netdev
In-Reply-To: <20100318102127.14576.98388.stgit@bert.katalix.com>
Doesn't even build:
net/l2tp/l2tp_ip.c:600: error: ‘compat_udp_setsockopt’ undeclared here (not in a function)
net/l2tp/l2tp_ip.c:601: error: ‘compat_udp_getsockopt’ undeclared here (not in a function)
You can't do this like this, as the header providing these
declarations is private to net/ipv4/
Respin your entire patch set once you've resolved this and
also please fix these fundamental whitespace errors emitted
by git when I apply your patches:
Applying: l2tp: Relocate pppol2tp driver to new net/l2tp directory
Applying: l2tp: Split pppol2tp driver into separate l2tp and ppp parts
/home/davem/src/GIT/net-next-2.6/.git/rebase-apply/patch:118: new blank line at EOF.
+
/home/davem/src/GIT/net-next-2.6/.git/rebase-apply/patch:133: new blank line at EOF.
+
warning: 2 lines add whitespace errors.
Applying: ppp: Add ppp_dev_name() exported function
Applying: l2tp: Add ppp device name to L2TP ppp session data
Applying: l2tp: Add L2TPv3 protocol support
Applying: l2tp: Update PPP-over-L2TP driver to work over L2TPv3
Applying: l2tp: Add L2TPv3 IP encapsulation (no UDP) support
/home/davem/src/GIT/net-next-2.6/.git/rebase-apply/patch:61: new blank line at EOF.
+
warning: 1 line adds whitespace errors.
Applying: netlink: Export genl_lock() API for use by modules
Applying: l2tp: Add netlink control API for L2TP
Applying: l2tp: Add L2TP ethernet pseudowire support
/home/davem/src/GIT/net-next-2.6/.git/rebase-apply/patch:25: space before tab in indent.
used as a control protocol and for data encapsulation to set
/home/davem/src/GIT/net-next-2.6/.git/rebase-apply/patch:26: space before tab in indent.
up Pseudowires for transporting layer 2 Packet Data Units
/home/davem/src/GIT/net-next-2.6/.git/rebase-apply/patch:27: space before tab in indent.
across an IP network [RFC3931].
/home/davem/src/GIT/net-next-2.6/.git/rebase-apply/patch:12: new blank line at EOF.
+
warning: 4 lines add whitespace errors.
Applying: l2tp: Add support for static unmanaged L2TPv3 tunnels
Applying: l2tp: Update documentation
Thanks.
^ permalink raw reply
* Re: [PATCH] tcp: Fix tcp_mark_head_lost() with packets == 0
From: David Miller @ 2010-03-20 5:44 UTC (permalink / raw)
To: lennart.schulte; +Cc: netdev, ilpo.jarvinen, hannemann
In-Reply-To: <1268828189-22182-1-git-send-email-lennart.schulte@nets.rwth-aachen.de>
From: Lennart Schulte <lennart.schulte@nets.rwth-aachen.de>
Date: Wed, 17 Mar 2010 13:16:29 +0100
> A packet is marked as lost in case packets == 0, although nothing should be done.
> This results in a too early retransmitted packet during recovery in some cases.
> This small patch fixes this issue by returning immediately.
>
> Signed-off-by: Lennart Schulte <lennart.schulte@nets.rwth-aachen.de>
> Signed-off-by: Arnd Hannemann <hannemann@nets.rwth-aachen.de>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] net: ipmr/ip6mr: fix potential out-of-bounds vif_table access
From: David Miller @ 2010-03-20 5:44 UTC (permalink / raw)
To: kaber; +Cc: netdev
In-Reply-To: <4BA0FD7E.4050201@trash.net>
From: Patrick McHardy <kaber@trash.net>
Date: Wed, 17 Mar 2010 17:04:14 +0100
> My appologies for using git-show again. Correctly formatted
> patch attached.
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 3/3] netlink: fix unaligned access in nla_get_be64()
From: David Miller @ 2010-03-20 5:44 UTC (permalink / raw)
To: pablo; +Cc: netdev, kaber
In-Reply-To: <20100316233044.4185.69099.stgit@decadence>
From: Pablo Neira Ayuso <pablo@netfilter.org>
Date: Wed, 17 Mar 2010 00:30:44 +0100
> This patch fixes a unaligned access in nla_get_be64() that was
> introduced by myself in a17c859849402315613a0015ac8fbf101acf0cc1.
>
> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Applied.
^ permalink raw reply
* Re: [PATCH 1/1] KS8695: update ksp->next_rx_desc_read at the end of rx loop
From: David Miller @ 2010-03-20 5:44 UTC (permalink / raw)
To: yegorslists; +Cc: eric.dumazet, netdev
In-Reply-To: <f69abfc31003170240u717283egf2c66adfaaa9aca7@mail.gmail.com>
From: Yegor Yefremov <yegorslists@googlemail.com>
Date: Wed, 17 Mar 2010 10:40:10 +0100
> KS8695: update ksp->next_rx_desc_read at the end of rx loop
>
> There is no need to adjust the next rx descriptor after each packet,
> so do it only once at the end of the routine.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] igb: Add support for 82576 ET2 Quad Port Server Adapter
From: David Miller @ 2010-03-20 4:11 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, carolyn.wyborny
In-Reply-To: <20100319160747.10902.61121.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Fri, 19 Mar 2010 09:07:48 -0700
> From: Carolyn Wyborny <carolyn.wyborny@intel.com>
>
> Signed-off-by: Carolyn Wyborny <carolyn.wyborny@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied, thanks.
^ 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