Patrick McHardy <kaber@xxxxxxxxx> wrote: > On 25.11, Patrick McHardy wrote: > > On 25.11, Florian Westphal wrote: > > > Hmm, I think it actually increases readability, as all the other lines > > > you quoted above are a lot shorter the ip saddr part is a lot more > > > visible. > > > > They are actually still missing some minor parts from the original output :) > > > > But if we want to shorten them, I would suggest f.i. to not repeat the > > devices on every line. It seems to logically belong to the "packet" part, > > same as vlan id. I guess the only thing we actually need to repeat is the > > mark since that might change while we're within the ruleset. We can do this, but we'll need to make sure that the oif gets printed at one point (not available in prerouting)... > 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? -- 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
