On 25.11, Florian Westphal wrote: > Patrick McHardy <kaber@xxxxxxxxx> wrote: > > > Actually thinking more about this, we might want to send a new "packet" > > message whenever we enter nft_do_chain(). At that point the packet has been > > processed by other parts of the network stack since the last "packet" > > message and it might be helpful to know in which ways it has changed. > > True, good point. In that case I would propose to get rid of "packet" > message type completely. > > Instead we'd include all the info that we currently have in "packet" > (i.e. vlanid, headers) on the first message type fired on each nft_do_chain() > invocation. > > We can also move IIF/OIF info to this 'initial' message > (which might be of any type depending on the ruleset, due to POLICY > type we would however always send at least one, even if there are no > matches). > > The price to be paid would be a new variable that we have to keep > on-stack to know when we can elide the extra packet data. > > Does that sound reasonable? Sure, but is that really easier than including an unconditional (well, skb->nf_trace == 1) call to nf_tables_trace_notify() before entering the main loop? I don't see anything wrong the the packet message itself, just thinking it might be useful to emit one more in this specific spot. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
