linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stefan Schmidt <stefan@datenfreihafen.org>
To: "Clément Péron" <peron.clem@gmail.com>,
	"Romuald Cari" <romuald.cari@devialet.com>,
	linux-wpan@vger.kernel.org
Cc: "Alexander Aring" <alex.aring@gmail.com>,
	"Stefan Schmidt" <stefan@osg.samsung.com>,
	"David S . Miller" <davem@davemloft.net>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	"Clément Peron" <clement.peron@devialet.com>
Subject: Re: [PATCH] ieee802154: add rx LQI from userspace
Date: Mon, 9 Jul 2018 10:49:08 +0200	[thread overview]
Message-ID: <ac0ff951-627d-9694-741d-03f6bc4d6ddc@datenfreihafen.org> (raw)
In-Reply-To: <20180607140802.22666-1-peron.clem@gmail.com>

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 <romuald.cari@devialet.com>
> 
> 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 <romuald.cari@devialet.com>
> Signed-off-by: Clément Peron <clement.peron@devialet.com>
> ---
>  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 <linux/termios.h>	/* For TIOCOUTQ/INQ */
>  #include <linux/list.h>
>  #include <linux/slab.h>
> +#include <linux/socket.h>
>  #include <net/datalink.h>
>  #include <net/psnap.h>
>  #include <net/sock.h>
> @@ -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

  parent reply	other threads:[~2018-07-09  8:49 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-07 14:08 [PATCH] ieee802154: add rx LQI from userspace Clément Péron
2018-07-02 13:28 ` Clément Péron
2018-07-02 13:58   ` Stefan Schmidt
2018-07-02 17:53   ` Alexander Aring
2018-07-09  8:49 ` Stefan Schmidt [this message]
2018-07-09 21:17   ` Alexander Aring
2018-07-10 15:13   ` Clément Péron
2018-07-13 15:43     ` Stefan Schmidt
2018-08-06  9:07 ` Stefan Schmidt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ac0ff951-627d-9694-741d-03f6bc4d6ddc@datenfreihafen.org \
    --to=stefan@datenfreihafen.org \
    --cc=alex.aring@gmail.com \
    --cc=clement.peron@devialet.com \
    --cc=davem@davemloft.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-wpan@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=peron.clem@gmail.com \
    --cc=romuald.cari@devialet.com \
    --cc=stefan@osg.samsung.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).