In D26652#593856, @roy_marples.name wrote:

In D26652#593850, @tuexen wrote:

In D26652#593848, @roy_marples.name wrote:

In D26652#593846, @emaste wrote:

what other OSes share this API now?

I originally implemented on NetBSD and ported it to DragonFly BSD.
OpenBSD has an API which dhcpcd also uses which is specific to the route(4) API where it sends a RTM_DESYNC message.
The irony being it has to send a message on a socket which has already overflowed.

Maybe one can force that such a message (only one) is appended to the socket buffer even if it is full.

I believe they have a system where if the message doesn't fit they flush some or all of the buffer to ensure it does.

This API covers all sockets and is not limited to route(4) and thus has greater application outside of dhcpcd.

Well, I'm not sure how useful it is for, let's say, UDP based communication. UDP is unreliable. Any application can't assume that it sees all messages. A receiver buffer overflow is only one reason why a message can not be delivered. So why should I care as an application writer?

For example, a syslogd implementation could use it to notify the admin that potentially important messages have been lost - ie from, over the network.

How would you know that a packet is dropped in the network?

It could also be dropped locally.
We recently increased the size of some buffers on NetBSD as we discovered boot time messages from some daemons were being discarded as some apps were too noisy on startup.
UDP is an unreliable network protocol sure - but in this patch you will note that I have solved some comments such as /* should notify about lost packet */

Linux as an equivalent socket option like this, but it only applies to their equivalent of route(4).

I think it makes sense to limit the scope...

Well, any fix needs to go into the raw sockets code where the call to sbappendaddr() fails.
Once that is realised then it makes sense to try and cover all uses of sbappendaddr() with a generic API.
From a dhcpcd perspective I only care about route(4), but as an engineer I see a chance to do better.
Remember, this is opt-in.

In D26652#593850, @tuexen wrote:

In D26652#593848, @roy_marples.name wrote:

In D26652#593846, @emaste wrote:

what other OSes share this API now?

I originally implemented on NetBSD and ported it to DragonFly BSD.
OpenBSD has an API which dhcpcd also uses which is specific to the route(4) API where it sends a RTM_DESYNC message.
The irony being it has to send a message on a socket which has already overflowed.

Maybe one can force that such a message (only one) is appended to the socket buffer even if it is full.

This API covers all sockets and is not limited to route(4) and thus has greater application outside of dhcpcd.

Well, I'm not sure how useful it is for, let's say, UDP based communication. UDP is unreliable. Any application can't assume that it sees all messages. A receiver buffer overflow is only one reason why a message can not be delivered. So why should I care as an application writer?

For example, a syslogd implementation could use it to notify the admin that potentially important messages have been lost - ie from, over the network.

How would you know that a packet is dropped in the network?

I don't know if a packet is dropped in the network.
We do know if a packet is dropped in the host, and this allows an action to be taken on that.
As it stands now everything is silently discarded.

Correct.

Linux as an equivalent socket option like this, but it only applies to their equivalent of route(4).

I think it makes sense to limit the scope...

Why would you want to limit the scope?

Because an application writer might get the impression that he/she will be notified if an incoming packet was dropped. This is not true since this patch only covers one of many reasons. If any application wants to detect this, it should add some sequence numbers to the data and it will know.

In D26652#593848, @roy_marples.name wrote:

In D26652#593846, @emaste wrote:

what other OSes share this API now?

I originally implemented on NetBSD and ported it to DragonFly BSD.
OpenBSD has an API which dhcpcd also uses which is specific to the route(4) API where it sends a RTM_DESYNC message.
The irony being it has to send a message on a socket which has already overflowed.

Maybe one can force that such a message (only one) is appended to the socket buffer even if it is full.

This API covers all sockets and is not limited to route(4) and thus has greater application outside of dhcpcd.

Well, I'm not sure how useful it is for, let's say, UDP based communication. UDP is unreliable. Any application can't assume that it sees all messages. A receiver buffer overflow is only one reason why a message can not be delivered. So why should I care as an application writer?

For example, a syslogd implementation could use it to notify the admin that potentially important messages have been lost - ie from, over the network.

How would you know that a packet is dropped in the network?

Linux as an equivalent socket option like this, but it only applies to their equivalent of route(4).

I think it makes sense to limit the scope...

Not sure about showing the TCP stack name and the TCP congestion under the same flag. The TCP congestion control name scales to other transports, the TCP stack name doesn't.

Another question: what about RACK and BBR? Do they need a similar change?

Move CC name up as suggested by Richard.

Address Richard's comment.

In D26410#587502, @rscheff wrote:

In the man page, do we want to refer to RFC2474 and RFC3168, so that people are at least warned when the tos / tclass bytes are using not only the DSCP field, but also the ECN codepoints in ping / ping6 / traceroute / traceroute6?

In D26414#587458, @jilles wrote:

Perhaps it is better to match sockstat (D26413) and make the option -C instead of -c.

Use -C instead of -c.

Please add some documentation for the SOL_SOCKET level socket option SO_VLAN_PCP to the man page lib/libc/sys/getsockopt.2.

I ran the reproducers for RAVK and BBR and the problem does not show up anymore.