netdev
[Top] [All Lists]

Re: RFC/PATCH capture qdisc requeue event in stats

To: "David S. Miller" <davem@xxxxxxxxxxxxx>
Subject: Re: RFC/PATCH capture qdisc requeue event in stats
From: Thomas Graf <tgraf@xxxxxxx>
Date: Wed, 29 Sep 2004 02:36:56 +0200
Cc: hadi@xxxxxxxxxx, netdev@xxxxxxxxxxx, shemminger@xxxxxxxx
In-reply-to: <20040830212910.78047bcd.davem@xxxxxxxxxxxxx>
References: <1093799632.1073.410.camel@xxxxxxxxxxxxxxxx> <20040830144033.2265a6e6.davem@xxxxxxxxxx> <1093904088.1043.12.camel@xxxxxxxxxxxxxxxx> <20040830154430.769d1d59.davem@xxxxxxxxxx> <1093906592.1037.32.camel@xxxxxxxxxxxxxxxx> <20040830160052.548c4846.davem@xxxxxxxxxx> <1093916592.1037.51.camel@xxxxxxxxxxxxxxxx> <20040830191716.0d002f91.davem@xxxxxxxxxx> <1093919823.1043.80.camel@xxxxxxxxxxxxxxxx> <20040830212910.78047bcd.davem@xxxxxxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
* David S. Miller <20040830212910.78047bcd.davem@xxxxxxxxxxxxx> 2004-08-30 21:29
> Look, let's get real about this topic.  We can't be breaking shit
> like this all the time.  We're nearly letting it happen a lot
> lately.
> 
> These data structures are user visible APIs, they are just like
> system call data structures, and if we cannot modify
> them without potentially breaking some existing application we
> cannot make that change.

Why not do it by using nested TLVs?:

  TCA_STATS2 [
      TCA_STAT_BYTES
      TCA_STAT_PACKETS
      TCA_STAT_DROPS
      ...
  ]

This way we can add as many new stats as we want without
even thinking about backward compatibility in the future.
This would also allow to implement dynamic size statistics
or introduce TCA_STAT_*_64 if ever needed.

<Prev in Thread] Current Thread [Next in Thread>