On Wed, Oct 04, 2023 at 10:07:02AM +0200, Florian Westphal wrote: > Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote: > > We will soon need NFT_MSG_GETRULE_RESET_NO_TIMEOUT to undo this combo > > command semantics, from userspace this will require some sort of 'nft > > reset table x notimeout' syntax. > > NFT_MSG_GETRULE_RESET_NO_TIMEOUT sounds super ugly :/ > > Do you think we can add a flags attr that describes which parts > to reset? Sure. This will require one attribute for each object type, also reject it where it does not make sense. > No flags attr would reset everything. Refreshing timers is a bad default behaviour. And how does this mix with the set element timeout model from transaction? Now timers becomes a "moving target" again with this refresh? Oh, this will drag commit_mutex to netlink dump path to avoid that. > Do you consider reset of timers to be something that must > be handled via transaction infra or do you think it can > (re)use the dump-and-reset approach? The question why user wants to reset the timers in this path. For counters, this is to collect stats while leaving remaining things as is. Refreshing timers make no sense to me. For quota, this is to fetch the consumed quota and restart it, it might make sense to refresh the timer, but transaction sounds like a better path for this usecase? For limit, they do not expose internal stateful information, so this just a reset. Timer refresh makes no sense to me here. If this is for a dynamic set, user is refreshing/extending the timeout, but usually it is packet path that refreshes this timeouts via update. This reset feature is just there to collect stateful properties and leave things as is.
