On 17-08-24 07:51 PM, Cong Wang wrote:
For TC classes, their ->get() and ->put() are always paired, and the
reference counting is completely useless, because:
1) For class modification and dumping paths, we already hold RTNL lock,
so all of these ->get(),->change(),->put() are atomic.
2) Fo
Fri, Aug 25, 2017 at 01:51:29AM CEST, xiyou.wangc...@gmail.com wrote:
>For TC classes, their ->get() and ->put() are always paired, and the
>reference counting is completely useless, because:
>
>1) For class modification and dumping paths, we already hold RTNL lock,
> so all of these ->get(),->ch
Fri, Aug 25, 2017 at 11:18:50AM CEST, f...@strlen.de wrote:
>Jiri Pirko wrote:
>> Fri, Aug 25, 2017 at 01:51:29AM CEST, xiyou.wangc...@gmail.com wrote:
>> >For TC classes, their ->get() and ->put() are always paired, and the
>> >reference counting is completely useless, because:
>> >
>> >1) For cl
Jiri Pirko wrote:
> Fri, Aug 25, 2017 at 01:51:29AM CEST, xiyou.wangc...@gmail.com wrote:
> >For TC classes, their ->get() and ->put() are always paired, and the
> >reference counting is completely useless, because:
> >
> >1) For class modification and dumping paths, we already hold RTNL lock,
> >
Fri, Aug 25, 2017 at 01:51:29AM CEST, xiyou.wangc...@gmail.com wrote:
>For TC classes, their ->get() and ->put() are always paired, and the
>reference counting is completely useless, because:
>
>1) For class modification and dumping paths, we already hold RTNL lock,
> so all of these ->get(),->ch
For TC classes, their ->get() and ->put() are always paired, and the
reference counting is completely useless, because:
1) For class modification and dumping paths, we already hold RTNL lock,
so all of these ->get(),->change(),->put() are atomic.
2) For filter bindiing/unbinding, we use other