* Re: [RFC PATCH net-next 0/7 v2]IPv6:netfilter: defragment
From: Patrick McHardy @ 2010-03-23 17:16 UTC (permalink / raw)
To: YOSHIFUJI Hideaki
Cc: Shan Wei, YOSHIFUJI Hideaki, David Miller, Alexey Dobriyan,
Yasuyuki KOZAKAI, netdev@vger.kernel.org, netfilter-devel
In-Reply-To: <4BA8EC4A.9070802@linux-ipv6.org>
YOSHIFUJI Hideaki wrote:
> Hello.
>
> Sorry for my slow response.
>
> (2010/03/16 1:27), Patrick McHardy wrote:
>> YOSHIFUJI Hideaki wrote:
>>> (2010/03/11 18:16), 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.
>>>
>>> Please make it optional (via parameter) at least.
>>
>> The ICMP messages are only sent if the packet is destined for the
>> local host, similar to what IPv6 defrag would do if conntrack wouldn't
>> be used. So this patch increases consistency, why should we make this
>> optional?
>
> Well, in the first place, I do think conntrack should be
> transparent as much as possible. And, I cannot find other
> netfilter conntrack code (ipv4 or ipv6) sending icmp e.g.
> parameter problem etc.
Agreed on the transparent part, however I consider silently dropping
packets not transparent. In fact conntrack itself should never drop
packets except under some very special circumstances when there's
no other choice in order to operate correctly. Dropping packets is
supposed to be a policy decision made by the user.
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.
There's really no difference in sending these packets from conntrack
compared to passing the incomplete fragments upwards to IPv6 and
waiting for another timeout, except that its easier to implement
consistently by generating the packets within conntrack.
> As I said before, I agree that netfilter may drop packets
> by any reasons, but I do think it should be done silently.
> It can increment netfilter's own statistic counting etc.
> but it should not increment the core's (especially,
> specific) statistic counting.
It really depends on what you define as "transparent".
>
> Reassembling processes are the same. We should NOT send icmp, and
> if ever desired, we might optionally send icmp (in other
> module maybe).
Please see above for my reasoning. There's also the matter of consistency
between IPv4 and IPv6 conntrack.
^ permalink raw reply
* Re: [RFC PATCH net-next 0/7 v2]IPv6:netfilter: defragment
From: YOSHIFUJI Hideaki @ 2010-03-23 16:28 UTC (permalink / raw)
To: Patrick McHardy
Cc: Shan Wei, YOSHIFUJI Hideaki, David Miller, Alexey Dobriyan,
Yasuyuki KOZAKAI, netdev@vger.kernel.org, netfilter-devel,
YOSHIFUJI Hideaki
In-Reply-To: <4B9E5FEC.9010002@trash.net>
Hello.
Sorry for my slow response.
(2010/03/16 1:27), Patrick McHardy wrote:
> YOSHIFUJI Hideaki wrote:
>> (2010/03/11 18:16), 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.
>>
>> Please make it optional (via parameter) at least.
>
> The ICMP messages are only sent if the packet is destined for the
> local host, similar to what IPv6 defrag would do if conntrack wouldn't
> be used. So this patch increases consistency, why should we make this
> optional?
Well, in the first place, I do think conntrack should be
transparent as much as possible. And, I cannot find other
netfilter conntrack code (ipv4 or ipv6) sending icmp e.g.
parameter problem etc.
As I said before, I agree that netfilter may drop packets
by any reasons, but I do think it should be done silently.
It can increment netfilter's own statistic counting etc.
but it should not increment the core's (especially,
specific) statistic counting.
Reassembling processes are the same. We should NOT send icmp, and
if ever desired, we might optionally send icmp (in other
module maybe).
Regards,
--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: [PATCH] Fix locking in flush_backlog
From: Eric Dumazet @ 2010-03-23 16:14 UTC (permalink / raw)
To: Tom Herbert; +Cc: davem, netdev
In-Reply-To: <65634d661003230856v3d1737dehf64a883c1e785333@mail.gmail.com>
Le mardi 23 mars 2010 à 08:56 -0700, Tom Herbert a écrit :
> Eric,
>
> I'm not sure what you're asking. Do you just want to add spinlocks in
> the flush_backlog function without changing the mechanism to call the
> function on each CPU, or keep flush_backlog but call it from
> netdev_run_todo for each queue?
>
keep flush_backlog() so that its role is obvious and indentation level
not too big.
static void flush_backlog(int cpu)
{
struct softnet_data *queue = &per_cpu(softnet_data, cpu);
struct sk_buff *skb, *tmp;
unsigned long flags;
spin_lock_irqsave(&queue->input_pkt_queue.lock, flags);
skb_queue_walk_safe(&queue->input_pkt_queue, skb, tmp)
if (skb->dev == dev) {
__skb_unlink(skb, &queue->input_pkt_queue);
kfree_skb(skb);
}
spin_unlock_irqrestore(&queue->input_pkt_queue.lock, flags);
}
And call it from netdev_run_todo() :
for_each_online_cpu(i)
flush_backlog(i);
This adds two lines to netdev_run_todo() only.
Thanks
^ permalink raw reply
* Re: [PATCH] Fix locking in flush_backlog
From: Tom Herbert @ 2010-03-23 15:56 UTC (permalink / raw)
To: Eric Dumazet; +Cc: davem, netdev
In-Reply-To: <1269325757.3043.11.camel@edumazet-laptop>
On Mon, Mar 22, 2010 at 11:29 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le lundi 22 mars 2010 à 23:04 -0700, Tom Herbert a écrit :
>> Need to take spinlocks when dequeuing from input_pkt_queue in
>> flush_backlog. Also, with the spinlock the backlog queues can
>> be flushed directly from netdev_run_todo.
>>
>> Signed-off-by: Tom Herbert <therbert@google.com>
>> ---
>> diff --git a/net/core/dev.c b/net/core/dev.c
>> index a03aab4..e7db656 100644
>> --- a/net/core/dev.c
>> +++ b/net/core/dev.c
>> @@ -2765,20 +2765,6 @@ int netif_receive_skb(struct sk_buff *skb)
>> }
>> EXPORT_SYMBOL(netif_receive_skb);
>>
>> -/* Network device is going away, flush any packets still pending */
>> -static void flush_backlog(void *arg)
>> -{
>> - struct net_device *dev = arg;
>> - struct softnet_data *queue = &__get_cpu_var(softnet_data);
>> - struct sk_buff *skb, *tmp;
>> -
>> - skb_queue_walk_safe(&queue->input_pkt_queue, skb, tmp)
>> - if (skb->dev == dev) {
>> - __skb_unlink(skb, &queue->input_pkt_queue);
>> - kfree_skb(skb);
>> - }
>> -}
>> -
>> static int napi_gro_complete(struct sk_buff *skb)
>> {
>> struct packet_type *ptype;
>> @@ -5545,6 +5531,7 @@ void netdev_run_todo(void)
>> while (!list_empty(&list)) {
>> struct net_device *dev
>> = list_first_entry(&list, struct net_device, todo_list);
>> + int i;
>> list_del(&dev->todo_list);
>>
>> if (unlikely(dev->reg_state != NETREG_UNREGISTERING)) {
>> @@ -5556,7 +5543,22 @@ void netdev_run_todo(void)
>>
>> dev->reg_state = NETREG_UNREGISTERED;
>>
>> - on_each_cpu(flush_backlog, dev, 1);
>> + /* Flush backlog queues of any pending packets */
>> + for_each_online_cpu(i) {
>> + struct softnet_data *queue = &per_cpu(softnet_data, i);
>> + struct sk_buff *skb, *tmp;
>> + unsigned long flags;
>> +
>> + spin_lock_irqsave(&queue->input_pkt_queue.lock, flags);
>> + skb_queue_walk_safe(&queue->input_pkt_queue, skb, tmp)
>> + if (skb->dev == dev) {
>> + __skb_unlink(skb,
>> + &queue->input_pkt_queue);
>> + kfree_skb(skb);
>> + }
>> + spin_unlock_irqrestore(&queue->input_pkt_queue.lock,
>> + flags);
>> + }
>>
>> netdev_wait_allrefs(dev);
>>
>
> OK (this is a patch for net-next-2.6)
>
> Could you please keep the function, to ease netdev_run_todo() review ?
>
Eric,
I'm not sure what you're asking. Do you just want to add spinlocks in
the flush_backlog function without changing the mechanism to call the
function on each CPU, or keep flush_backlog but call it from
netdev_run_todo for each queue?
Tom
^ permalink raw reply
* Re: [RFC PATCH net-next 0/7 v2]IPv6:netfilter: defragment
From: Patrick McHardy @ 2010-03-23 15:05 UTC (permalink / raw)
To: Shan Wei
Cc: YOSHIFUJI Hideaki, David Miller, Alexey Dobriyan,
Yasuyuki KOZAKAI, netdev@vger.kernel.org, netfilter-devel,
yoshfuji@linux-ipv6.org >> YOSHIFUJI Hideaki
In-Reply-To: <4B98B4FC.50904@cn.fujitsu.com>
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!
--
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
* [PATCH] ksz884x: fix return value of netdev_set_eeprom
From: Jens Rottmann @ 2010-03-23 14:23 UTC (permalink / raw)
To: David S. Miller; +Cc: Tristram Ha, netdev, linux-kernel
ksz884x: fix return value of netdev_set_eeprom
netdev_set_eeprom() confused ethtool by just returning 1 on error
instead of a proper -EINVAL.
Signed-off-by: Jens Rottmann <JRottmann@LiPPERTEmbedded.de>
---
--- linux-2.6.34-rc2-git1/drivers/net/ksz884x.c
+++ return_value_fixed/drivers/net/ksz884x.c
@@ -6322,7 +6322,7 @@ static int netdev_set_eeprom(struct net_
int len;
if (eeprom->magic != EEPROM_MAGIC)
- return 1;
+ return -EINVAL;
len = (eeprom->offset + eeprom->len + 1) / 2;
for (i = eeprom->offset / 2; i < len; i++)
_
^ permalink raw reply
* RE: Gianfar: RX Recycle skb->len error
From: Ben Menchaca (ben@bigfootnetworks.com) @ 2010-03-23 14:16 UTC (permalink / raw)
To: David Miller
Cc: avorontsov@ru.mvista.com, netdev@vger.kernel.org,
Sandeep.Kumar@freescale.com, kumar.gala@freescale.com
In-Reply-To: <20100322.203053.37576243.davem@davemloft.net>
> There's no need to make this so complicated. Just remember the
> value and then refer to it later, when needed.
Thanks for the sanity adjustment! As suggested, then...hope to hear from FS soon.
diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
index b671555..669de02 100644
--- a/drivers/net/gianfar.c
+++ b/drivers/net/gianfar.c
@@ -2393,6 +2393,7 @@ struct sk_buff * gfar_new_skb(struct net_device *dev)
* as many bytes as needed to align the data properly
*/
skb_reserve(skb, alignamount);
+ GFAR_CB(skb)->alignamount = alignamount;
return skb;
}
@@ -2533,13 +2534,13 @@ int gfar_clean_rx_ring(struct gfar_priv_rx_q *rx_queue, int rx_work_limit)
newskb = skb;
else if (skb) {
/*
- * We need to reset ->data to what it
+ * We need to un-reserve() the skb to what it
* was before gfar_new_skb() re-aligned
* it to an RXBUF_ALIGNMENT boundary
* before we put the skb back on the
* recycle list.
*/
- skb->data = skb->head + NET_SKB_PAD;
+ skb_reserve(skb, -GFAR_CB(skb)->alignamount);
__skb_queue_head(&priv->rx_recycle, skb);
}
} else {
diff --git a/drivers/net/gianfar.h b/drivers/net/gianfar.h
index 3d72dc4..3ae2c77 100644
--- a/drivers/net/gianfar.h
+++ b/drivers/net/gianfar.h
@@ -566,6 +566,12 @@ struct rxfcb {
u16 vlctl; /* VLAN control word */
};
+struct gfar_skb_cb {
+ int alignamount;
+};
+
+#define GFAR_CB(skb) ((struct gfar_skb_cb *)((skb)->cb))
+
struct rmon_mib
{
u32 tr64; /* 0x.680 - Transmit and Receive 64-byte Frame Counter */
^ permalink raw reply related
* Re: [PATCH] rps: make distributing packets fairly among all the online CPUs default
From: Andi Kleen @ 2010-03-23 14:05 UTC (permalink / raw)
To: Changli Gao
Cc: Eric Dumazet, David S. Miller, Tom Herbert, netdev, Ben Hutchings
In-Reply-To: <412e6f7f1003230303l69fc142ey1581fff4c3e749be@mail.gmail.com>
Changli Gao <xiaosuo@gmail.com> writes:
>
> I do think distributing packets fairly among all the online CPUs will
> helps most of users. I remember the smp_affinity of IRQ is the
> online_cpu_mask be default.
The established wisdom is that most apps prefer locality.
The cost of data transfer between CPUs is worse than the
overhead of processing the packet header in the stack.
That's why no system does interrupt RR by default anymore.
Besides if you do such a change you would need extensive benchmarking
to verify that it's a good idea.
-Andi
--
ak@linux.intel.com -- Speaking for myself only.
^ permalink raw reply
* [BUG] XFRM IS NOT UPDATING ETH TYPE FIELD FOR INNER PACKET ON ETH HEADER
From: Eduardo Panisset @ 2010-03-23 13:22 UTC (permalink / raw)
To: netdev
Hi,
Before doing this change wireshark was showing the inner packet as
"malformed" as it uses the ethernet's type field to classify the L3
packets as IPv6, IPv4 and so on.
The problem is when the inner packet is reinserted into Linux stack
and the ethernet header keeps holding on its type field a value for
the protocol of outer packet.
Below my correction on file net/xfrm/xfrm_input.c, function xfrm_prepare_input:
...
skb->protocol = inner_mode->afinfo->eth_proto; // existing code
eth_hdr(skb)->h_proto = skb->protocol; // my change, adding this line
...
Regards,
Eduardo Panisset.
^ permalink raw reply
* Re: [PATCH] rps: make distributing packets fairly among all the online CPUs default
From: Eric Dumazet @ 2010-03-23 13:06 UTC (permalink / raw)
To: Changli Gao; +Cc: David S. Miller, Tom Herbert, netdev, Ben Hutchings
In-Reply-To: <412e6f7f1003230458o459b9e45i7327c5330c43e152@mail.gmail.com>
Le mardi 23 mars 2010 à 19:58 +0800, Changli Gao a écrit :
> The sysadmins you mentioned above are Linux experters, and they know
> how to tunning the system to get the best performance, but the default
> configuration should be for the ordinary users, who don't know Linux
> much.
>
I strongly NACK your change at this very moment, many devices run
without a linux expert to tune them, thanks.
Ordinary users dont need RPS magic in 2.6.35.
Maybe in 2.6.38+ we can reconsider this, if RPS deployment happens to be
successful, thanks to experts doing their job and reports.
^ permalink raw reply
* Re: [RFC Patch 1/3] netpoll: add generic support for bridge and bonding devices
From: Jeff Moyer @ 2010-03-23 12:11 UTC (permalink / raw)
To: Matt Mackall
Cc: Amerigo Wang, linux-kernel, netdev, bridge, Andy Gospodarek,
Neil Horman, Stephen Hemminger, bonding-devel, Jay Vosburgh,
David Miller
In-Reply-To: <1269297081.3552.19.camel@calx>
Matt Mackall <mpm@selenic.com> writes:
> On Mon, 2010-03-22 at 04:17 -0400, Amerigo Wang wrote:
>> This whole patchset is for adding netpoll support to bridge and bonding
>> devices. I already tested it for bridge, bonding, bridge over bonding,
>> and bonding over bridge. It looks fine now.
>
> Ages ago, Jeff Moyer took a run at this, added him to the cc: on the off
> chance he still cares.
I'll take a look at it in a bit. For now, here is the link to my
original post on this for Amerigo's reading pleasure:
http://lkml.indiana.edu/hypermail/linux/kernel/0507.0/0206.html
Cheers,
Jeff
^ permalink raw reply
* Does Realtek RTL8110S and RTL8100C work ?
From: Markus Feldmann @ 2010-03-23 12:09 UTC (permalink / raw)
To: netdev
Hi All,
i am thinking about buying a Mini-ITX Server with some Realtek Cips on
the PCI Network Devices. These are
Realtek RTL8110S
Realtek RTL8100C
The Mini-ITX is a Jetway JNF92.
Does anybody know whether they work good or should i keep the hands off
these?
regards Markus
^ permalink raw reply
* Re: [PATCH] rps: make distributing packets fairly among all the online CPUs default
From: Changli Gao @ 2010-03-23 11:58 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David S. Miller, Tom Herbert, netdev, Ben Hutchings
In-Reply-To: <1269344306.2983.16.camel@edumazet-laptop>
On Tue, Mar 23, 2010 at 7:38 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le mardi 23 mars 2010 à 18:03 +0800, Changli Gao a écrit :
>
>
> I know _many_ applications that perform better when all network IRQS are
> directed to one CPU only. Single threaded UDP server for example, with
> fast answer, or routers, or ...
Yea, single threaded applicatons can't get much from RPS, but
multi-threaded applications such as apache do. And more and more
applications are programmed with the assumption there are more than
one CPUs/Cores.
>
> Many sysadmins tuned their machine to meet this requirement. Installing
> 2.6.35, if RPS enabled by default will make them unhappy, especially if
> CONFIG_SYSFS is not set, since they wont be able to change RPS settings.
>
> If RPS was good for all workloads, activating it would make sense, but
> this is not the case.
>
The sysadmins you mentioned above are Linux experters, and they know
how to tunning the system to get the best performance, but the default
configuration should be for the ordinary users, who don't know Linux
much.
--
Regards，
Changli Gao(xiaosuo@gmail.com)
^ permalink raw reply
* Re: [net-next-2.6 PATCH] ipoib: remove addrlen check for mc addresses
From: Moni Shoua @ 2010-03-23 11:55 UTC (permalink / raw)
To: Moni Shoua
Cc: Eli Cohen, Or Gerlitz, Jiri Pirko, netdev, davem, linux-rdma,
jgunthorpe
In-Reply-To: <4BA8A9BD.9030508@Voltaire.COM>
> maybe your'e looking for this one
> http://git.kernel.org/?p=linux/kernel/git/davem/net-next-2.6.git;a=commit;h=32a806c194ea112cfab00f558482dd97bee5e44e
This is the link to the related patch of course but it also tells you which tree to clone
^ permalink raw reply
* Hi
From: Santhapuri, Damodar @ 2010-03-23 11:55 UTC (permalink / raw)
To: netdev@vger.kernel.org
Subscribe me on it
^ permalink raw reply
* Re: [net-next-2.6 PATCH] ipoib: remove addrlen check for mc addresses
From: Moni Shoua @ 2010-03-23 11:45 UTC (permalink / raw)
To: Eli Cohen; +Cc: Or Gerlitz, Jiri Pirko, netdev, davem, linux-rdma, jgunthorpe
In-Reply-To: <20100323113436.GD12224@mtldesk030.lab.mtl.com>
Eli Cohen wrote:
> On Tue, Mar 23, 2010 at 12:34:13PM +0200, Or Gerlitz wrote:
>> basically, as the subject line suggests, it should be in Dave's net-next tree
>>
> I just need to clone this tree and need the url. Can you give it to me
> from .git/config?
> Thanks.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
maybe your'e looking for this one
http://git.kernel.org/?p=linux/kernel/git/davem/net-next-2.6.git;a=commit;h=32a806c194ea112cfab00f558482dd97bee5e44e
^ permalink raw reply
* Re: [PATCH] rps: make distributing packets fairly among all the online CPUs default
From: Eric Dumazet @ 2010-03-23 11:38 UTC (permalink / raw)
To: Changli Gao; +Cc: David S. Miller, Tom Herbert, netdev, Ben Hutchings
In-Reply-To: <412e6f7f1003230303l69fc142ey1581fff4c3e749be@mail.gmail.com>
Le mardi 23 mars 2010 à 18:03 +0800, Changli Gao a écrit :
>
> Ben Hutchings raised this question, but nobody replied with any message.
>
> I do think distributing packets fairly among all the online CPUs will
> helps most of users. I remember the smp_affinity of IRQ is the
> online_cpu_mask be default.
>
I know _many_ applications that perform better when all network IRQS are
directed to one CPU only. Single threaded UDP server for example, with
fast answer, or routers, or ...
Many sysadmins tuned their machine to meet this requirement. Installing
2.6.35, if RPS enabled by default will make them unhappy, especially if
CONFIG_SYSFS is not set, since they wont be able to change RPS settings.
If RPS was good for all workloads, activating it would make sense, but
this is not the case.
^ permalink raw reply
* Re: [net-next-2.6 PATCH] ipoib: remove addrlen check for mc addresses
From: Eli Cohen @ 2010-03-23 11:34 UTC (permalink / raw)
To: Or Gerlitz; +Cc: Jiri Pirko, netdev, davem, linux-rdma, monis, jgunthorpe
In-Reply-To: <4BA89925.3050602@Voltaire.com>
On Tue, Mar 23, 2010 at 12:34:13PM +0200, Or Gerlitz wrote:
>
> basically, as the subject line suggests, it should be in Dave's net-next tree
>
I just need to clone this tree and need the url. Can you give it to me
from .git/config?
Thanks.
^ permalink raw reply
* Re: [PATCH] rps: make distributing packets fairly among all the online CPUs default
From: Changli Gao @ 2010-03-23 11:27 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David S. Miller, Tom Herbert, netdev
In-Reply-To: <1269343422.2983.1.camel@edumazet-laptop>
On Tue, Mar 23, 2010 at 7:23 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le mardi 23 mars 2010 à 17:56 +0800, Changli Gao a écrit :
>> On Tue, Mar 23, 2010 at 3:20 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>> > Le mardi 23 mars 2010 à 14:24 +0800, Changli Gao a écrit :
>> >
>> > You cannot do this like this, these allocations wont be freed.
>> >
>> > Better would be to take a look at net/core/net-sysfs.c
>> >
>>
>> Sorry, but I don't know why these allocations won't be freed.
>>
>>
>
> Hint : This will be freed only if CONFIG_SYSFS is set
>
got it, thanks. But I just wonder if it is right the life cycle of
rps_map is maintained by sysfs rather than netdev itself.
--
Regards，
Changli Gao(xiaosuo@gmail.com)
^ permalink raw reply
* Re: [PATCH] rps: make distributing packets fairly among all the online CPUs default
From: Eric Dumazet @ 2010-03-23 11:23 UTC (permalink / raw)
To: Changli Gao; +Cc: David S. Miller, Tom Herbert, netdev
In-Reply-To: <412e6f7f1003230256m109644b0n2988e86a56f1ae1@mail.gmail.com>
Le mardi 23 mars 2010 à 17:56 +0800, Changli Gao a écrit :
> On Tue, Mar 23, 2010 at 3:20 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> > Le mardi 23 mars 2010 à 14:24 +0800, Changli Gao a écrit :
> >
> > You cannot do this like this, these allocations wont be freed.
> >
> > Better would be to take a look at net/core/net-sysfs.c
> >
>
> Sorry, but I don't know why these allocations won't be freed.
>
>
Hint : This will be freed only if CONFIG_SYSFS is set
^ permalink raw reply
* Re: [net-next-2.6 PATCH] ipoib: remove addrlen check for mc addresses
From: Moni Shoua @ 2010-03-23 10:46 UTC (permalink / raw)
To: Eli Cohen
Cc: Jiri Pirko, netdev-u79uwXL29TY76Z2rM5mHXA,
davem-fT/PcQaiUtIeIZ0/mPfg9Q, ogerlitz-smomgflXvOZWk0Htik3J/w,
linux-rdma-u79uwXL29TY76Z2rM5mHXA,
jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/
In-Reply-To: <20100323103034.GC12224-8YAHvHwT2UEvbXDkjdHOrw/a8Rv0c6iv@public.gmane.org>
> Could you send a link to the git tree where I can find this commit and
> the related fixes?
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
See commit 5e47596bee12597824a3b5b21e20f80b61e58a35 for the fix prior to this one.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [net-next-2.6 PATCH] ipoib: remove addrlen check for mc addresses
From: Or Gerlitz @ 2010-03-23 10:34 UTC (permalink / raw)
To: Eli Cohen
Cc: Jiri Pirko, netdev-u79uwXL29TY76Z2rM5mHXA,
davem-fT/PcQaiUtIeIZ0/mPfg9Q, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
monis-smomgflXvOZWk0Htik3J/w,
jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/
In-Reply-To: <20100323103034.GC12224-8YAHvHwT2UEvbXDkjdHOrw/a8Rv0c6iv@public.gmane.org>
Eli Cohen wrote:
> Could you send a link to the git tree where I can find this commit and
> the related fixes?
basically, as the subject line suggests, it should be in Dave's net-next tree
Or.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [net-next-2.6 PATCH] ipoib: remove addrlen check for mc addresses
From: Eli Cohen @ 2010-03-23 10:30 UTC (permalink / raw)
To: Jiri Pirko
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
ogerlitz-smomgflXvOZWk0Htik3J/w,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, monis-smomgflXvOZWk0Htik3J/w,
jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/
In-Reply-To: <20100322132138.GC2780-YzwxZg+R7evMbnheQZGK0N5OCZ2W11yPFxja6HXR22MAvxtiuMwx3w@public.gmane.org>
On Mon, Mar 22, 2010 at 02:21:39PM +0100, Jiri Pirko wrote:
> Finally this bit can be removed. Currently, after the bonding driver is
> changed/fixed (32a806c194ea112cfab00f558482dd97bee5e44e net-next-2.6),
Could you send a link to the git tree where I can find this commit and
the related fixes?
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 00/12] l2tp: Introduce L2TPv3 support
From: James Chapman @ 2010-03-23 10:19 UTC (permalink / raw)
To: davem; +Cc: netdev
David Miller wrote:
> > 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/
Oops, no-one built this with CONFIG_COMPAT when testing. Will fix.
> > 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:
scripts/checkpatch.pl didn't pick these up. Is there a recommended way
to find these in the future? I'm using stg to manage these 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.
I'm out the office this week. I'll fix the above (unless others beat me
to it) and resend as soon as I'm back.
--
James Chapman
Katalix Systems Ltd
http://www.katalix.com
Catalysts for your Embedded Linux software development
^ permalink raw reply
* Re: [PATCH] xfrm: cache bundle lookup results in flow cache
From: Herbert Xu @ 2010-03-23 9:41 UTC (permalink / raw)
To: Timo Teräs; +Cc: netdev, David S. Miller
In-Reply-To: <4BA88789.7060104@iki.fi>
On Tue, Mar 23, 2010 at 11:19:05AM +0200, Timo Teräs wrote:
>
> Normally, only the getter is called per-packet. So I'm thinking
> to have get() that would check for entry being stale or not,
> and bump up the refcount.
OK if it's just one call per packet it sounds good to me.
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
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