Mikrotik Know this ?????

Fasttrack HW-Offloads established connections to the switch-chip,

I stand corrected. Good to know what actually happens on fasttracked connections.

https://help.mikrotik.com/docs/display/ ... -FastTrack

Describes it pretty well - yea, only mikrotik can answer that then.

fasttrack conection work in x86 ? yes or not, Mikrotik Know this ?????

Fastpath and Fasttrack generally speaking do NOT work on x86.

It is true that these have nothing whatsoever to do with HW offiload. However, both of these features require specific support to be added to the network interface driver (ethernet chip, etc.). MikroTik only bothers to do this for network interface drivers that apply to interface hardware included with RouterBOARDs. I've not yet run into a third-party NIC that is supported by ROS x86 and which is Fastpath/Fasttrack enabled.

Given how much CPU horsepower you can throw at an x86 solution, though, this is generally not an issue (or at least it hasn't been for us).

@NathanA: Fastpath and Fasttrack generally speaking do NOT work on x86....however, both of these features require specific support to be added to the network interface driver (ethernet chip, etc.).

Do you know how it actually works under the hood?

My guess is that Mikrotik uses their own attributes (likely within skb->cb[]) to flag packets that can bypass things like firewall, NAT, or queuing. This would work across all architectures, including x86, and wouldn’t require any special driver support.

FastTrack is available on the devices with FastPath support. FastTrack is FastPath+Connection Tracking.

FastPath is an interface driver extension, that allows you to receive/process/send traffic without unnecessary processing.
● Interface driver can now talk directly to specific RouterOS processes - skipping all others
● FastPath requirements:
– Interface driver support
[...]

That said, I’ll concede that “interface driver support” might not necessarily mean modifying the driver. It could just mean that the driver and underlying hardware must not interfere with FastPath requirements

net_device_ops code

struct net_device_ops {
    ...
    netdev_tx_t (*ndo_fast_path_xmit)(struct sk_buff *skb, struct net_device *dev);
};

To me, the key question still is: Does FastPath require a hard dependency on patched drivers, or can ROS use skb with standard hooks?

Your observations (e.g. counters staying at zero) might also suggest that the FastPath metrics themselves aren’t being reported correctly — rather than FastPath not working at all. The fact that ROS reports FastPath as enabled on x86 even if counters stay at 0 still suggests that the mechanism is present and able to engage.

Mikrotik’s documentation is infamously vague

But with ROS v7 (now on Linux 5.6.3), full support for L2MTU is present in the kernel via netlink

it’s more likely just a Mikrotik-defined standard transiver hook, declared something like this:

int (*ndo_fast_path_xmit) (struct net_device *dev, struct fp_buf *fpb);

struct fp_buf;
struct net_device_ops {
[...]

struct fp_stuff;
struct fp_dev_pcpu_stats;
struct fp_stats_rcu;
struct fp_dev {
       struct fp_stuff *stuff;
       int (*xmit)(struct net_device *dev, struct fp_buf *fpb);
       struct hlist_node list;
       struct fp_dev_pcpu_stats __percpu *stats;
       struct fp_stats_rcu *stats_rcu;
       u64 sp_rx_packet;
       u64 sp_tx_packet;
       u64 sp_rx_byte;
       u64 sp_tx_byte;
       u64 fp_rx_packet;
       u64 fp_tx_packet;
       u64 fp_rx_byte;
       u64 fp_tx_byte;
       u64 tx_drop;
};

struct net_device {
[...]
        unsigned                devid;
        struct fp_dev fp;
        unsigned long list_bitmap[256 / BITS_PER_LONG];

extern void (*fp_ptype_all_changed)(int);
extern void (*fp_nf_changed)(int, int pf);
extern void (*fp_xfrm_changed)(int);

void (*ipv4_routing_changed)(void);
void (*fp_ptype_all_changed)(int);
void (*fp_nf_changed)(int, int pf);
void (*fp_xfrm_changed)(int);
EXPORT_SYMBOL(ipv4_routing_changed);
EXPORT_SYMBOL(fp_ptype_all_changed);
EXPORT_SYMBOL(fp_nf_changed);
EXPORT_SYMBOL(fp_xfrm_changed);

int (*ndo_xmit_commit) (struct net_device *dev);

netdev_tx_t (*ndo_fast_path_xmit) (struct net_device *dev, struct net_device *port, void *buf);

To me, the key question still is: Does FastPath require a hard dependency on patched drivers, or can ROS use skb with standard hooks?

Yes, of course. That's what we are discussing.

Yeah, but you forgot to add my mighty conclusion:

You don't need to use a backtick to add an empty new line, just use a space plus newline

You only need two back-to-back newlines for all cases. No space needed.

Bleh.

• Netfilter’s flowtable infrastructure
• Flowtables explained Part 1: A Netfilter/Nftables Fastpath
• Linux Network Performance Ultimate Guide
• Nftables Wiki - Flowtables

I got this info from a friend I met this weekend. Support for "fast path" (aka Linux "flowtables") is standard functionality in Linux kernel 5.6, which is what ROS v7 runs on. Flowtables were introduced around 2017/2018 with full user-space support in Linux 5.1 and use related standard hooks in the network drivers. Only really old drivers need manual patching if the vendor hasn’t kept them up to date.

Just to be clear, my post was about fast path via nf_flowtable, not L2MTU. Different features and different context.

The idea that MT would deliberately replace or downgrade standard fast path functionality already present in the kernel and supported by current and future mainstream drivers is hard to take seriously. Occam's razor applies here.

• The help/documentation for v7 has the same set of restrictions placed upon both fast path and fast track's usage as v6 does (from the old wiki), in terms of what ROS features can or cannot be used and how things can be "wired up" in your config
• v7 listed hardware platform "support" for fast path has not deviated from the previous v6 list; it certainly hasn't added x86 to it
• the same first-party hardware that doesn't support fast path on v6 does not suddenly get it in v7
• in tests, none of the NICs that have drivers shipping with mainline Linux and which ROS7 supports on x86 seem to behave as if they support fast path...same as v6

The simplest explanation is that they’re using the native flowtable support in the 5.6 kernel, unless there’s solid evidence to the contrary. Sure, their patchsets might still include older fast path code for legacy drivers, but that doesn’t necessarily mean they aren’t also relying on the kernel’s built-in flowtable functionality for everything else.

It could simply be for backward compatibility or part of a gradual transition. If you’ve seen specific patches where they explicitly disable nf_flowtable, I’d be genuinely interested to take a look.