What is the effect of setting a linux socket - high priority?

Every Linux network interface has a so called qdisc (queuing discipline) attached to it. And the answer to your questions depends on the qdisc in use. Some queuing disciplines like pfifo and bfifo, have no concept of priority. So if they're used, the answer is simple - there will be no prioritization

However, with a prioritizing qdisc such as pfifo_fast (which typically the default qdisc on Linux), the socket priority can have an effect.

This image describes what's going on in a pfifo_fast qdisc:

We see that packets are placed in queues depending on their priority. When the time comes for the interface to send the next packet (frame actually, but let's not get into that), it will always choose to send the packet with the highest priority. That means that if multiple packets are waiting, those with the highest priority will be sent first. Note that this requires the interface to be congested - if the interface isn't congested and packets are sent as soon as they arrive from the OS, then there is no queuing and therefore no prioritization.

Other qdiscs have different structures and policies. For example an SFQ qdisc:

With that in mind, let's get back to your questions:

1. Depending on the qdisc, yes, packets from socket_11 may be sent ahead of packets from other sockets. If pfifo_fast is used, and if socket_11 sends enough traffic to saturate the outbound network interface, then the packets from the other sockets might even not be sent at all. This is unlikely in practice since it's usually hard to saturate a network interface before saturating some other resource, unless it's a wireless interface.

2. The path that packets take from the machine's network interface to the socket is much faster than the network itself. And, as you recall, for prioritization to have any effect, there has to be congestion. In a typical scenario, packets that reached as far as your network interface have already passed the bottleneck of their journey across the network, so congestion is unlikely.

   You can of course use an ingress qdisc or other mechanisms to artificially create a bottleneck, and prioritize incoming traffic. But why would you? That only makes sense if you're building a traffic shaper or a similar network device. Plus, since this qdiscs are a low level mechanism that happens well below the higher level sockets (even before bridging or routing), I doubt that the socket's priority could have any effect on in.

3. Not that I'm aware of, but I'd be happy to learn. This kernel module comes close, but it doesn't seem to be able to show priority flags, just regular socket options.

Answers on your questions:

1. Yes by default, explanation is below
2. No priorities work only on send, explanation is also below
3. I don't think so because this options is not seen even via /proc interface

Details about 1

Some words about priorities, network queues and device disciplines. All this stuff is related to quality of service and particularly to Differentiated Services (DiffServ).

When packet is sent then it put to interface "queue" that processed by network device. By default queue is not real queue but three real fifos that are strongly prioritised. If there is packet in fifo0 than packets in fifo1 waiting. Socket priority is mapped to this fifo by following mapping:

• 0 (Best Effort) is fifo1
• 1-3 (Filler, Bulk, ...) is fifo2
• 4 is fifo1
• 5 is fifo2
• 6-7 (Interactive, Control) is fifo0
• 8-15 is fifo1

So priority 1 will be dispatched after priority 0.

For changing default behaviour "traffic control" (tc) utility is used. With it you can configure priority queues on the network interface. This is so called "device queueing discipline". You can define how priorities are served by the particular network device (answer of Malt has good explanation of this).

Details about 2

Socket has states "ready for read"/"not ready for read" and this is bool. If any data is arrived to not ready socket it changes state from "not ready" to "ready" and this is seen by functions like select/poll or by returning from blocked recv call. What thread will be woken depends not by socket priority but by thread priority.

So if you want to prioritise sockets you need

• either put them on prioritized threads
• or prioritise by code after select/poll