Netdev Archive on lore.kernel.org
help / color / mirror / Atom feed
From: "Bjørn Mork" <bjorn@mork.no>
To: subashab@codeaurora.org
Cc: Aleksander Morgado <aleksander@aleksander.es>,
	Daniele Palmas <dnlplm@gmail.com>,
	Network Development <netdev@vger.kernel.org>,
	Sean Tranchetti <stranche@codeaurora.org>
Subject: Re: RMNET QMAP data aggregation with size greater than 16384
Date: Sat, 07 Aug 2021 12:55:29 +0200	[thread overview]
Message-ID: <87sfzlplr2.fsf@miraculix.mork.no> (raw)
In-Reply-To: <2c2d1204842f457bb0d0b2c4cd58847d@codeaurora.org> (subashab@codeaurora.org's message of "Fri, 06 Aug 2021 16:30:42 -0600")

subashab@codeaurora.org writes:

> Would something like this work-


Looking pretty good to me, but I believe it needs some polishing.

> diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
> index 6a2e4f8..c49827e 100644
> --- a/drivers/net/usb/qmi_wwan.c
> +++ b/drivers/net/usb/qmi_wwan.c
> @@ -75,6 +75,8 @@ struct qmimux_priv {
>         u8 mux_id;
>  };
>
> +#define MAP_DL_URB_SIZE (32768)

No need for () around a constant, is there?

>  static int qmimux_open(struct net_device *dev)
>  {
>         struct qmimux_priv *priv = netdev_priv(dev);
> @@ -303,6 +305,33 @@ static void qmimux_unregister_device(struct
> net_device *dev,
>         dev_put(real_dev);
>  }
>
> +static int qmi_wwan_change_mtu(struct net_device *net, int new_mtu)
> +{
> +       struct usbnet *dev = netdev_priv(net);
> +       struct qmi_wwan_state *info = (void *)&dev->data;
> +       int old_rx_urb_size = dev->rx_urb_size;
> +
> +       /* mux and pass through modes use a fixed rx_urb_size and the
> value
> +        * is independent of mtu
> +        */
> +       if (info->flags & (QMI_WWAN_FLAG_MUX |
> QMI_WWAN_FLAG_PASS_THROUGH)) {
> +               if (old_rx_urb_size == MAP_DL_URB_SIZE)
> +                       return 0;
> +
> +               if (old_rx_urb_size < MAP_DL_URB_SIZE) {
> +                       usbnet_pause_rx(dev);
> +                       usbnet_unlink_rx_urbs(dev);
> +                       usbnet_resume_rx(dev);
> +                       usbnet_update_max_qlen(dev);
> +               }
> +
> +               return 0;
> +       }
> +
> +       /* rawip mode uses existing logic of setting rx_urb_size based
> on mtu */
> +       return usbnet_change_mtu(net, new_mtu);
> +}

Either I'm blind, or you don't actuelly change the rx_urb_size for the
mux and pass through modes?


I'd also prefer this to reset back to syncing with hard_mtu if/when
muxing or passthrough is disabled.  Calling usbnet_change_mtu() won't do
that. It doesn't touch rx_urb_size if it is different from hard_mtu.

I also think that it might be useful to keep the mtu/hard_mtu control,
wouldn't it?


Something like

   old_rx_urb_size = dev->rx_urb_size;
   if (mux|passthrough)
       dev->rx_urb_size = MAP_DL_URB_SIZE;
   else
       dev->rx_urb_size = dev->hard_mtu;
   if (dev->rx_urb_size > old_rx_urb_size)
       unlink_urbs etc;
   return usbnet_change_mtu(net, new_mtu);

should do that, I think.  Completely untested....



> +
>  static void qmi_wwan_netdev_setup(struct net_device *net)
>  {
>         struct usbnet *dev = netdev_priv(net);
> @@ -326,7 +355,7 @@ static void qmi_wwan_netdev_setup(struct
> net_device *net)
>         }
>
>         /* recalculate buffers after changing hard_header_len */
> -       usbnet_change_mtu(net, net->mtu);
> +       qmi_wwan_change_mtu(net, net->mtu);
>  }
>
>  static ssize_t raw_ip_show(struct device *d, struct device_attribute
>  *attr, char *buf)
> @@ -433,6 +462,7 @@ static ssize_t add_mux_store(struct device *d,
> struct device_attribute *attr, c
>         if (!ret) {
>                 info->flags |= QMI_WWAN_FLAG_MUX;
>                 ret = len;
> +               qmi_wwan_change_mtu(dev->net, dev->net->mtu);
>         }
>  err:
>         rtnl_unlock();
> @@ -514,6 +544,8 @@ static ssize_t pass_through_store(struct device *d,
>         else
>                 info->flags &= ~QMI_WWAN_FLAG_PASS_THROUGH;
>
> +       qmi_wwan_change_mtu(dev->net, dev->net->mtu);
> +
>         return len;
>  }


And add it to the (!qmimux_has_slaves(dev)) cas in del_mux_store() too.


Bjørn

  reply	other threads:[~2021-08-07 10:55 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-31 22:45 RMNET QMAP data aggregation with size greater than 16384 Aleksander Morgado
2021-08-05 19:10 ` subashab
2021-08-05 20:32   ` Aleksander Morgado
     [not found]     ` <CAGRyCJHYkH4_FvTzk7BFwjMN=iOTN_Y2=4ueY=s3rJMQO9j7uw@mail.gmail.com>
2021-08-05 21:01       ` Aleksander Morgado
2021-08-05 21:12         ` Daniele Palmas
2021-08-05 22:57     ` subashab
2021-08-06 14:08       ` Aleksander Morgado
2021-08-06 18:42         ` subashab
2021-08-06 19:58           ` Bjørn Mork
2021-08-06 20:22             ` Aleksander Morgado
2021-08-06 22:30               ` subashab
2021-08-07 10:55                 ` Bjørn Mork [this message]
2021-08-09 21:40                   ` subashab
2021-08-12 12:02                     ` Daniele Palmas
2021-08-13  6:21                       ` subashab
2021-08-13  6:25                         ` Bjørn Mork
2021-09-03 13:55                           ` Daniele Palmas
2021-09-08  6:21                             ` subashab

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=87sfzlplr2.fsf@miraculix.mork.no \
    --to=bjorn@mork.no \
    --cc=aleksander@aleksander.es \
    --cc=dnlplm@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=stranche@codeaurora.org \
    --cc=subashab@codeaurora.org \
    /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).