On Tue, 2019-06-18 at 09:00 -0500, Alex Elder wrote: > Deaggregation is a connection property, not a channel property. That'd make sense, yes. > And it looks like that's exactly how it's used in the rmnet > driver. Yeah, I think you're right. I got confused by the whole use of "port" there, but it seems like "port" actually refers to the underlying netdev. Which is really strange too, btw, because you configure the "port" to agg/non-agg when you add a new channel to it ... So it seems like it's part of the channel configuration, when it's not! Anyway, I think for now we could probably live with not having this configurable for the IPA driver, and if it *does* need to be configurable, it seems like it should be a driver configuration, not a channel configuration - so something like a debugfs hook if you really just need to play with it for performance testing, or a module parameter, or something else? Or even, in the WWAN framework, a knob that we provide there for the WWAN device, rather than for the (newly created) channel. > The hardware is capable of aggregating QMAP packets > arriving on a connection into a single buffer, so this provides > a way of requesting it do that. > > > > #define RMNET_FLAGS_INGRESS_MAP_COMMANDS (1U << 1) > > > > Similar here? If you have flow control you probably want to use it? > > I agree with that, though perhaps there are cases where it > is pointless, or can't be supported, so one might want to > simply *not* implement/advertise the feature. I don't know. Sure, but then that's likely something the driver would need to know, not necessarily userspace? johannes
