Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp298583imm; Mon, 9 Jul 2018 01:50:12 -0700 (PDT) X-Google-Smtp-Source: AAOMgpfRPUeqpgJiRfDkYwXMkeX2n2Ikn5PlvDUXRh9wt8AxPUXNLEChtLuLNAGFTCh2UX8sYE/D X-Received: by 2002:a17:902:8e87:: with SMTP id bg7-v6mr19721975plb.129.1531126212372; Mon, 09 Jul 2018 01:50:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1531126212; cv=none; d=google.com; s=arc-20160816; b=aCJTD7iNsZxeGKgYHEKtGns8xTTYHRED3OgyuP8RIAMUpv9xMO6VWMNuKde9OLqseS xYOb0cjNfhrRv0XyI9tM8VpmJ3gi0uEdcfCHxV+FjF+Hfd190BNOV0W8dhGdgUSsgC48 P1iiHqx5ezEpjTIhk58s74vZGuUk3SZ5LhVKRQ2GMmqfmUWnPBKw61I8SXlXe8ClbEtJ VCY1Eo4qVpX8UYhfKszd8AH9V27uYtq3QeeXs1AozCIRD1h7YDEagYCGeHfhOQ02tGsh EUITBV7vxWkAXbMrUCbUCaH34KV3RN0B0c7PhTLEVpVHGp22/SpPAikf6klZrFh9xApo fNWw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:arc-authentication-results; bh=k6DF2TmKE6OnVBRsPPULGZo+sCOhDCxZ02bn7CibKGw=; b=fo5O37wA6LrGFTKpcCWDtJfjD3qsB9WCK5YKLwx+n5SJBRT84sCzJqjYgsVxbsd3ob SNoA70QudZ7VRrAiN6nO3dxljoGDcudWdTEZ8FLRF+DIt14/cvNSBD+3pnjWW/igvhHG iQ3y2T1ZMUov7QDGAh+P5lX5/iH7UncGFW8CZ84xRPxSQkjhGTUn6/1pyJsasPQx3y5m meJPzHWK90px+QRCTS+IPU7iE+AmJVI9DcsWH+p0Kn/bpO4P03W4pQ+Cd4Mtu/Kqx3+S Uwdd4OeVB12FsmHF69xP/ekXuT+rvmkmPpWnCEHEa7pefAP3tYr10gpKvDAE+SpxRkaQ hjDA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h65-v6si14944067pfg.197.2018.07.09.01.49.57; Mon, 09 Jul 2018 01:50:12 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932466AbeGIItM (ORCPT + 99 others); Mon, 9 Jul 2018 04:49:12 -0400 Received: from proxima.lasnet.de ([78.47.171.185]:53431 "EHLO proxima.lasnet.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751211AbeGIItL (ORCPT ); Mon, 9 Jul 2018 04:49:11 -0400 Received: from [IPv6:2003:e9:d74b:829:3252:cbff:fe54:190f] (p200300E9D74B08293252CBFFFE54190F.dip0.t-ipconnect.de [IPv6:2003:e9:d74b:829:3252:cbff:fe54:190f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: stefan@datenfreihafen.org) by proxima.lasnet.de (Postfix) with ESMTPSA id EDFABC759F; Mon, 9 Jul 2018 10:49:08 +0200 (CEST) Subject: Re: [PATCH] ieee802154: add rx LQI from userspace To: =?UTF-8?B?Q2zDqW1lbnQgUMOpcm9u?= , Romuald Cari , linux-wpan@vger.kernel.org Cc: Alexander Aring , Stefan Schmidt , "David S . Miller" , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, =?UTF-8?Q?Cl=c3=a9ment_Peron?= References: <20180607140802.22666-1-peron.clem@gmail.com> From: Stefan Schmidt Message-ID: Date: Mon, 9 Jul 2018 10:49:08 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <20180607140802.22666-1-peron.clem@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello Clement. Finally coming to review the patch. Sorry for the delay. On 07.06.2018 16:08, Clément Péron wrote: > From: Romuald CARI > > The Link Quality Indication data exposed by drivers could not be accessed from > userspace. Since this data is per-datagram received, it makes sense to make it > available to userspace application through the ancillary data mechanism in > recvmsg rather than through ioctls. This can be activated using the socket > option WPAN_WANTLQI under SOL_IEEE802154 protocol. I can see that it makes the application life a lot easier to have data send out and LQI value synced up by using the socket approach instead of dealing with socket and ioctl's. I am good with this patch in general. So you have some public code that uses this approach? I would be interesting in the userspace part of yours. A demo would be fine. If the network handling part of your application is public anyway that would be even better. :-) As Alex mentioned we have some socket examples in the wpa-tools package to give people a head start when wanting to use the subsystem. Having such a simple example for the LQI feature would really give you bonus points. :-) https://github.com/linux-wpan/wpan-tools/tree/master/examples > > This LQI data is available in the ancillary data buffer under the SOL_IEEE802154 > level as the type WPAN_LQI. The value is an unsigned byte indicating the link > quality with values ranging 0-255. > > Signed-off-by: Romuald Cari > Signed-off-by: Clément Peron > --- > include/net/af_ieee802154.h | 1 + > net/ieee802154/socket.c | 17 +++++++++++++++++ > 2 files changed, 18 insertions(+) > > diff --git a/include/net/af_ieee802154.h b/include/net/af_ieee802154.h > index a5563d27a3eb..8003a9f6eb43 100644 > --- a/include/net/af_ieee802154.h > +++ b/include/net/af_ieee802154.h > @@ -56,6 +56,7 @@ struct sockaddr_ieee802154 { > #define WPAN_WANTACK 0 > #define WPAN_SECURITY 1 > #define WPAN_SECURITY_LEVEL 2 > +#define WPAN_WANTLQI 3 > > #define WPAN_SECURITY_DEFAULT 0 > #define WPAN_SECURITY_OFF 1 > diff --git a/net/ieee802154/socket.c b/net/ieee802154/socket.c > index a60658c85a9a..bc6b912603f1 100644 > --- a/net/ieee802154/socket.c > +++ b/net/ieee802154/socket.c > @@ -25,6 +25,7 @@ > #include /* For TIOCOUTQ/INQ */ > #include > #include > +#include > #include > #include > #include > @@ -452,6 +453,7 @@ struct dgram_sock { > unsigned int bound:1; > unsigned int connected:1; > unsigned int want_ack:1; > + unsigned int want_lqi:1; > unsigned int secen:1; > unsigned int secen_override:1; > unsigned int seclevel:3; > @@ -486,6 +488,7 @@ static int dgram_init(struct sock *sk) > struct dgram_sock *ro = dgram_sk(sk); > > ro->want_ack = 1; > + ro->want_lqi = 0; > return 0; > } > > @@ -713,6 +716,7 @@ static int dgram_recvmsg(struct sock *sk, struct msghdr *msg, size_t len, > size_t copied = 0; > int err = -EOPNOTSUPP; > struct sk_buff *skb; > + struct dgram_sock *ro = dgram_sk(sk); > DECLARE_SOCKADDR(struct sockaddr_ieee802154 *, saddr, msg->msg_name); > > skb = skb_recv_datagram(sk, flags, noblock, &err); > @@ -744,6 +748,13 @@ static int dgram_recvmsg(struct sock *sk, struct msghdr *msg, size_t len, > *addr_len = sizeof(*saddr); > } > > + if (ro->want_lqi) { > + err = put_cmsg(msg, SOL_IEEE802154, WPAN_WANTLQI, > + sizeof(uint8_t), &(mac_cb(skb)->lqi)); > + if (err) > + goto done; > + } > + I am wondering a bit about the LQI you get back here. Maybe Alex can also shed some lights on it. The LQI value stored here is always from the last frame send (to any peer)? Or is it the last frame send to this specific peer? I have not put much thoughts into the LQI thing so far.Just thinking we need to be careful what we are providing to not let userspace make bad decisions (e.g. wrong routing changes due to link values given for a different peer connection). > if (flags & MSG_TRUNC) > copied = skb->len; > done: > @@ -847,6 +858,9 @@ static int dgram_getsockopt(struct sock *sk, int level, int optname, > case WPAN_WANTACK: > val = ro->want_ack; > break; > + case WPAN_WANTLQI: > + val = ro->want_lqi; > + break; > case WPAN_SECURITY: > if (!ro->secen_override) > val = WPAN_SECURITY_DEFAULT; > @@ -892,6 +906,9 @@ static int dgram_setsockopt(struct sock *sk, int level, int optname, > case WPAN_WANTACK: > ro->want_ack = !!val; > break; > + case WPAN_WANTLQI: > + ro->want_lqi = !!val; > + break; > case WPAN_SECURITY: > if (!ns_capable(net->user_ns, CAP_NET_ADMIN) && > !ns_capable(net->user_ns, CAP_NET_RAW)) { > Review wise I am happy with the patch. I will give it a test. regards Stefan Schmidt