netdev - Re: [PATCH] af_packet: add interframe drop cmsg (v6)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 06 Oct 2009 13:05:42 +0200
From:	Oliver Hartkopp <socketcan@...tkopp.net>
To:	Eric Dumazet <eric.dumazet@...il.com>
CC:	Neil Horman <nhorman@...driver.com>,
	David Miller <davem@...emloft.net>, netdev@...r.kernel.org
Subject: Re: [PATCH] af_packet: add interframe drop cmsg (v6)

Eric Dumazet wrote:
> Oliver Hartkopp a écrit :
> 
>>> +	gap = check_packet_gap(skb);
>>> +	if (gap)
>>> +		put_cmsg(msg, SOL_PACKET, PACKET_GAPDATA, sizeof(__u32), &gap);
>>> +
>> I wonder, if using SOL_PACKET with a packet specific sockopt PACKET_GAPDATA is
>> the right approach here, as this functionality should probably be made
>> available to all DGRAM/RAW sockets ...
>>
>> E.g. getting the gap information is also interesting for CAN_RAW sockets as i
>> polled from the SocketCAN ML.
>>
>> So i could easily implement something like this in net/can/raw.c :
>>
>> gap = check_packet_gap(skb);
>> if (gap)
>> 	put_cmsg(msg, SOL_CAN_RAW, CAN_RAW_GAPDATA, sizeof(__u32), &gap);
>>
>> Is this a good approach or should we better find a general handling within
>> SOL_SOCKET here?
>>
> 
> 
> 
> Given that datagrams are usually lost by network before hitting your socket, I am not sure
> it is useful at all. 

It is :-)

Usually the datagrams ('CAN frames') do not get lost on the media. The problem
is, that userspace apps are scheduled. An on high CAN traffic load this may
lead to drops in the receive path on socket level.

It helps to increase the sockets receivebufsize with

  setsockopt(s, SOL_SOCKET, SO_RCVBUF, ...)

but it never gives an answer whether any frames have been dropped.

> 
> But yes, we could do the following for free :
> 
> Use existing sock->sk_drops total counter, and to store its value at time datagram 
> is received and stored into socket queue (store sock->sk_drops into skb->mark)
> 
> At recv() time, copy this saved value into a CMSG item if user set a given SOL_SOCKET option.
> 
> (It would not be a relative gap, but absolute. Your application would have to compute
> deltas itself)
> 

But this leads to two questions:

1. AFAICS we would add a cmsg to *any* received datagram then. Would this have
any remarkable impact to the performance?

2. If it is that easy: Does it still make sense for PF_PACKET to support a
separate PACKET_GAPDATA interface to the user?

Regards,
Oliver

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html