On Sun, 2019-04-14 at 13:09 -0600, Subash Abhinov Kasiviswanathan wrote:
> > Hmm, not sure I understand this. If you do RPS/RSS then that's a
> > hardware function, and the netdev doesn't really come into play
> > immediately? If the underlying driver directly deals with multiple
> > netdevs that'
Currently, iproute2 can be used to add the underlying dev as real_dev
and create rmnet links over it (ip link add link rmnet_ipa0 name
rmnet0 type
rmnet mux_id 1). Would this continue to work if -
1. the rmnet library were to be included directly as part of the
underlying driver itself
2. there
On Fri, 2019-04-12 at 16:27 +0200, Bjørn Mork wrote:
> Johannes Berg writes:
> > On Wed, 2019-04-10 at 21:54 -0600, Subash Abhinov Kasiviswanathan wrote:
> >
> > > These packets will be processed as raw IP muxed frames on the PC as
> > > well, not as ethernet though.
> >
> > But in order to tra
Johannes Berg writes:
> On Wed, 2019-04-10 at 21:54 -0600, Subash Abhinov Kasiviswanathan wrote:
>
>> These packets will be processed as raw IP muxed frames on the PC as
>> well, not as ethernet though.
>
> But in order to transport them, they're always encapsulated in ethernet?
No. There is no
On Wed, 2019-04-10 at 21:54 -0600, Subash Abhinov Kasiviswanathan wrote:
> > > We need raw IP frames from a embedded device transmitted to a PC
> > > and vice versa.
> >
> > Sure. But you just need to encap them in some kind of ethernet frame to
> > transport them on the wire, but don't really ne
OK. But it means that you have a very specific encapsulation mode on
top
of the "netdev". I'm still not convinced we should actually make that a
netdev, but I'll elaborate elsewhere.
I recall Daniele also managed to get rmnet working with qmi_wwan
(with an additional patch in which I had made q
On Sat, 2019-04-06 at 19:20 +0200, Daniele Palmas wrote:
>
> the qmi_wwan sysfs qmap feature, being very easy to use, is serving
> well for me and customers of the company I work for (mainly directly
> with libqmi, not ModemManager),
Yeah, I don't doubt this. In fact, we could arguably provide t
On Thu, 2019-04-04 at 22:45 -0600, Subash Abhinov Kasiviswanathan wrote:
> On 2019-04-04 14:38, Johannes Berg wrote:
> > Hi,
> >
> > > The normal mode of operation of rmnet is using the rmnet netdevices
> > > in an embedded device.
> >
> > Sure. Can you say what driver this would typically live o
Hi,
Il giorno ven 5 apr 2019 alle ore 06:45 Subash Abhinov Kasiviswanathan
ha scritto:
>
> On 2019-04-04 14:38, Johannes Berg wrote:
> > Hi,
> >
> >> The normal mode of operation of rmnet is using the rmnet netdevices
> >> in an embedded device.
> >
> > Sure. Can you say what driver this would ty
Hi,
Il giorno gio 4 apr 2019 alle ore 11:00 Johannes Berg
ha scritto:
> > > (2) Channels are created using sysfs (qmi_wwan)
> > >
> > > This feels almost worse - channels are created using sysfs and
> > > just *bam* new netdev shows up, no networking APIs are used to
> > > cr
On 2019-04-04 14:38, Johannes Berg wrote:
Hi,
The normal mode of operation of rmnet is using the rmnet netdevices
in an embedded device.
Sure. Can you say what driver this would typically live on top of? I'm
actually a bit surprised to find out this isn't really a driver :-)
This needs a p
On Thu, 2019-04-04 at 22:38 +0200, Johannes Berg wrote:
> > The bridge mode is used only for testing by sending frames
> > without de-muxing to some other driver such as a USB netdev so packets
> > can be parsed on a tethered PC.
>
> Yeah, I get it, it's just done in a strange way. You'd think ad
Hi,
> The normal mode of operation of rmnet is using the rmnet netdevices
> in an embedded device.
Sure. Can you say what driver this would typically live on top of? I'm
actually a bit surprised to find out this isn't really a driver :-)
In my view right now, I'd recommend splitting rmnet into t
On 2019-04-04 09:52, Dan Williams wrote:
On Thu, 2019-04-04 at 11:00 +0200, Johannes Berg wrote:
Hi,
> Thanks a lot for doing this! Being responsible for most of the
> issues
> you point out, I can only say that you have my full support if you
> want
> to change any of it.
:-)
> My pathetic
On Thu, 2019-04-04 at 11:00 +0200, Johannes Berg wrote:
> Hi,
>
> > Thanks a lot for doing this! Being responsible for most of the
> > issues
> > you point out, I can only say that you have my full support if you
> > want
> > to change any of it.
>
> :-)
>
> > My pathetic excuses below are just
Johannes Berg writes:
> Hi all,
>
> I've been looking at modem drivers, to see what the APIs are to interact
> with them, and while I originally thought I had the story sorted out ...
> not at all.
Thanks a lot for doing this! Being responsible for most of the issues
you point out, I can only s
Hi,
> Thanks a lot for doing this! Being responsible for most of the issues
> you point out, I can only say that you have my full support if you want
> to change any of it.
:-)
> My pathetic excuses below are just meant to clarify why things are the
> way they are. They are not a defense for s
Hi all,
I've been looking at modem drivers, to see what the APIs are to interact
with them, and while I originally thought I had the story sorted out ...
not at all.
Here's the current things we seem to be doing:
(1) Channels are created/encoded as VLANs (cdc_mbim)
This is ... strange a
18 matches
Mail list logo
