Ethernet (and for that matter, IP) was designed to have a fixed upper length on packet sizes so that no one can hog the shared medium for too long while transmitting some long arbitrary-length message.
Standard Ethernet frames can only have up to 1500 bytes of payload.
Standard IP datagrams can only be up to 64 KiBytes length. (But because there are so many Ethernet-like network links on the Internet, most of the time IP datagrams stay within the 1500 byte limit of Ethernet anyway, because fragmentation and reassembly of large IP datagrams is less efficient than just keeping datagrams within the data link layer's MTU.)
If your application deals in messages larger than that, you have to do message fragmentation/reassembly/validation yourself at your own layer. This is how it was designed and how everyone deals with it, and you'd be swimming upstream to try to hack your hardware to allow 1MB messages. Instead you should just realize that what you want is not something those lower layers provide for you, but they provide you the building blocks you need to build your own solution at your layer. Networking protocols and technologies are specifically designed in layers, with the lowest layers providing the bare minimum needed by that layer, so that upper layers aren't burdened by lower layers doing way more than the upper layers need. There's a seminal paper on this called "End-to-End Arguments in System Design" by Saltzer, Reed, and Clark. Anyone getting into networking at this level of detail should read it.
I'm sure there are plenty of message-framing libraries around to make it easy to pass arbitrary-length messages around via TCP or UDP, where the message-framing library takes care of fragmenting, reassembling, and verifying your messages.