From: Daniele Palmas <dnlplm@gmail.com>
To: "Subash Abhinov Kasiviswanathan (KS)" <quic_subashab@quicinc.com>
Cc: "Alexander Lobakin" <alexandr.lobakin@intel.com>,
"David Miller" <davem@davemloft.net>,
"Jakub Kicinski" <kuba@kernel.org>,
"Paolo Abeni" <pabeni@redhat.com>,
"Eric Dumazet" <edumazet@google.com>,
"Sean Tranchetti" <quic_stranche@quicinc.com>,
"Jonathan Corbet" <corbet@lwn.net>, "Bjørn Mork" <bjorn@mork.no>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
netdev@vger.kernel.org
Subject: Re: [PATCH net-next 2/3] net: qualcomm: rmnet: add tx packets aggregation
Date: Fri, 11 Nov 2022 23:00:32 +0100 [thread overview]
Message-ID: <CAGRyCJHEwqg8f-pGuCuboo-mE6gFaViX3e4v26LGCGuWjgAyWA@mail.gmail.com> (raw)
In-Reply-To: <b84e45e0-55e0-a1f5-e1cc-980983946019@quicinc.com>
Hello Subash,
Il giorno ven 11 nov 2022 alle ore 02:17 Subash Abhinov
Kasiviswanathan (KS) <quic_subashab@quicinc.com> ha scritto:
>
> On 11/10/2022 10:32 AM, Alexander Lobakin wrote:
> > From: Daniele Palmas <dnlplm@gmail.com>
> > Date: Wed, 9 Nov 2022 19:02:48 +0100
> >
> >> Bidirectional TCP throughput tests through iperf with low-cat
> >> Thread-x based modems showed performance issues both in tx
> >> and rx.
> >>
> >> The Windows driver does not show this issue: inspecting USB
> >> packets revealed that the only notable change is the driver
> >> enabling tx packets aggregation.
> >>
> >> Tx packets aggregation, by default disabled, requires flag
> >> RMNET_FLAGS_EGRESS_AGGREGATION to be set (e.g. through ip command).
> >>
> >> The maximum number of aggregated packets and the maximum aggregated
> >> size are by default set to reasonably low values in order to support
> >> the majority of modems.
> >>
> >> This implementation is based on patches available in Code Aurora
> >> repositories (msm kernel) whose main authors are
> >>
> >> Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>
> >> Sean Tranchetti <stranche@codeaurora.org>
> >>
> >> Signed-off-by: Daniele Palmas <dnlplm@gmail.com>
> >> ---
> >>
> >> +struct rmnet_egress_agg_params {
> >> + u16 agg_size;
> >
> > skbs can now be way longer than 64 Kb.
> >
>
> rmnet devices generally use a standard MTU (around 1500) size.
> Would it still be possible for >64kb to be generated as no relevant
> hw_features is set for large transmit offloads.
> Alternatively, are you referring to injection of packets explicitly, say
> via packet sockets.
>
> >> + u16 agg_count;
> >> + u64 agg_time_nsec;
> >> +};
> >> +
> > Do I get the whole logics correctly, you allocate a new big skb and
> > just copy several frames into it, then send as one chunk once its
> > size reaches the threshold? Plus linearize every skb to be able to
> > do that... That's too much of overhead I'd say, just handle S/G and
> > fraglists and make long trains of frags from them without copying
> > anything? Also BQL/DQL already does some sort of aggregation via
> > ::xmit_more, doesn't it? Do you have any performance numbers?
>
> The difference here is that hardware would use a single descriptor for
> aggregation vs multiple descriptors for scatter gather.
>
> I wonder if this issue is related to pacing though.
> Daniele, perhaps you can try this hack without enabling EGRESS
> AGGREGATION and check if you are able to reach the same level of
> performance for your scenario.
>
> --- a/drivers/net/ethernet/qualcomm/rmnet/rmnet_handlers.c
> +++ b/drivers/net/ethernet/qualcomm/rmnet/rmnet_handlers.c
> @@ -236,7 +236,7 @@ void rmnet_egress_handler(struct sk_buff *skb)
> struct rmnet_priv *priv;
> u8 mux_id;
>
> - sk_pacing_shift_update(skb->sk, 8);
> + skb_orphan(skb);
>
> orig_dev = skb->dev;
> priv = netdev_priv(orig_dev);
>
Sure, I'll test that on Monday.
> >
> >> diff --git a/include/uapi/linux/if_link.h b/include/uapi/linux/if_link.h
> >> index 5e7a1041df3a..09a30e2b29b1 100644
> >> --- a/include/uapi/linux/if_link.h
> >> +++ b/include/uapi/linux/if_link.h
> >> @@ -1351,6 +1351,7 @@ enum {
> >> #define RMNET_FLAGS_EGRESS_MAP_CKSUMV4 (1U << 3)
> >> #define RMNET_FLAGS_INGRESS_MAP_CKSUMV5 (1U << 4)
> >> #define RMNET_FLAGS_EGRESS_MAP_CKSUMV5 (1U << 5)
> >> +#define RMNET_FLAGS_EGRESS_AGGREGATION (1U << 6)
> >
> > But you could rely on the aggregation parameters passed via Ethtool
> > to decide whether to enable aggregation or not. If any of them is 0,
> > it means the aggregation needs to be disabled.
> > Otherwise, to enable it you need to use 2 utilities: the one that
> > creates RMNet devices at first and Ethtool after, isn't it too
> > complicated for no reason?
>
> Yes, the EGRESS AGGREGATION parameters can be added as part of the rmnet
> netlink policies.
>
Ack.
Thanks,
Daniele
> >
> >>
> >> enum {
> >> IFLA_RMNET_UNSPEC,
> >> --
> >> 2.37.1
> >
> > Thanks,
> > Olek
next prev parent reply other threads:[~2022-11-11 22:02 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-09 18:02 [PATCH net-next 0/3] add tx packets aggregation to ethtool and rmnet Daniele Palmas
2022-11-09 18:02 ` [PATCH net-next 1/3] ethtool: add tx aggregation parameters Daniele Palmas
2022-11-11 17:07 ` Jakub Kicinski
2022-11-11 21:51 ` Daniele Palmas
2022-11-13 9:48 ` Gal Pressman
2022-11-14 10:06 ` Daniele Palmas
2022-11-14 10:45 ` Dave Taht
2022-11-15 11:51 ` Daniele Palmas
2022-11-15 15:27 ` Dave Taht
2022-11-15 0:42 ` Jakub Kicinski
2022-11-15 10:59 ` Gal Pressman
2022-11-15 16:21 ` Jakub Kicinski
2022-11-09 18:02 ` [PATCH net-next 2/3] net: qualcomm: rmnet: add tx packets aggregation Daniele Palmas
2022-11-10 17:32 ` Alexander Lobakin
2022-11-11 1:17 ` Subash Abhinov Kasiviswanathan (KS)
2022-11-11 17:11 ` Jakub Kicinski
2022-11-11 22:00 ` Daniele Palmas [this message]
2022-11-14 8:48 ` Daniele Palmas
2022-11-11 17:23 ` Daniele Palmas
2022-11-16 15:19 ` Daniele Palmas
2022-11-16 16:20 ` Alexander Lobakin
2022-11-20 9:25 ` Daniele Palmas
2022-11-20 9:39 ` Bjørn Mork
2022-11-20 9:52 ` Daniele Palmas
2022-11-20 17:48 ` Subash Abhinov Kasiviswanathan (KS)
2022-11-21 7:00 ` Daniele Palmas
2022-11-24 3:32 ` Subash Abhinov Kasiviswanathan (KS)
2022-11-10 19:09 ` kernel test robot
2022-11-11 17:14 ` Jakub Kicinski
2022-11-14 9:13 ` Daniele Palmas
2022-11-14 10:25 ` Bjørn Mork
2022-11-15 0:43 ` Jakub Kicinski
2022-11-09 18:02 ` [PATCH net-next 3/3] net: qualcomm: rmnet: add ethtool support for configuring tx aggregation Daniele Palmas
2022-11-11 6:46 ` kernel test robot
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=CAGRyCJHEwqg8f-pGuCuboo-mE6gFaViX3e4v26LGCGuWjgAyWA@mail.gmail.com \
--to=dnlplm@gmail.com \
--cc=alexandr.lobakin@intel.com \
--cc=bjorn@mork.no \
--cc=corbet@lwn.net \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=gregkh@linuxfoundation.org \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=quic_stranche@quicinc.com \
--cc=quic_subashab@quicinc.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).