IMO, one of the significant scaling bottlenecks for VMS was there were only a handful of spinlocks that governed kernel activity. The one that I remember was IOLOCK8 (sp?). Any ethernet frame handling would have to hold that for a period of time. The underlying code that those stacks use to manage their inbound ethernet frames is likely quite old and would require significant work to reduce contention around that lock.
To put it differently, a modern 10 gig ethernet card likely generates too much traffic to be effectively handled by that code. And if you had more than one 10 gig card in a box, they would contend around that common spin lock.
I'll add in that you could run a fairly simple program on Linux that simply blasted out very small UDP packets and point it at a VMS node - any port is fine - you'll drive up the interrupt mode on that box. You won't need much traffic. Smaller packets are better because you want to punch it with lots of packets. It won't be much actual bandwidth. VMS performance here is kind of sad.
As a bonus feature, if your VMS TCP/IP stack is configured to send ICMP replies when there is nothing there at the given port, you'll create even more grief because now the stack is busy trying to receive the blast you give it and send out replies too.
Are you talking about a lock held for regular interrupt-driven packet delivery, or a lock held even when an Ethernet card wants to DMA into a kernel ring buffer?
I don't think DMA is an option in VMS land. Just a lock held for regular interrupt driven packet delivery. Been a while since I've dealt with it.
This provides an in-depth description of the VCI API which is used to write your own ethernet frame handler. Some descriptions of when IOLOCK8 is held.
To put it differently, a modern 10 gig ethernet card likely generates too much traffic to be effectively handled by that code. And if you had more than one 10 gig card in a box, they would contend around that common spin lock.