I test rule which catches torrent traffic (udp packets). When rule action is 'accept' everything is ok -- bytes counter is adequate to downloaded torrent. But when I change action to mark-packet -- rule byte counter is >90% lower than actual download. So, it skips >90% of packets!

Are you marking the connection as well?
In general, you should mark packets based on connection marks and not the classification criteria.
(in other words, if you're marking udp port 9999, then mark the connection based on udp 9999, but mark the packets based on the connection marks.)

I believe that this tends to increase your performance.

I checked both variants. Router doesn't do conntrack on UDP, at least for bittorrent. Anyway, what is UDP connection in terms of conntrack? I don't fully understand...

I checked both variants. Router doesn't do conntrack on UDP, at least for bittorrent. Anyway, what is UDP connection in terms of conntrack? I don't fully understand...

Router definitely does conntrack on UDP, even bittorrent. Now, the matching "ptp=bittorrent" might fail because bittorrent tries to hide from these sorts of things - and some packets in the stream may match the fingerprint of bittorrent and some packets may not - which is why packet-by-packet marking isn't the best way to go.

If your chains pick a udp connection to mark, then the connection is marked until the connection times out in the tracking table. (udp is connectionless, so there's no "FIN/RST" flags to watch for like on TCP). You can see your connection tracking timeouts by going into IP > Firewall > Connections and clicking the Tracking button.

As long as your initial matching criteria to flag a connection as bittorrent is able to recognize bittorrent connections, then marking the connection as bittorrent and all subsequent packets in the connection should be correctly marked.

This can't catch anything:
It catched 1724 bytes from total of 120 Mb download. I had encryption disabled in my client. And this catches well (all bytes were catched):
But, as you explained, such form can't do conntrack. In any case, don't you find that doing DPI for conntrack to mark a packet is more (much more) computationally intensive than just mark packet by a port range?

Maybe you have (as you should) a rule that matches "state established" as first rule and then those other matching rules below that?
When you do, the rules below see only the first packet of an exchange (TCP session or UDP port pair with recent traffic), which explains why you have so little matching data.

Good imagination, but no. I see all counters, none of them gets increased (and no such rule 'established').