Non-IP traffic over Ethernet has been a part of networking for decades so I am not really clear on what you are really trying to get answered and maybe you need to learn a bit more about the basics of networking. There is no such thing as a "Ethernet Wireless card" as 802.3 Ethernet and 802.11 wireless are two entirely different standards. As such, your frame format in the 2nd issue wouldn't apply at all to an 802.11 network, but frames have certain requirements according to the standards which is why many of the components of the frame you list are not configurable.

@YLearn Non-IP traffic over Ethernet has been a part of networking for decades ok, but at that time the Ethernet devices were not as 'smart' as today, and a lot of the work was done by the CPU. I was wondering whether the cost of being 'smart' is losing flexibility.

@YLearn wouldn't apply at all to an 802.11 network Ok, I'm aware that other computers connected in a standard 802.11 network would not recognize such frames as valid ones. However, is it possible to send/receive such frames? Or the hardware won't allow?

@MarkMessa, frames from one host to another host on the same LAN will be received by the second host. The question is whether or not they will be passed to upper layers in the network stack inside the host. If the receiving host only has an IP stack and the frame payload is not IP, then the data will be ignored. You need to learn about the OSI model to get a general ideas about how data is passed from one host to another.

@MarkMessa, regarding your first comment, despite Ethernet devices being "smarter," Ethernet still operates as Ethernet. 802.3 never has nor never will require the use of IP. For example, while rare, Ethernet today will still support Appletalk or IPX/SPX just as happily as ever, or without any higher layer protocol at all (many things still use just L2 for communication). As for your second comment, I am not sure what you mean by "is it possible to send/receive such frames." You can't send 802.3 frames over 802.11, but there are 802.11 only communications not involving IP.

@RonMaupin The question is whether or not they will be passed to [host] upper layers Ok, it would be necessary to customize a software that would get the data from the data-link layer (OSI layer 2), avoid several intermediaries layers (mainly the network layer and the transport layer), and pass directly to the application layer (OSI layer 7). However, for the moment I would prefer just to conclude whether there is some hardware constraint or not. Latter I will focus on software issues.

It's all software. The hardware basically just turns the bits from layer-2 into electrical signals. What you are discussing is really all software. Layer-2 needs addressing to find another host on the LAN, layer-3 needs addressing to find another host on a different LAN, and layer-4 needs addressing to find the application in the target host. You can replace layer-3 and layer-4 with your own network stack, but the applications may not be compatible with it. Just remember that there are many very smart people that do nothing but try to make it all work better.

@RonMaupin It's all software. I was expecting to be like that. Unfortunately, several software developers don't say so. Now with your posts, it would be much easier to talk with them. By the way, it would be very nice if you include this comments in your final answer.

@RonMaupin there are many very smart people Some customization you need to do on your own instead of waiting the market solve it for you.

The point is that the layers are separate and independent. The layer-1 hardware can have non-standard layer-2 software. You just need to write your own divers and network stack. That is very, very non-trivial.

@RonMaupin You just need to write your own divers ok, I imagined this might happen. But I'll urge you to leave this issue to my next question, which will focus on the software side.

@YLearn You can't send 802.3 frames over 802.11 Ok, I get it that Ethernet frames (802.3) are different than Wi-Fi frames (802.11). I guess that the preamble, the delimiter and pad are different. However, the CRC is the same and the MAC header I guess is very similar. Do you agree with this comment?

@MarkMessa, no I don't. For instance, 802.11 frames can have up to four addresses in their headers (see my answer here for more details) and contain other information as well. They are two entirely different frame formats that happen to have some similarities.

@YLearn They are two entirely different frame formats Ok, I guess I'm getting your point. Let me ask you again but through a different perspective. Is the frame 'structure' of 802.3 and 802.11 at least the same? ie: both frames are divided in the same way (preamble, delimiter, mac header, payload, pad and CRC) although the format of each one of such divisions are entirely different.

@MarkMessa, in general I believe so, although 802.11 frames do not make use of padding (padding is only necessary in 802.3 if the payload is too small to allow the frame to reach the minimum size of 64 bytes) and the "mac header" sections are very different.

@YLearn I am not sure what you mean by "is it possible to send/receive such frames." Now we have some common ground to solve this issue. Is it possible to send/receive a 802.11 frame without the mac header sections? (ie: preamble | delimiter | payload | CRC)

@MarkMessa, see that is where you lose me. You reference a couple of resources about using "Raw Ethernet" and then out of no where you start asking about not using the MAC headers and I have no idea where you are pulling that "concept" from as the "Raw Ethernet" examples are using the MAC headers. No, without the headers, Ethernet is not Ethernet nor is 802.11 802.11. Would it be possible if you wrote your own L1/L2 protocol? Sure, anything is possible. But asking about using "Raw Ethernet" without the MAC headers just doesn't make any sense.

@YLearn Ok, I though it might be possible to use some built-in features of the MAC and LLC sublayers without necessarily using the standard MAC/LLC headers section. However, this sound a little bit strange to me. For example, there is nothing in the MAC header section serving as input for a medium access control protocol. Even so, you can't use such feature without filling the MAC header.

Just for reference, the data in the first link is obviously incorrect. It alleges that it would be possible to transmit 1500 octets of data, back and forth, on a 100 Mbit/s link, in 19, 12, or 46 µs. 1500 octets * 8 bits/octet * 2 (back and forth) / 100000000 (100 Mbit/s) = 240 µs (not even counting Ethernet overhead). This is actually acknowledged by the author (bold section above table of contents).

Yes, A. Schaufler (the author of the 1st link) recognized that "there is a mistake in the performance measuring code" and that "the figures presented are very likely wrong". However, the benchmarks done in the 2nd link by D. Sarda seems to be wright, which roughly indicates a 50% increase in the throughput.

@jcaron Although the figures are likely wrong in the 1st link, I consider it a nice introduction to the main ideas of the subject (reason why I mentioned it in the question).

@MarkMessa, yes, but be advised that you will most certainly not get anywhere near 50% increases in throughput. For 1500-byte packets, the IP+UDP overhead is less than 2%, and remember you'll probably have to add your own overhead instead of that of IP+UDP, so it'll be even less.

@jcaron I guess the main overhead in question is not the headers in each packet, but the additional packets transmitted due to TCP/IP control and management.

@MarkMessa, if you consider UDP, in terms of throughput there's nothing more that the packets containing the data you send. In the case of TCP you would only have the issue of ACKs, but only in the case of a unidirectional data flow (otherwise they would piggyback on packets sent in the other direction). And if you needed the reliability of TCP, you would have the same issue with your own protocol. There's nothing else required for "control and management" being the initial DHCP setup/lease renewal and the possible initial ARP request.

@jcaron There's nothing else required for "control and management" Besides handshakes, ACKS, DHCP and ARP, I guess that the congestion control of TCP (mainly slow-start) is also a significant reason for a difference in throughput. Now, considering UDP, I agree with you that there is not much reason for a large difference in throughput, unfortunately there is no reliable benchmark measuring that.

@MarkMessa, why don't you just do the test yourself? The details of raw packet sending/receiving are OS-specific, but I believe in many cases you actually send/receive Ethernet-formatted frames which are converted to/from link-layer format by the driver (too much stuff that's really controlled by the adapter or adapter settings, not you). You haven't told us what OS you're contemplating, BTW.

@jcaron You haven't told us what OS you're contemplating When I posted this question, I was still in doubt about whether the hardware would let you sent/receive raw wifi packet. Therefore, I preferred not to blur the discussion with OS details.