* Re: [PATCH 1/7] xfrm: remove policy lock when accessing policy->walk.dead
From: Timo Teräs @ 2010-03-30 12:41 UTC (permalink / raw)
To: Herbert Xu; +Cc: netdev
In-Reply-To: <20100330122301.GG5731@gondor.apana.org.au>
Herbert Xu wrote:
> On Tue, Mar 30, 2010 at 03:21:19PM +0300, Timo Teräs wrote:
>> Hmm... is it possible to modify/delete per-socket policies from
>> userland via xfrm_user? That would be also another race why
>> we'd need to check the unlinking result.
>
> How would the user be able to specify the socket?
>
> The answer is no.
I thought it was possible since they can be dumped.
But yes, I now see that the policy direction check does not
allow the per-socket policies to be specified.
So it'd make more sense to nuke the hashes entirely for
per-socket policies?
^ permalink raw reply
* Re: [PATCH 4/7] flow: delayed deletion of flow cache entries
From: Herbert Xu @ 2010-03-30 12:36 UTC (permalink / raw)
To: Timo Teräs; +Cc: netdev
In-Reply-To: <4BB1EF7A.7030407@iki.fi>
On Tue, Mar 30, 2010 at 03:32:58PM +0300, Timo Teräs wrote:
> If flow cache regeneration or shrinking is triggered in lookup,
> it would previously free it in place. Now that is deferred. But
> yes, it's more useful after the next patches that call the
> virtual destructor. Should have explained this better.
Any chance you can refactor them so that this comes after the
virtual get/put patch?
That way can evaluate this on its own merit rather than being
a prerequisite for the more important stuff.
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
* Re: [PATCH RFC] inetpeer: Support ipv6 addresses.
From: Herbert Xu @ 2010-03-30 12:34 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20100329.151539.216335891.davem@davemloft.net>
On Mon, Mar 29, 2010 at 03:15:39PM -0700, David Miller wrote:
>
> Interesting idea, but there is the issue of how to fill in
> new metrics cache entries when these requests come in later.
You just perform an rt lookup as usual. That'll give you the
metrics either from the route cache, or from scratch if we get
a cache miss.
> We'd have to retain a pointer to the routing table fib entry.
> This is because the fib entry states what the initial metric
> values need to be for cached routes.
We can keep the static metrics in the dst/rt entry. For me
shrinking the dst entry isn't such a big deal, but avoiding touching
global state when constructing a new rt entry is the deal-breaker.
But if you're really into dieting then we can have that fib
pointer :)
> So we'd need a pointer to the fib_info in the routing cache entry, and
> this pointer would need to grab a reference to the fib_info. And this
> subsequently leads to the question of what to do for route changes
> (f.e. hold the fib_info around until all the route cache entries drop
> their references and have a dead state in the fib_info struct that can
> be checked, and if we find it dead what can we even do as the route
> we're working with might be cached in a socket or similar)
AFAIK on route changes we always flush the route cache.
> The other option is to relookup the FIB, but we'd then have to
> validate that the route cache entry we're working with matches
> precisely still, and also this lookup alone going to have non-trivial
> cost :-)
>
> It's really depressing how hard it is to untangle the way we have
> things currently setup, isn't it. :-)
Yeah it's like the Gordian Knot :)
--
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 4/7] flow: delayed deletion of flow cache entries
From: Timo Teräs @ 2010-03-30 12:32 UTC (permalink / raw)
To: Herbert Xu; +Cc: netdev
In-Reply-To: <20100330122217.GF5731@gondor.apana.org.au>
Herbert Xu wrote:
> On Mon, Mar 29, 2010 at 05:12:41PM +0300, Timo Teras wrote:
>> Speed up lookups by freeing flow cache entries later. This is also in
>> preparation to have virtual entry destructor that might do more
>> work.
>
> So how does this speed up lookups exactly?
If flow cache regeneration or shrinking is triggered in lookup,
it would previously free it in place. Now that is deferred. But
yes, it's more useful after the next patches that call the
virtual destructor. Should have explained this better.
Like said in the general description, patches 4-7 go together
and still have some problem cases. But should show where I'm
trying to go.
I'd be interested hear if the idea of patches 4-7 is good
or we could things somehow better.
^ permalink raw reply
* Re: [PATCH 1/7] xfrm: remove policy lock when accessing policy->walk.dead
From: Herbert Xu @ 2010-03-30 12:23 UTC (permalink / raw)
To: Timo Teräs; +Cc: netdev
In-Reply-To: <4BB1ECBF.50000@iki.fi>
On Tue, Mar 30, 2010 at 03:21:19PM +0300, Timo Teräs wrote:
>
> Hmm... is it possible to modify/delete per-socket policies from
> userland via xfrm_user? That would be also another race why
> we'd need to check the unlinking result.
How would the user be able to specify the socket?
The answer is no.
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 4/7] flow: delayed deletion of flow cache entries
From: Herbert Xu @ 2010-03-30 12:22 UTC (permalink / raw)
To: Timo Teras; +Cc: netdev
In-Reply-To: <1269871964-5412-5-git-send-email-timo.teras@iki.fi>
On Mon, Mar 29, 2010 at 05:12:41PM +0300, Timo Teras wrote:
> Speed up lookups by freeing flow cache entries later. This is also in
> preparation to have virtual entry destructor that might do more
> work.
So how does this speed up lookups exactly?
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 1/7] xfrm: remove policy lock when accessing policy->walk.dead
From: Timo Teräs @ 2010-03-30 12:21 UTC (permalink / raw)
To: Herbert Xu; +Cc: netdev
In-Reply-To: <20100330121427.GD5731@gondor.apana.org.au>
Herbert Xu wrote:
> On Tue, Mar 30, 2010 at 03:04:01PM +0300, Timo Teräs wrote:
>>> I think it's hashed so socket policies are included in the policy
>> db dumps and counts.
>
> No we use a linked list for that.
Ah, yes. It's just all done together in the __xfrm_link_policy().
Hmm... is it possible to modify/delete per-socket policies from
userland via xfrm_user? That would be also another race why
we'd need to check the unlinking result.
^ permalink raw reply
* Re: [PATCH 2/7] flow: structurize flow cache
From: Herbert Xu @ 2010-03-30 12:15 UTC (permalink / raw)
To: Timo Teräs; +Cc: netdev
In-Reply-To: <4BB1E862.8090302@iki.fi>
On Tue, Mar 30, 2010 at 03:02:42PM +0300, Timo Teräs wrote:
>
> If we want generic flow cache, we might want to have multiple
> instance in future. It might also make sense to have per-net
> flow cache.
OK that makes sense.
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 1/7] xfrm: remove policy lock when accessing policy->walk.dead
From: Herbert Xu @ 2010-03-30 12:14 UTC (permalink / raw)
To: Timo Teräs; +Cc: netdev
In-Reply-To: <4BB1E8B1.4030604@iki.fi>
On Tue, Mar 30, 2010 at 03:04:01PM +0300, Timo Teräs wrote:
>> I think it's hashed so socket policies are included in the policy
> db dumps and counts.
No we use a linked list for that.
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 3/7] flow: allocate hash table for online cpus only
From: Herbert Xu @ 2010-03-30 12:12 UTC (permalink / raw)
To: Timo Teras; +Cc: netdev, Rusty Russell
In-Reply-To: <1269871964-5412-4-git-send-email-timo.teras@iki.fi>
On Mon, Mar 29, 2010 at 05:12:40PM +0300, Timo Teras wrote:
> Instead of unconditionally allocating hash table for all possible
> cpu's, allocate it only for online cpu's and release related
> memory if cpu goes down.
>
> Signed-off-by: Timo Teras <timo.teras@iki.fi>
Hmm that's where we started but then Rusty changed it back in 2004:
commit 0a32dc4d8e83c48f7535d66731eb35d1916b39a8
Author: Rusty Russell <rusty@rustcorp.com.au>
Date: Wed Jan 21 18:14:37 2004 -0800
[NET]: Simplify net/flow.c per-cpu handling.
The cpu handling in net/core/flow.c is complex: it tries to allocate
flow cache as each CPU comes up. It might as well allocate them for
each possible CPU at boot.
So I'd like to hear his opinion on changing it back again.
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: Network performance - iperf
From: Steve Magnani @ 2010-03-30 12:11 UTC (permalink / raw)
To: Michal Simek, Eric Dumazet
Cc: LKML, John Williams, netdev, Grant Likely, John Linn,
Arnd Bergmann, akpm
In-Reply-To: <4BB1C5A5.5070202@petalogix.com>
Looks like a lot of time spent in tcp_collapse(). I think there is assumption that the memcpys
involved in collapsing lead to better throughput than packet retransmit, which on our platforms
may not be the case. If so is there a way to tune when tcp_collapse gets invoked? I haven't
seen one.
Steve
-----Original Message-----
From: Michal Simek <michal.simek@petalogix.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: LKML <linux-kernel@vger.kernel.org>, John Williams <john.williams@petalogix.com>,
netdev@vger.kernel.org, Grant Likely <grant.likely@secretlab.ca>, John Linn
<John.Linn@xilinx.com>, "Steven J. Magnani" <steve@digidescorp.com>, Arnd Bergmann
<arnd@arndb.de>, akpm@linux-foundation.org
Date: Tue, 30 Mar 2010 11:34:29 +0200
Subject: Re: Network performance - iperf
> Eric Dumazet wrote:
> > Le lundi 29 mars 2010 à 17:27 +0200, Michal Simek a écrit :
> >> Michal Simek wrote:
> >>> Eric Dumazet wrote:
> >>>> Le lundi 29 mars 2010 à 13:33 +0200, Michal Simek a écrit :
> >>>>
> >>>>> Do you have any idea howto improve TCP/UDP performance in
> general?
> >>>>> Or tests which can point me on weak places.
> >>>> Could you post "netstat -s" on your receiver, after fresh boot and
> your
> >>>> iperf session, for 32 MB and 256 MB ram case ?
> >>>>
> >>> I am not sure if is helpful but look below.
> >>>
> >> Sorry I forget to c&p that second part. :-(
> >>
> >
> > Sorry, your netstat is not up2date.
>
> I am afraid that is up2date.
>
> >
> > If you cannot correct it to last version
> > [ net-tools 1.60 , netstat 1.42 ], please send
> >
> > cat /proc/net/snmp
> > cat /proc/net/netstat
>
> There is small buffer for parsing /proc/net/netstat.
> There is necessary to extend buffer size because one line is greater
> than 1024 chars.
>
> ~ # head -n 1 /proc/net/netstat
> TcpExt: SyncookiesSent SyncookiesRecv SyncookiesFailed EmbryonicRsts
> PruneCalled RcvPruned OfoPruned OutOfWindowIcmps LockDroppedIcmps
> ArpFilter TW TWRecycled TWKilled PAWSPassive PAWSActive PAWSEstab
> DelayedACKs DelayedACKLocked DelayedACKLost ListenOverflows ListenDrops
> TCPPrequeued TCPDirectCopyFromBacklog TCPDirectCopyFromPrequeue
> TCPPrequeueDropped TCPHPHits TCPHPHitsToUser TCPPureAcks TCPHPAcks
> TCPRenoRecovery TCPSackRecovery TCPSACKReneging TCPFACKReorder
> TCPSACKReorder TCPRenoReorder TCPTSReorder TCPFullUndo TCPPartialUndo
> TCPDSACKUndo TCPLossUndo TCPLoss TCPLostRetransmit TCPRenoFailures
> TCPSackFailures TCPLossFailures TCPFastRetrans TCPForwardRetrans
> TCPSlowStartRetrans TCPTimeouts TCPRenoRecoveryFail TCPSackRecoveryFail
> TCPSchedulerFailed TCPRcvCollapsed TCPDSACKOldSent TCPDSACKOfoSent
> TCPDSACKRecv TCPDSACKOfoRecv TCPAbortOnSyn TCPAbortOnData
> TCPAbortOnClose TCPAbortOnMemory TCPAbortOnTimeout TCPAbortOnLinger
> TCPAbortFailed TCPMemoryPressures TCPSACKDiscard TCPDSACKIgnoredOld
> TCPDSACKIgnoredNoUndo TCPSpuriousRTOs TCPMD5NotFound TCPMD5Unexpected
> TCPSackShifted TCPSackMerged TCPSackShiftFallback TCPBacklogDrop
> TCPMinTTLDrop
>
> Look at attached patch.
> And updated results are below.
>
> Thanks,
> Michal
>
>
>
>
>
> 256M
>
> ~ # iperf -s
> ------------------------------------------------------------
> Server listening on TCP port 5001
> TCP window size: 85.3 KByte (default)
> ------------------------------------------------------------
> [ 6] local 192.168.0.10 port 5001 connected with 192.168.0.101 port
> 33261
> [ ID] Interval Transfer Bandwidth
> [ 6] 0.0-50.2 sec 22.9 MBytes 3.83 Mbits/sec
> ~ # ./netstat -s
> Ip:
> 16618 total packets received
> 0 forwarded
> 0 incoming packets discarded
> 16618 incoming packets delivered
> 6490 requests sent out
> Icmp:
> 0 ICMP messages received
> 0 input ICMP message failed.
> ICMP input histogram:
> 0 ICMP messages sent
> 0 ICMP messages failed
> ICMP output histogram:
> Tcp:
> 0 active connections openings
> 1 passive connection openings
> 0 failed connection attempts
> 0 connection resets received
> 0 connections established
> 16618 segments received
> 6490 segments send out
> 0 segments retransmited
> 0 bad segments received.
> 0 resets sent
> Udp:
> 0 packets received
> 0 packets to unknown port received.
> 0 packet receive errors
> 0 packets sent
> RcvbufErrors: 0
> SndbufErrors: 0
> UdpLite:
> InDatagrams: 0
> NoPorts: 0
> InErrors: 0
> OutDatagrams: 0
> RcvbufErrors: 0
> SndbufErrors: 0
> TcpExt:
> 2233 packets pruned from receive queue because of socket buffer
> overrun
> ArpFilter: 0
> 1 delayed acks sent
> 5519 packets header predicted
> TCPPureAcks: 2
> TCPHPAcks: 0
> TCPRenoRecovery: 0
> TCPSackRecovery: 0
> TCPSACKReneging: 0
> TCPFACKReorder: 0
> TCPSACKReorder: 0
> TCPRenoReorder: 0
> TCPTSReorder: 0
> TCPFullUndo: 0
> TCPPartialUndo: 0
> TCPDSACKUndo: 0
> TCPLossUndo: 0
> TCPLoss: 0
> TCPLostRetransmit: 0
> TCPRenoFailures: 0
> TCPSackFailures: 0
> TCPLossFailures: 0
> TCPFastRetrans: 0
> TCPForwardRetrans: 0
> TCPSlowStartRetrans: 0
> TCPTimeouts: 0
> TCPRenoRecoveryFail: 0
> TCPSackRecoveryFail: 0
> TCPSchedulerFailed: 0
> TCPRcvCollapsed: 207654
> TCPDSACKOldSent: 0
> TCPDSACKOfoSent: 0
> TCPDSACKRecv: 0
> TCPDSACKOfoRecv: 0
> TCPAbortOnSyn: 0
> TCPAbortOnData: 0
> TCPAbortOnClose: 0
> TCPAbortOnMemory: 0
> TCPAbortOnTimeout: 0
> TCPAbortOnLinger: 0
> TCPAbortFailed: 0
> TCPMemoryPressures: 0
> TCPSACKDiscard: 0
> TCPDSACKIgnoredOld: 0
> TCPDSACKIgnoredNoUndo: 0
> TCPSpuriousRTOs: 0
> TCPMD5NotFound: 0
> TCPMD5Unexpected: 0
> TCPSackShifted: 0
> TCPSackMerged: 0
> TCPSackShiftFallback: 0
> TCPBacklogDrop: 0
> TCPMinTTLDrop: 0
> IpExt:
> InNoRoutes: 0
> InTruncatedPkts: 0
> InMcastPkts: 0
> OutMcastPkts: 0
> InBcastPkts: 0
> OutBcastPkts: 0
> InOctets: 24915880
> OutOctets: 337488
> InMcastOctets: 0
> OutMcastOctets: 0
> InBcastOctets: 0
> OutBcastOctets: 0
> ~ # ./netstat --version
> net-tools 1.60
> netstat 1.42 (2001-04-15)
> Fred Baumgarten, Alan Cox, Bernd Eckenfels, Phil Blundell, Tuan Hoang
> and others
> +NEW_ADDRT +RTF_IRTT +RTF_REJECT +FW_MASQUERADE -I18N
> AF: (inet) +UNIX +INET -INET6 -IPX -AX25 -NETROM -X25 -ATALK -ECONET
> -ROSE
> HW: +ETHER -ARC +SLIP +PPP -TUNNEL -TR -AX25 -NETROM -X25 -FR -ROSE
> -ASH -SIT -FDDI -HIPPI -HDLC/LAPB
> ~ # head -n 1 /proc/meminfo
> MemTotal: 257108 kB
>
>
>
> 32MB
>
> ~ # head -n 1 /proc/meminfo
> MemTotal: 29920 kB
> ~ # iperf -s
> ------------------------------------------------------------
> Server listening on TCP port 5001
> TCP window size: 85.3 KByte (default)
> ------------------------------------------------------------
> [ 6] local 192.168.0.10 port 5001 connected with 192.168.0.101 port
> 50088
> [ ID] Interval Transfer Bandwidth
> [ 6] 0.0-50.0 sec 109 MBytes 18.3 Mbits/sec
> ~ # ./netstat -s
> Ip:
> 79040 total packets received
> 0 forwarded
> 0 incoming packets discarded
> 79040 incoming packets delivered
> 29655 requests sent out
> Icmp:
> 0 ICMP messages received
> 0 input ICMP message failed.
> ICMP input histogram:
> 0 ICMP messages sent
> 0 ICMP messages failed
> ICMP output histogram:
> Tcp:
> 0 active connections openings
> 1 passive connection openings
> 0 failed connection attempts
> 0 connection resets received
> 0 connections established
> 79040 segments received
> 29655 segments send out
> 0 segments retransmited
> 0 bad segments received.
> 0 resets sent
> Udp:
> 0 packets received
> 0 packets to unknown port received.
> 0 packet receive errors
> 0 packets sent
> RcvbufErrors: 0
> SndbufErrors: 0
> UdpLite:
> InDatagrams: 0
> NoPorts: 0
> InErrors: 0
> OutDatagrams: 0
> RcvbufErrors: 0
> SndbufErrors: 0
> TcpExt:
> 9773 packets pruned from receive queue because of socket buffer
> overrun
> ArpFilter: 0
> 1 delayed acks sent
> 101 packets directly queued to recvmsg prequeue.
> 558928 packets directly received from prequeue
> 33274 packets header predicted
> 378 packets header predicted and directly queued to user
> TCPPureAcks: 2
> TCPHPAcks: 0
> TCPRenoRecovery: 0
> TCPSackRecovery: 0
> TCPSACKReneging: 0
> TCPFACKReorder: 0
> TCPSACKReorder: 0
> TCPRenoReorder: 0
> TCPTSReorder: 0
> TCPFullUndo: 0
> TCPPartialUndo: 0
> TCPDSACKUndo: 0
> TCPLossUndo: 0
> TCPLoss: 0
> TCPLostRetransmit: 0
> TCPRenoFailures: 0
> TCPSackFailures: 0
> TCPLossFailures: 0
> TCPFastRetrans: 0
> TCPForwardRetrans: 0
> TCPSlowStartRetrans: 0
> TCPTimeouts: 0
> TCPRenoRecoveryFail: 0
> TCPSackRecoveryFail: 0
> TCPSchedulerFailed: 0
> TCPRcvCollapsed: 120195
> TCPDSACKOldSent: 0
> TCPDSACKOfoSent: 0
> TCPDSACKRecv: 0
> TCPDSACKOfoRecv: 0
> TCPAbortOnSyn: 0
> TCPAbortOnData: 0
> TCPAbortOnClose: 0
> TCPAbortOnMemory: 0
> TCPAbortOnTimeout: 0
> TCPAbortOnLinger: 0
> TCPAbortFailed: 0
> TCPMemoryPressures: 0
> TCPSACKDiscard: 0
> TCPDSACKIgnoredOld: 0
> TCPDSACKIgnoredNoUndo: 0
> TCPSpuriousRTOs: 0
> TCPMD5NotFound: 0
> TCPMD5Unexpected: 0
> TCPSackShifted: 0
> TCPSackMerged: 0
> TCPSackShiftFallback: 0
> TCPBacklogDrop: 0
> TCPMinTTLDrop: 0
> IpExt:
> InNoRoutes: 0
> InTruncatedPkts: 0
> InMcastPkts: 0
> OutMcastPkts: 0
> InBcastPkts: 0
> OutBcastPkts: 0
> InOctets: 118232864
> OutOctets: 1542068
> InMcastOctets: 0
> OutMcastOctets: 0
> InBcastOctets: 0
> OutBcastOctets: 0
> ~ #
>
>
>
>
>
>
>
>
>
>
> --
> Michal Simek, Ing. (M.Eng)
> PetaLogix - Linux Solutions for a Reconfigurable World
> w: www.petalogix.com p: +61-7-30090663,+42-0-721842854 f:
> +61-7-30090663
^ permalink raw reply
* Re: debugging kernel during packet drops
From: Jan Engelhardt @ 2010-03-30 12:06 UTC (permalink / raw)
To: Patrick McHardy; +Cc: Eric Dumazet, Jorrit Kronjee, netfilter-devel, netdev
In-Reply-To: <4BAB3C8B.3030104@trash.net>
On Thursday 2010-03-25 11:35, Patrick McHardy wrote:
>Eric Dumazet wrote:
>> Here is patch I cooked for xt_hashlimit (on top of net-next-2.6) to make
>> it use RCU and scale better in your case (allowing several concurrent
>> cpus once RPS is activated), but also on more general cases.
>>
>> [PATCH] xt_hashlimit: RCU conversion
>>
>> xt_hashlimit uses a central lock per hash table and suffers from
>> contention on some workloads.
>>
>> After RCU conversion, central lock is only used when a writer wants to
>> add or delete an entry. For 'readers', updating an existing entry, they
>> use an individual lock per entry.
>
>This clashes with some recent cleanups in nf-next-2.6.git. I'm
>also expecting a patch from Jan to remove the old v0 revision
>very soon (probably today). Please rediff once I've pushed that out.
One 12-series request has been sitting there for a while. Was there
something not in order with it?
^ permalink raw reply
* Re: [PATCH 1/7] xfrm: remove policy lock when accessing policy->walk.dead
From: Timo Teräs @ 2010-03-30 12:04 UTC (permalink / raw)
To: Herbert Xu; +Cc: netdev
In-Reply-To: <20100330115351.GA5731@gondor.apana.org.au>
Herbert Xu wrote:
> On Tue, Mar 30, 2010 at 07:55:07AM +0300, Timo Teräs wrote:
>> Herbert Xu wrote:
>>> On Mon, Mar 29, 2010 at 05:12:38PM +0300, Timo Teras wrote:
>>>> @@ -1132,7 +1119,7 @@ int xfrm_sk_policy_insert(struct sock *sk, int dir, struct xfrm_policy *pol)
>>>> __xfrm_policy_link(pol, XFRM_POLICY_MAX+dir);
>>>> }
>>>> if (old_pol)
>>>> - __xfrm_policy_unlink(old_pol, XFRM_POLICY_MAX+dir);
>>>> + old_pol = __xfrm_policy_unlink(old_pol, XFRM_POLICY_MAX+dir);
>>>> write_unlock_bh(&xfrm_policy_lock);
>>>> if (old_pol) {
>>> So when can this actually fail?
>> Considering that the socket reference is received from the sk->sk_policy,
>> and the hash bucket we use is "XFRM_POLICY_MAX+dir", it's non-obvious if
>> it can fail or not.
>>
>> It would look like the timer can kill a policy and unlink it, but it
>> would still be found from sk_policy.
>
> Socket policies cannot expire.
Was not aware of that. The above is not needed then.
> In fact, they probably shouldn't even be on the bydst or any other
> hash table. I think the only reason they're there at all is because
> the hash table was added to __xfrm_policy_link which happens to be
> used by socket policies.
I think it's hashed so socket policies are included in the policy
db dumps and counts.
^ permalink raw reply
* Re: [PATCH 2/7] flow: structurize flow cache
From: Timo Teräs @ 2010-03-30 12:02 UTC (permalink / raw)
To: Herbert Xu; +Cc: netdev
In-Reply-To: <20100330120104.GB5731@gondor.apana.org.au>
Herbert Xu wrote:
> On Mon, Mar 29, 2010 at 05:12:39PM +0300, Timo Teras wrote:
>> Group all per-cpu data to one structure instead of having many
>> globals. Also prepare the internals so that we can have multiple
>> instances of the flow cache if needed.
>
> Grouping everything together looks sane. But adding the flow
> cache pointer to everything seems to be unnecessary. Why would
> we need multiple flow caches?
Just a precaution since it doable cheaply.
If we want generic flow cache, we might want to have multiple
instance in future. It might also make sense to have per-net
flow cache.
^ permalink raw reply
* Re: [PATCH 2/7] flow: structurize flow cache
From: Herbert Xu @ 2010-03-30 12:01 UTC (permalink / raw)
To: Timo Teras; +Cc: netdev
In-Reply-To: <1269871964-5412-3-git-send-email-timo.teras@iki.fi>
On Mon, Mar 29, 2010 at 05:12:39PM +0300, Timo Teras wrote:
> Group all per-cpu data to one structure instead of having many
> globals. Also prepare the internals so that we can have multiple
> instances of the flow cache if needed.
Grouping everything together looks sane. But adding the flow
cache pointer to everything seems to be unnecessary. Why would
we need multiple flow caches?
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 1/7] xfrm: remove policy lock when accessing policy->walk.dead
From: Herbert Xu @ 2010-03-30 11:53 UTC (permalink / raw)
To: Timo Teräs; +Cc: netdev
In-Reply-To: <4BB1842B.9010704@iki.fi>
On Tue, Mar 30, 2010 at 07:55:07AM +0300, Timo Teräs wrote:
> Herbert Xu wrote:
>> On Mon, Mar 29, 2010 at 05:12:38PM +0300, Timo Teras wrote:
>>> @@ -1132,7 +1119,7 @@ int xfrm_sk_policy_insert(struct sock *sk, int dir, struct xfrm_policy *pol)
>>> __xfrm_policy_link(pol, XFRM_POLICY_MAX+dir);
>>> }
>>> if (old_pol)
>>> - __xfrm_policy_unlink(old_pol, XFRM_POLICY_MAX+dir);
>>> + old_pol = __xfrm_policy_unlink(old_pol, XFRM_POLICY_MAX+dir);
>>> write_unlock_bh(&xfrm_policy_lock);
>>> if (old_pol) {
>>
>> So when can this actually fail?
>
> Considering that the socket reference is received from the sk->sk_policy,
> and the hash bucket we use is "XFRM_POLICY_MAX+dir", it's non-obvious if
> it can fail or not.
>
> It would look like the timer can kill a policy and unlink it, but it
> would still be found from sk_policy.
Socket policies cannot expire.
In fact, they probably shouldn't even be on the bydst or any other
hash table. I think the only reason they're there at all is because
the hash table was added to __xfrm_policy_link which happens to be
used by socket policies.
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] net/wireless/libertas: do not call wiphy_unregister() w/o wiphy_register()
From: Holger Schurig @ 2010-03-30 10:59 UTC (permalink / raw)
To: Daniel Mack
Cc: linux-kernel, Dan Williams, John W. Linville, Bing Zhao,
libertas-dev, linux-wireless, netdev
In-Reply-To: <20100330105029.GO30801@buzzloop.caiaq.de>
> I don't get your point. The patch I submitted fixes an Ooops in the
> driver, due to wrong handling of an API. What does that have to do with
> principle discussions about the frameworks in use?
I asked if there is a better method, and you said that you would test a better
solution. That means that someone else should make a better solution.
I just pointed out that I won't be the one who creates the better solution,
because for fundamental reasons I don't see the libertas+cfg80211 approach
going forward. That issue has nothing to do with you or your patch, so please
don't feel offended or confused.
Basically, I neither ack nor nak you patch. Given that it fixes an oops the
patch should go in, and probably to stable at well. I just gave a hint, to
make you think if you could come up with something better.
BTW, testing/fixing of failure paths in libertas as well as simplifying the
call sequence of functions during initialisation could be quite useful.
^ permalink raw reply
* Re: [PATCH] net/wireless/libertas: do not call wiphy_unregister() w/o wiphy_register()
From: Daniel Mack @ 2010-03-30 10:50 UTC (permalink / raw)
To: Holger Schurig
Cc: linux-kernel, Dan Williams, John W. Linville, Bing Zhao,
libertas-dev, linux-wireless, netdev
In-Reply-To: <201003301149.13462.hs4233@mail.mn-solutions.de>
On Tue, Mar 30, 2010 at 11:49:13AM +0200, Holger Schurig wrote:
> > If there's any better solution, I'd happily test it.
>
> Not from me, unfortunately. I'm not really interested into getting full
> cfg80211 into Libertas. That is, until either _one_ of this two options
> happen:
>
> * someone that actually uses/wants the proprietary Libertas mesh steps
> forward and says "We'll look after this and make it work with cfg80211"
> * we remove the proprietary Libertas mesh support
>
> That is: I won't work on Libertas mesh. I can't justify this time investment
> with my employer for something that I'll never need. For my device, my own
> version of Libertas + cfg80211 (without any WEXT anymore) works quite nice.
>
>
> So, if neither of the above things happens, then Libertas will work for the
> rest of the world with WEXT, as it did before.
I don't get your point. The patch I submitted fixes an Ooops in the
driver, due to wrong handling of an API. What does that have to do with
principle discussions about the frameworks in use?
Daniel
^ permalink raw reply
* Re: which stable PCI DSL Modem card
From: Simon Farnsworth @ 2010-03-30 9:49 UTC (permalink / raw)
To: Markus Feldmann; +Cc: netdev
In-Reply-To: <hoqbhd$pod$1@dough.gmane.org>
Markus Feldmann wrote:
> Hi All,
>
> i am searching for a stable PCI DSL Modem card for Linux (Debian Lenny).
> It should be exist a driver in the Kernel not extra software driver. I
> have a 6000MBit/s DSL wire.
>
You might want to look at the Solos cards from Traverse Technologies -
the driver for them is in the current Linux kernel.
http://www.traverse.com.au/productview.php?product_id=116 for more.
--
Simon
^ permalink raw reply
* [PATCH] Allow MACB to connect to a higher addresses PHY.
From: Anders Darander @ 2010-03-30 9:58 UTC (permalink / raw)
To: David S. Miller
Cc: Ralf Baechle, Maxime Bizon, Anders Darander, David Daney,
Sekhar Nori, Anton Vorontsov, Andy Fleming, Grant Likely, netdev,
linux-kernel
From: Anders Darander <ad@datarespons.se>
Using the Atmel MACB together with an integrated switch, can make only port 1
work. This is caused by macb_mii_probe trying to attach the MAC to the first
PHY, which often is on one of the external ports.
E.g. the Micrel KSZ8873 connects to the MAC on port 3, thus phy_addr should be
set to 3.
Signed-off-by: Anders Darander <ad@datarespons.se>
---
drivers/net/phy/Kconfig | 19 ++++++++++++++++++-
drivers/net/phy/phy_device.c | 4 ++++
2 files changed, 22 insertions(+), 1 deletions(-)
diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index fc5938b..64aa003 100644
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@ -15,11 +15,28 @@ if PHYLIB
comment "MII PHY device drivers"
+config SWITCHING_PHY
+ bool "An Ethernet switch is connected to the MAC"
+ depends on MACB
+ help
+ If an Ethernet switch is connected to the MAC, it
+ is quite common to have the connection on a port
+ higher than the first port. This option allows to
+ select the desired port number
+
+config SWITCHING_PHY_ADDR
+ int "PHYA address"
+ depends on SWITCHING_PHY
+ default "3"
+ help
+ On e.g. the Micrel KSZ8873MLL, port 3 (and thus phy_addr
+ 3) is the one connected to the MAC of the MCU.
+
config MARVELL_PHY
tristate "Drivers for Marvell PHYs"
---help---
Currently has a driver for the 88E1011S
-
+
config DAVICOM_PHY
tristate "Drivers for Davicom PHYs"
---help---
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index db17945..891bd0d 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -284,7 +284,11 @@ struct phy_device *phy_find_first(struct mii_bus *bus)
{
int addr;
+#ifdef CONFIG_SWITCHING_PHY
+ for (addr = CONFIG_SWITCHING_PHY_ADDR; addr < PHY_MAX_ADDR; addr++) {
+#else
for (addr = 0; addr < PHY_MAX_ADDR; addr++) {
+#endif
if (bus->phy_map[addr])
return bus->phy_map[addr];
}
--
1.7.0.3
^ permalink raw reply related
* Re: [PATCH] net/wireless/libertas: do not call wiphy_unregister() w/o wiphy_register()
From: Holger Schurig @ 2010-03-30 9:49 UTC (permalink / raw)
To: Daniel Mack
Cc: linux-kernel, Dan Williams, John W. Linville, Bing Zhao,
libertas-dev, linux-wireless, netdev
In-Reply-To: <20100330085253.GL30801@buzzloop.caiaq.de>
> If there's any better solution, I'd happily test it.
Not from me, unfortunately. I'm not really interested into getting full
cfg80211 into Libertas. That is, until either _one_ of this two options
happen:
* someone that actually uses/wants the proprietary Libertas mesh steps
forward and says "We'll look after this and make it work with cfg80211"
* we remove the proprietary Libertas mesh support
That is: I won't work on Libertas mesh. I can't justify this time investment
with my employer for something that I'll never need. For my device, my own
version of Libertas + cfg80211 (without any WEXT anymore) works quite nice.
So, if neither of the above things happens, then Libertas will work for the
rest of the world with WEXT, as it did before.
^ permalink raw reply
* [patch] 9p: saving negative to unsigned char
From: Dan Carpenter @ 2010-03-30 9:42 UTC (permalink / raw)
To: Eric Van Hensbergen
Cc: David S. Miller, Abhishek Kulkarni, Sripathi Kodi,
Latchesar Ionkov, Venkateswararao Jujjuri, linux-kernel, netdev,
kernel-janitors
Saving -EINVAL as unsigned char truncates the high bits and changes it
into 234 instead of -22. This breaks the test for "if (ret == -EINVAL)"
in parse_opts().
Signed-off-by: Dan Carpenter <error27@gmail.com>
diff --git a/net/9p/client.c b/net/9p/client.c
index e3e5bf4..edf31aa 100644
--- a/net/9p/client.c
+++ b/net/9p/client.c
@@ -71,9 +71,10 @@ inline int p9_is_proto_dotu(struct p9_client *clnt)
EXPORT_SYMBOL(p9_is_proto_dotu);
/* Interpret mount option for protocol version */
-static unsigned char get_protocol_version(const substring_t *name)
+static int get_protocol_version(const substring_t *name)
{
- unsigned char version = -EINVAL;
+ int version = -EINVAL;
+
if (!strncmp("9p2000", name->from, name->to-name->from)) {
version = p9_proto_legacy;
P9_DPRINTK(P9_DEBUG_9P, "Protocol version: Legacy\n");
^ permalink raw reply related
* Re: Network performance - iperf
From: Michal Simek @ 2010-03-30 9:34 UTC (permalink / raw)
To: Eric Dumazet
Cc: LKML, John Williams, netdev, Grant Likely, John Linn,
Steven J. Magnani, Arnd Bergmann, akpm
In-Reply-To: <1269884717.1958.2.camel@edumazet-laptop>
[-- Attachment #1: Type: text/plain, Size: 8888 bytes --]
Eric Dumazet wrote:
> Le lundi 29 mars 2010 à 17:27 +0200, Michal Simek a écrit :
>> Michal Simek wrote:
>>> Eric Dumazet wrote:
>>>> Le lundi 29 mars 2010 à 13:33 +0200, Michal Simek a écrit :
>>>>
>>>>> Do you have any idea howto improve TCP/UDP performance in general?
>>>>> Or tests which can point me on weak places.
>>>> Could you post "netstat -s" on your receiver, after fresh boot and your
>>>> iperf session, for 32 MB and 256 MB ram case ?
>>>>
>>> I am not sure if is helpful but look below.
>>>
>> Sorry I forget to c&p that second part. :-(
>>
>
> Sorry, your netstat is not up2date.
I am afraid that is up2date.
>
> If you cannot correct it to last version
> [ net-tools 1.60 , netstat 1.42 ], please send
>
> cat /proc/net/snmp
> cat /proc/net/netstat
There is small buffer for parsing /proc/net/netstat.
There is necessary to extend buffer size because one line is greater
than 1024 chars.
~ # head -n 1 /proc/net/netstat
TcpExt: SyncookiesSent SyncookiesRecv SyncookiesFailed EmbryonicRsts
PruneCalled RcvPruned OfoPruned OutOfWindowIcmps LockDroppedIcmps
ArpFilter TW TWRecycled TWKilled PAWSPassive PAWSActive PAWSEstab
DelayedACKs DelayedACKLocked DelayedACKLost ListenOverflows ListenDrops
TCPPrequeued TCPDirectCopyFromBacklog TCPDirectCopyFromPrequeue
TCPPrequeueDropped TCPHPHits TCPHPHitsToUser TCPPureAcks TCPHPAcks
TCPRenoRecovery TCPSackRecovery TCPSACKReneging TCPFACKReorder
TCPSACKReorder TCPRenoReorder TCPTSReorder TCPFullUndo TCPPartialUndo
TCPDSACKUndo TCPLossUndo TCPLoss TCPLostRetransmit TCPRenoFailures
TCPSackFailures TCPLossFailures TCPFastRetrans TCPForwardRetrans
TCPSlowStartRetrans TCPTimeouts TCPRenoRecoveryFail TCPSackRecoveryFail
TCPSchedulerFailed TCPRcvCollapsed TCPDSACKOldSent TCPDSACKOfoSent
TCPDSACKRecv TCPDSACKOfoRecv TCPAbortOnSyn TCPAbortOnData
TCPAbortOnClose TCPAbortOnMemory TCPAbortOnTimeout TCPAbortOnLinger
TCPAbortFailed TCPMemoryPressures TCPSACKDiscard TCPDSACKIgnoredOld
TCPDSACKIgnoredNoUndo TCPSpuriousRTOs TCPMD5NotFound TCPMD5Unexpected
TCPSackShifted TCPSackMerged TCPSackShiftFallback TCPBacklogDrop
TCPMinTTLDrop
Look at attached patch.
And updated results are below.
Thanks,
Michal
256M
~ # iperf -s
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[ 6] local 192.168.0.10 port 5001 connected with 192.168.0.101 port 33261
[ ID] Interval Transfer Bandwidth
[ 6] 0.0-50.2 sec 22.9 MBytes 3.83 Mbits/sec
~ # ./netstat -s
Ip:
16618 total packets received
0 forwarded
0 incoming packets discarded
16618 incoming packets delivered
6490 requests sent out
Icmp:
0 ICMP messages received
0 input ICMP message failed.
ICMP input histogram:
0 ICMP messages sent
0 ICMP messages failed
ICMP output histogram:
Tcp:
0 active connections openings
1 passive connection openings
0 failed connection attempts
0 connection resets received
0 connections established
16618 segments received
6490 segments send out
0 segments retransmited
0 bad segments received.
0 resets sent
Udp:
0 packets received
0 packets to unknown port received.
0 packet receive errors
0 packets sent
RcvbufErrors: 0
SndbufErrors: 0
UdpLite:
InDatagrams: 0
NoPorts: 0
InErrors: 0
OutDatagrams: 0
RcvbufErrors: 0
SndbufErrors: 0
TcpExt:
2233 packets pruned from receive queue because of socket buffer overrun
ArpFilter: 0
1 delayed acks sent
5519 packets header predicted
TCPPureAcks: 2
TCPHPAcks: 0
TCPRenoRecovery: 0
TCPSackRecovery: 0
TCPSACKReneging: 0
TCPFACKReorder: 0
TCPSACKReorder: 0
TCPRenoReorder: 0
TCPTSReorder: 0
TCPFullUndo: 0
TCPPartialUndo: 0
TCPDSACKUndo: 0
TCPLossUndo: 0
TCPLoss: 0
TCPLostRetransmit: 0
TCPRenoFailures: 0
TCPSackFailures: 0
TCPLossFailures: 0
TCPFastRetrans: 0
TCPForwardRetrans: 0
TCPSlowStartRetrans: 0
TCPTimeouts: 0
TCPRenoRecoveryFail: 0
TCPSackRecoveryFail: 0
TCPSchedulerFailed: 0
TCPRcvCollapsed: 207654
TCPDSACKOldSent: 0
TCPDSACKOfoSent: 0
TCPDSACKRecv: 0
TCPDSACKOfoRecv: 0
TCPAbortOnSyn: 0
TCPAbortOnData: 0
TCPAbortOnClose: 0
TCPAbortOnMemory: 0
TCPAbortOnTimeout: 0
TCPAbortOnLinger: 0
TCPAbortFailed: 0
TCPMemoryPressures: 0
TCPSACKDiscard: 0
TCPDSACKIgnoredOld: 0
TCPDSACKIgnoredNoUndo: 0
TCPSpuriousRTOs: 0
TCPMD5NotFound: 0
TCPMD5Unexpected: 0
TCPSackShifted: 0
TCPSackMerged: 0
TCPSackShiftFallback: 0
TCPBacklogDrop: 0
TCPMinTTLDrop: 0
IpExt:
InNoRoutes: 0
InTruncatedPkts: 0
InMcastPkts: 0
OutMcastPkts: 0
InBcastPkts: 0
OutBcastPkts: 0
InOctets: 24915880
OutOctets: 337488
InMcastOctets: 0
OutMcastOctets: 0
InBcastOctets: 0
OutBcastOctets: 0
~ # ./netstat --version
net-tools 1.60
netstat 1.42 (2001-04-15)
Fred Baumgarten, Alan Cox, Bernd Eckenfels, Phil Blundell, Tuan Hoang
and others
+NEW_ADDRT +RTF_IRTT +RTF_REJECT +FW_MASQUERADE -I18N
AF: (inet) +UNIX +INET -INET6 -IPX -AX25 -NETROM -X25 -ATALK -ECONET -ROSE
HW: +ETHER -ARC +SLIP +PPP -TUNNEL -TR -AX25 -NETROM -X25 -FR -ROSE
-ASH -SIT -FDDI -HIPPI -HDLC/LAPB
~ # head -n 1 /proc/meminfo
MemTotal: 257108 kB
32MB
~ # head -n 1 /proc/meminfo
MemTotal: 29920 kB
~ # iperf -s
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[ 6] local 192.168.0.10 port 5001 connected with 192.168.0.101 port 50088
[ ID] Interval Transfer Bandwidth
[ 6] 0.0-50.0 sec 109 MBytes 18.3 Mbits/sec
~ # ./netstat -s
Ip:
79040 total packets received
0 forwarded
0 incoming packets discarded
79040 incoming packets delivered
29655 requests sent out
Icmp:
0 ICMP messages received
0 input ICMP message failed.
ICMP input histogram:
0 ICMP messages sent
0 ICMP messages failed
ICMP output histogram:
Tcp:
0 active connections openings
1 passive connection openings
0 failed connection attempts
0 connection resets received
0 connections established
79040 segments received
29655 segments send out
0 segments retransmited
0 bad segments received.
0 resets sent
Udp:
0 packets received
0 packets to unknown port received.
0 packet receive errors
0 packets sent
RcvbufErrors: 0
SndbufErrors: 0
UdpLite:
InDatagrams: 0
NoPorts: 0
InErrors: 0
OutDatagrams: 0
RcvbufErrors: 0
SndbufErrors: 0
TcpExt:
9773 packets pruned from receive queue because of socket buffer overrun
ArpFilter: 0
1 delayed acks sent
101 packets directly queued to recvmsg prequeue.
558928 packets directly received from prequeue
33274 packets header predicted
378 packets header predicted and directly queued to user
TCPPureAcks: 2
TCPHPAcks: 0
TCPRenoRecovery: 0
TCPSackRecovery: 0
TCPSACKReneging: 0
TCPFACKReorder: 0
TCPSACKReorder: 0
TCPRenoReorder: 0
TCPTSReorder: 0
TCPFullUndo: 0
TCPPartialUndo: 0
TCPDSACKUndo: 0
TCPLossUndo: 0
TCPLoss: 0
TCPLostRetransmit: 0
TCPRenoFailures: 0
TCPSackFailures: 0
TCPLossFailures: 0
TCPFastRetrans: 0
TCPForwardRetrans: 0
TCPSlowStartRetrans: 0
TCPTimeouts: 0
TCPRenoRecoveryFail: 0
TCPSackRecoveryFail: 0
TCPSchedulerFailed: 0
TCPRcvCollapsed: 120195
TCPDSACKOldSent: 0
TCPDSACKOfoSent: 0
TCPDSACKRecv: 0
TCPDSACKOfoRecv: 0
TCPAbortOnSyn: 0
TCPAbortOnData: 0
TCPAbortOnClose: 0
TCPAbortOnMemory: 0
TCPAbortOnTimeout: 0
TCPAbortOnLinger: 0
TCPAbortFailed: 0
TCPMemoryPressures: 0
TCPSACKDiscard: 0
TCPDSACKIgnoredOld: 0
TCPDSACKIgnoredNoUndo: 0
TCPSpuriousRTOs: 0
TCPMD5NotFound: 0
TCPMD5Unexpected: 0
TCPSackShifted: 0
TCPSackMerged: 0
TCPSackShiftFallback: 0
TCPBacklogDrop: 0
TCPMinTTLDrop: 0
IpExt:
InNoRoutes: 0
InTruncatedPkts: 0
InMcastPkts: 0
OutMcastPkts: 0
InBcastPkts: 0
OutBcastPkts: 0
InOctets: 118232864
OutOctets: 1542068
InMcastOctets: 0
OutMcastOctets: 0
InBcastOctets: 0
OutBcastOctets: 0
~ #
--
Michal Simek, Ing. (M.Eng)
PetaLogix - Linux Solutions for a Reconfigurable World
w: www.petalogix.com p: +61-7-30090663,+42-0-721842854 f: +61-7-30090663
[-- Attachment #2: 0001-Extend-buffer-size-because-line-size-is-greater-than.patch --]
[-- Type: text/x-patch, Size: 988 bytes --]
>From e2d160e2e235103af3e08b5bbbc451982bc0fed0 Mon Sep 17 00:00:00 2001
From: Michal Simek <monstr@monstr.eu>
Date: Tue, 30 Mar 2010 10:45:06 +0200
Subject: [PATCH] Extend buffer size because line size is greater than 1024 chars
Error shown on console
UdpLite:
InDatagrams: 0
NoPorts: 0
InErrors: 0
OutDatagrams: 0
RcvbufErrors: 0
SndbufErrors: 0
error parsing /proc/net/snmp: Success
It is easy to check size of line which is necessary to check.
1151
Signed-off-by: Michal Simek <monstr@monstr.eu>
---
statistics.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/statistics.c b/statistics.c
index a878df8..51beb8a 100644
--- a/statistics.c
+++ b/statistics.c
@@ -291,7 +291,7 @@ struct tabtab *newtable(struct tabtab *tabs, char *title)
void process_fd(FILE *f)
{
- char buf1[1024], buf2[1024];
+ char buf1[2048], buf2[2048];
char *sp, *np, *p;
while (fgets(buf1, sizeof buf1, f)) {
int endflag;
--
1.5.5.1
^ permalink raw reply related
* Re: which stable PCI DSL Modem card
From: Michael Tokarev @ 2010-03-30 9:32 UTC (permalink / raw)
To: Markus Feldmann; +Cc: netdev
In-Reply-To: <hoqbhd$pod$1@dough.gmane.org>
Markus Feldmann Wrote:
> Hi All,
>
> i am searching for a stable PCI DSL Modem card for Linux (Debian Lenny).
> It should be exist a driver in the Kernel not extra software driver. I
> have a 6000MBit/s DSL wire.
>
> Does anybody know some interesting device for me? Any further information?
As far as I can see they stopped producing PCI DSL modems quite a while
ago. They sell USB and ethernet ones, but not PCI. And even at "old
good" times there were only 2 or 3 models with PCI interface, the rest
were USB or Ether.
I personally recommend ethernet modem - it will work with any OS including
linux. USB modems with linux support exists, but that support is somewhat
flaky.
Also, many DSL modems nowadays comes with 4-port ethernet switch and
wireless access point, which may be handy too. Both optional.
/mjt
^ permalink raw reply
* XT_ALIGN changed to use ALIGN breaks iproute2
From: Andreas Henriksson @ 2010-03-30 9:28 UTC (permalink / raw)
To: Alexey Dobriyan, Patrick McHardy; +Cc: Stephen Hemminger, jamal, netdev
Hello Alexey (and everyone else)!
You updated the kernel header include/linux/netfilter/x_tables.h
in torvalds/linux-2.6.git commit 42107f5009da223daa800d6da6904d77297ae829
with the comment "Use ALIGN() macro while I'm at it for same types.".
When this header was synced into iproute2 the build broke because the
ALIGN macro apparently only is defined in kernel headers.
(For iproute2 the problem was introduced in
8ecdcce08319d0e39b0d32c1d17db3f69d85a35c and found by Stephen
and worked around in 609ceb807deba8e23 and edaaa11e5a3cf2c9c1a39)
I'm guessing the problem in the iproute2 header sync is just a heads
up for what's going to happen when distributions updates their
system headers to match linux 2.6.33.
Could someone who knows how the userspace version of the kernel
headers are generated please find a suitable solution?
--
Andreas Henriksson
^ 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