You don't have an aggregation-layer where you terminate such (very high-speed) customers ? Straight onto your core switch doesn't sound like a very good plan to me.
I don't know what CPU-power you have in your coreswitch-device, but perhaps you can iterate from 1Gbps shaping profiles to see howmuch cpu-time is going to that and make a guesstimate what will happen at 35Gbps

I can't speak out of experience, but I see no reason why simple-queues for the sake or shaping would work differently on 35Gbps vs 1Gbps.
What you need to try to find out is the impact on cpu & memory I guess. Shaping on IP-level like this using (simple) queues on 35Gbps is something you want to understand before implementing.


Reading things like

viewtopic.php?t=125422
viewtopic.php?t=171031

""
MikroTik made some changes to simple queues years ago that improved performance and gave them multi-core support (each simple queue item (or a group of them?) has a core for itself). So the solution was to use simple queues instead of queue trees. Oh boy and do I hate simple queues...well, turns out that adding about ~37500 simple queues halfbricks the router (reset needed) and the single core limit of ~1370Mbit/s still stands on the single core performance, so a single simple queue item can not limit more then the ~1370mbit/s on the ccr1036. And you need to have more then 32 simple queues for optimal load balancing on the cores, works ok with less tho.
""