| To: | hadi@xxxxxxxxxx |
|---|---|
| Subject: | Re: RFC/PATCH capture qdisc requeue event in stats |
| From: | "David S. Miller" <davem@xxxxxxxxxx> |
| Date: | Mon, 30 Aug 2004 19:17:16 -0700 |
| Cc: | netdev@xxxxxxxxxxx, shemminger@xxxxxxxx |
| In-reply-to: | <1093916592.1037.51.camel@xxxxxxxxxxxxxxxx> |
| 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> |
| Sender: | netdev-bounce@xxxxxxxxxxx |
On 30 Aug 2004 21:43:13 -0400 jamal <hadi@xxxxxxxxxx> wrote: > On Mon, 2004-08-30 at 19:05, Stephen Hemminger wrote: > > > I have no problem but easier to just do something: > > struct tc_stats mystats; > > > > memset(&mystats, 0, sizeof(mystats)); > > memcpy(&mystats, RTA_DATA(tb[TCA_STATS]), RTA_PAYLOAD(tb[TCA_STATS])); > > > > that way it can grow as much as we want and don't have v1, v2, v3, ... > > size structures. > > Not sure i parsed that. You mean the tc_stats in user space will be the new > one. Yes, that's his idea. This way on older kernel the "new" statistics just show up as zero. |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: RFC/PATCH capture qdisc requeue event in stats, jamal |
|---|---|
| Next by Date: | Re: [RFC] MASQUERADE / policy routing ("Route send us somewhere else"), David S. Miller |
| Previous by Thread: | Re: RFC/PATCH capture qdisc requeue event in stats, jamal |
| Next by Thread: | Re: RFC/PATCH capture qdisc requeue event in stats, jamal |
| Indexes: | [Date] [Thread] [Top] [All Lists] |