netdev - Re: [PATCH net-next v2] net: qualcomm: rmnet: Add side band flow control support

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]

Message-ID: <8cbd0969-0c1f-3c19-778b-4af9b3ad6417@linux.dev>
Date: Thu, 28 Sep 2023 01:12:24 +0100
From: Vadim Fedorenko <vadim.fedorenko@...ux.dev>
To: Subash Abhinov Kasiviswanathan <quic_subashab@...cinc.com>,
 davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org,
 pabeni@...hat.com, netdev@...r.kernel.org, lkp@...el.com
Cc: Sean Tranchetti <quic_stranche@...cinc.com>
Subject: Re: [PATCH net-next v2] net: qualcomm: rmnet: Add side band flow
 control support

On 26/09/2023 19:24, Subash Abhinov Kasiviswanathan wrote:
> Individual rmnet devices map to specific network types such as internet,
> multimedia messaging services, IP multimedia subsystem etc. Each of
> these network types may support varying quality of service for different
> bearers or traffic types.
> 
> The physical device interconnect to radio hardware may support a
> higher data rate than what is actually supported by the radio network.
> Any packets transmitted to the radio hardware which exceed the radio
> network data rate limit maybe dropped. This patch tries to minimize the
> loss of packets by adding support for bearer level flow control within a
> rmnet device by ensuring that the packets transmitted do not exceed the
> limit allowed by the radio network.
> 
> In order to support multiple bearers, rmnet must be created as a
> multiqueue TX netdevice. Radio hardware communicates the supported
> bearer information for a given network via side band signalling.
> Consider the following mapping -
> 
> IPv4 UDP port 1234 - Mark 0x1001 - Queue 1
> IPv6 TCP port 2345 - Mark 0x2001 - Queue 2
> 
> iptables can be used to install filters which mark packets matching these
> specific traffic patterns and the RMNET_QUEUE_MAPPING_ADD operation can
> then be to install the mapping of the mark to the specific txqueue.
> 
> If the traffic limit is exceeded for a particular bearer, radio hardware
> would notify that the bearer cannot accept more packets and the
> corresponding txqueue traffic can be stopped using RMNET_QUEUE_DISABLE.
> 
> Conversely, if radio hardware can send more traffic for a particular
> bearer, RMNET_QUEUE_ENABLE can be used to allow traffic on that
> particular txqueue. RMNET_QUEUE_MAPPING_REMOVE can be used to remove the
> mark to queue mapping in case the radio network doesn't support that
> particular bearer any longer.
> 
> Signed-off-by: Sean Tranchetti <quic_stranche@...cinc.com>
> Signed-off-by: Subash Abhinov Kasiviswanathan <quic_subashab@...cinc.com>
> ---
> v1 -> v2
>   Fix incorrect xarray API usage in rmnet_update_queue_map() and remove some
>   unneccessary checks in rmnet_vnd_select_queue() as mentioned by Vadim.
>   Fix UAPI types as reported by kernel test robot.
> 
>   .../ethernet/qualcomm/rmnet/rmnet_config.c    | 96 ++++++++++++++++++-
>   .../ethernet/qualcomm/rmnet/rmnet_config.h    |  2 +
>   .../net/ethernet/qualcomm/rmnet/rmnet_vnd.c   | 21 ++++
>   include/uapi/linux/if_link.h                  | 16 ++++
>   4 files changed, 134 insertions(+), 1 deletion(-)

[...]

> +static u16 rmnet_vnd_select_queue(struct net_device *dev,
> +				  struct sk_buff *skb,
> +				  struct net_device *sb_dev)
> +{
> +	struct rmnet_priv *priv = netdev_priv(dev);
> +	void *p = xa_load(&priv->queue_map, skb->mark);

Reverse X-mas tree, please.

> +	u8 txq;
> +
> +	if (!p || !xa_is_value(p))
> +		return 0;
> +
> +	txq = xa_to_value(p);
> +
> +	netdev_dbg(dev, "mark %08x -> txq %02x\n", skb->mark, txq);
> +	return txq;
> +}
> +