[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1324053184.25554.47.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
Date: Fri, 16 Dec 2011 17:33:04 +0100
From: Eric Dumazet <eric.dumazet@...il.com>
To: igorm@....rs
Cc: netdev@...r.kernel.org, davem@...emloft.net
Subject: Re: [PATCH 00/10 net-next] Introduce per interface ipv4 statistics
Le vendredi 16 décembre 2011 à 16:58 +0100, Igor Maravić a écrit :
> > 1) Why is it needed ? Any RFC requires this bloat ?
> >
>
> RFC4293 defines ipIfStatsTable.
Only as an option :
In addition to the ipSystemStatsTable, the MIB includes the
ipIfStatsTable. This table counts the same items as the system table
but does so on a per interface basis. It is optional and may be
ignored. If you decide to implement it, you may wish to arrange to
collect the data on a per-interface basis and then sum those counters
in order to provide the aggregate system level statistics. However,
if you choose to provide the system level statistics by summing the
interface level counters, no interface level statistics can be lost -
if an interface is removed, the statistics associated with it must be
retained.
If not enough memory is available, we cannot up the interfaces anymore
after your patches. Some people disable ipv6 on their machines because
they setup thousand of interfaces, and added memory cost of
ipIfStatsTable on IPv6 is huge.
> Also I did it because ipv6 has per interface stats.
I was considering _removing_ them, or make it optional.
Memory costs are huge for percpu data.
>
> > 2) Every patch in a patch serie must be compilable. Think about
> > bisection. This is mandatory.
> >
>
> OK, I didn't know about that...
> Do I need to resubmit it? If I do, I'l do that in monday.
As I said, this is _mandatory_.
Before spending time on this stuff, please wait for other people
comments.
> Would it be acceptable to send it as one big patch?
I dont think so, its too big.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists