[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAGRyCJEXLF7pbghH83scyO6mjAP3Emo32sgfQOcTeGSyToctMQ@mail.gmail.com>
Date: Mon, 21 Nov 2022 08:00:51 +0100
From: Daniele Palmas <dnlplm@...il.com>
To: "Subash Abhinov Kasiviswanathan (KS)" <quic_subashab@...cinc.com>
Cc: Bjørn Mork <bjorn@...k.no>,
Alexander Lobakin <alexandr.lobakin@...el.com>,
David Miller <davem@...emloft.net>,
Jakub Kicinski <kuba@...nel.org>,
Paolo Abeni <pabeni@...hat.com>,
Eric Dumazet <edumazet@...gle.com>,
Sean Tranchetti <quic_stranche@...cinc.com>,
Jonathan Corbet <corbet@....net>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
netdev@...r.kernel.org
Subject: Re: [PATCH net-next 2/3] net: qualcomm: rmnet: add tx packets aggregation
Il giorno dom 20 nov 2022 alle ore 18:48 Subash Abhinov
Kasiviswanathan (KS) <quic_subashab@...cinc.com> ha scritto:
>
> On 11/20/2022 2:52 AM, Daniele Palmas wrote:
> > Il giorno dom 20 nov 2022 alle ore 10:39 Bjørn Mork <bjorn@...k.no> ha scritto:
> >>
> >> Daniele Palmas <dnlplm@...il.com> writes:
> >>
> >>> Ok, so rmnet would only take care of qmap rx packets deaggregation and
> >>> qmi_wwan of the tx aggregation.
> >>>
> >>> At a conceptual level, implementing tx aggregation in qmi_wwan for
> >>> passthrough mode could make sense, since the tx aggregation parameters
> >>> belong to the physical device and are shared among the virtual rmnet
> >>> netdevices, which can't have different aggr configurations if they
> >>> belong to the same physical device.
> >>>
> >>> Bjørn, would this approach be ok for you?
> >>
> >> Sounds good to me, if this can be done within the userspace API
> >> restrictions we've been through.
> >>
> >> I assume it's possible to make this Just Work(tm) in qmi_wwan
> >> passthrough mode? I do not think we want any solution where the user
> >> will have to configure both qmi_wwan and rmnet to make things work
> >> properly.
> >>
> >
> > Yes, I think so: the ethtool configurations would apply to the
> > qmi_wwan netdevice so that nothing should be done on the rmnet side.
> >
> > Regards,
> > Daniele
>
> My only concern against this option is that we would now need to end up
> implementing the same tx aggregation logic in the other physical device
> drivers - mhi_netdev & ipa. Keeping this tx aggregation logic in rmnet
> allows you to leverage it across all these various physical devices.
Yes, that's true.
But according to this discussion, the need for tx aggregation seems
relevant just to USB devices (and maybe also a minority of them, since
so far no one complained about it lacking), isn't it?
Regards,
Daniele
Powered by blists - more mailing lists