talking-specifically, for example all AR8337 chips support up to 9k Jumbo frames, which imply up to 15%-25% benefits in sustained transfer/performance.
and since today even some low-end devices had it(or better)switch chips, like HEX/HAP/3011 it would be handy, perhaps.
How practical will it be? Jumbo frames work in a consistently managed LAN, e.g. between servers, but when you
are going to route or communicate to clients, what is the chance that there will be any percentage of the traffic
actually using >1500 byte frames?
Remember that when any party or any equipment inbetween does not support them, the frame size immediately
falls down to 1500 or less…
thats purely rhetorical, offtopic and irrelevant and apply to anything else in any area(aside networking)of activity.
basically if “any part of equipment don’t support X feature” its shouldn’t concern you as this topic shouldn’t concern you unless if you actually HAVE benefits from Jumbo frames, which is case.
and remember - considerable part of mikrotik gear - worked in “dumbed-down” configurations, with negilible setup complexity, even with fast-path and fast-track and aside routers there was switches that even in theory can’t handle anything else, which is benefit even more from, eventually.
similarly 90% of devices with 10Gb copper ports - had too weak CPU’s to use them in “router” configuration, but they find some use despite that, so jumbo frames perhaps pack some extra punch in that segment.
if you personally - don’t use something, thats imply automatically that its worthless for others.
Do you have actual experience with a deployment where jumbo frames are used outside of a very small
controlled environment like a storage area network?
How did you cope with the problem that there is no equivalent of path MTU discovery at L2?
(i.e. when sending >1500 bytes frames to a non-jumbo-capable host the frames are just lost, and you get
no report back “please decrease the frame size” like you get at L3 at least outside the realm of incompetent
firewall operators that just drop all ICMP)
i think maybe but only when jumbo 9k frames are standarized across all common scenarios will be the moment to think on bigger
today deploying jumbo frames require validate all devices involved on communication supporting it
i have a doubt, in a wireless 802.11ac access-point is viable to use jumbo 9k frames??
you intentionally missed whole point of usage/purpose of Jumbo frames, then.
because targeted/usual usage of them - absolutely irrelevant to this scenario/issues(whose is generic and irrelevant to jumbo frames, btw).
its never supposed to be “magic bullet”(like SCTP was or ad-hoc routing(say cjdns or hwmp or 802.11s) or active queuing(like RRED) and portion of Global communication, but NECESSITY for business networking within company network.
personally i never big fan of Jumbo frames even in LAN, but Several of companies i worked with - really Obsessed with it and do really Enjoy them.
as for wireless - considering CSMA impact on - i don’t think serious increase of it - make sense or safe in many respects(in fact some operators - forced decreased MTU,sadly). in TDMA things and hybrid/mixed tech(where TDMA meet FDMA meet CDMA, sometimes 3-in-1 or even 4-in-1(w/something else 
- maybe.
more than 9k over copper/fiber - give you only troubles usually, cuz its not really supported by most switches and routers or no at all. its may work over “all-intel” or “all-juniper” heterogeneous setup, which is quite unusual and fragile thing and avoided as hell for many reasons.
No to the contrary, I think you are missing the whole point, because you suggest jumboframe capability
in MikroTik equipment. But I won’t reply anymore, I don’t want to start a fight, I just think it is not useful
outside a small LAN segment like a storage area network, and I would never use MikroTik equipment there.
its depend approach and budget.
personally i knew companies that used both CRS and CCR in that scenario.
and generally “dumbed-down”(to maximize throughput)config - is quite popular among ROS users, sadly, aswell as things like fastpath and etc user cases.
support for Jumbo frames - may give you some edge in high-load transfers and outside of file servers “for free”. (up to 25-30%, which is considerable improvement).
personally i never use it, just wonder why it not there YET.
i use jumbo frames in my LAN mainly because i use both CCR and CRS so i like applying more load to them when they have to fragment packets that go outside the network.
My CCR has 10k ethernet frames, 65k bridge frames and i use SFP+ to connect to CRS which has 9k frames. To keep everything happy i leave it at 9k. Even though wifi uses 1.5k frames (2-3k including overhead which is the value you see) they have good CPUs.
I always try to push things over the edge and doing a CCR test with 65k frames you can reach the internal bandwidth limits way before the processing limits and also find problems that the CCR isnt always the best in every scenario despite being better than the CRS and other mikrotik products excluding wifi.
All jumbo frames do is increase the MTU but it doesnt necessarily mean that every packet will be 9k in size so you gain no loss in using jumbo frames as long as your networking gear keeps up and all agree on the same MTU.