Re: [PATCH net-next 1/1 v2] net: rmnet_data: Initial implementation

2017-03-31 Thread Subash Abhinov Kasiviswanathan 

Yeah, seems quite a bit like VLAN (from a workflow perspective, not
quite as much from a protocol one) and I think the same workflow could
work for this too.  Would be nice to eventually get qmi_wwan onto the
same base, if possible (though we'd need to preserve the 802.3
capability somehow for devices that don't support raw-ip).

It doesn't necessarily mean that configuration would need to move to
the IP tool.  I just used it as an example of how VLAN works and how
rmnet could work as well, quite easily with the ip tool.

Since the ip tool is based on netlink, both it and your userspace
library could use the same netlink attributes and families to do the
same thing.

Essentially, I am recommending that instead of your current custom
netlink commands, port them over to rtnetlink which will mean less code
for you, and a more standard kernel interface for everyone.


Thanks for your comments. I'll work on conversion into rtnl_link_ops.

Ethernet frames are supported in pass through mode (though not used 
often)

but they cannot be used in conjunction with MAP functionality.


Does the aggregation happen at the level of the raw device, or at the
level of the MUX channels?  eg, can I aggregate packets from multiple
MUX channels into the same request, especially on USB devices?

Hardware does allow aggregation of packets from different mux channels 
in

a single frame.


One use-case is to put different packet data contexts into different
namespaces.  You could then isolate different EPS/PDP contexts by
putting them into different network namespaces, and for example have
your IMS handler only be able to access its own EPS/PDP context.

We could already do this with qmi_wwan on devices that provide multiple
USB endpoints for QMI/rmnet, but I thought the point of the MUX
protocol was to allow a single endpoint for rmnet that can MUX multiple
packet data contexts.  So it would be nice to allow each rmnet netdev
to be placed into a different network namespace.


I need to study more about namespaces since I am not familiar with it.
I'll add support for it in a follow up patchset.


Like a usb gadget rmnet interface for debugging?


Yes, its mostly used for test only.
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora 
Forum,

a Linux Foundation Collaborative Project

Re: [PATCH net-next 1/1 v2] net: rmnet_data: Initial implementation

2017-03-31 Thread Dan Williams 
On Fri, 2017-03-24 at 18:49 -0600, Subash Abhinov Kasiviswanathan
wrote:
> > (re-sending from an address that's actually subscribed to
> > netdev@...)
> > 
> > The first thing that jumps out at me is "why isn't this using
> > rtnl_link_ops?"
> > 
> > To me (and perhaps I'm completely wrong) the structure here is a
> > lot
> > like VLAN interfaces.  You have a base device (whether that's a
> > netdev
> > or not) and you essentially "ip link add link cdc-wdm0 name rmnet0
> > type
> > rmnet id 5".  Does the aggregation happen only on the downlink (eg,
> > device -> host) or can the host send aggregated packets too?
> 
> Hi Dan
> 
> Yes, you are correct. We associate this driver with a physical
> device 
> and
> then create rmnet devices over it as needed for multiplexing.

Yeah, seems quite a bit like VLAN (from a workflow perspective, not
quite as much from a protocol one) and I think the same workflow could
work for this too.  Would be nice to eventually get qmi_wwan onto the
same base, if possible (though we'd need to preserve the 802.3
capability somehow for devices that don't support raw-ip).

> Aggregation is supported both on downlink and uplink by Qualcomm
> Technologies, Inc. modem hardware. This initial patchset implements
> only
> downlink aggregation since uplink aggregation is rarely enabled or
> used.
> I'll send a separate patchset for that.

Does the aggregation happen at the level of the raw device, or at the
level of the MUX channels?  eg, can I aggregate packets from multiple
MUX channels into the same request, especially on USB devices?

> > Using rtnl_link_ops would get rid of ASSOC_NET_DEV,
> > UNASSOC_NET_DEV,
> > NEW_VND, NEW_VND_WITH_PREFIX, and FREE_VND.  GET_NET_DEV_ASSOC goes
> > away becuase you use normal 'kobject' associations and you can
> > derive
> > the rmnet parent through sysfs links.  rmnet_nl_msg_s goes away,
> > because you can use nla_policy.
> > 
> > Just a thought; there seems to be a ton of overlap with
> > rtnl_link_ops
> > in the control plane here.
> 
> As of now, we have been using a custom netlink userspace tool for
> configuring the interfaces by listening to RMNET_NETLINK_PROTO
> events.
> Does that mean that configuration needs to be moved to ip tool by
> adding a new option for rmnet (like how you have mentioned above)
> and add additional options for end point configuration as well?

It doesn't necessarily mean that configuration would need to move to
the IP tool.  I just used it as an example of how VLAN works and how
rmnet could work as well, quite easily with the ip tool.

Since the ip tool is based on netlink, both it and your userspace
library could use the same netlink attributes and families to do the
same thing.

Essentially, I am recommending that instead of your current custom
netlink commands, port them over to rtnetlink which will mean less code
for you, and a more standard kernel interface for everyone.

> > Any thoughts on how this plays with net namespaces?
> 
> We have not tried it with different net namespaces since we never had
> such use cases internally. We can look into this.

One use-case is to put different packet data contexts into different
namespaces.  You could then isolate different EPS/PDP contexts by
putting them into different network namespaces, and for example have
your IMS handler only be able to access its own EPS/PDP context.

We could already do this with qmi_wwan on devices that provide multiple
USB endpoints for QMI/rmnet, but I thought the point of the MUX
protocol was to allow a single endpoint for rmnet that can MUX multiple
packet data contexts.  So it would be nice to allow each rmnet netdev
to be placed into a different network namespace.

> > Also, I'm not sure if it make sense to provide first class
> > tracepoints
> > for a specific driver, as it's not clear if they are userspace API
> > or
> > not and thus may need to be kept stable.   Or are perf probes
> > enough
> > instead?
> 
> We have some tracepoints which are in datapath and some for specific
> events such as device unregistration and configuration events 
> association.
> Most of these devices are on ARM64 and need to support older kernels,
> (from 3.10) so we had to rely on tracepoints. I believe ARM64 got
> trace
> point support somewhat recently. I was not aware of the restriction
> of
> tracepoints, so I can remove that.

Yeah, best to remove that for now, you can propose to add them back
later and see what people say.

> > 
> > What's RMNET_EPMODE_BRIDGE and how is it used?
> 
> RMNET_EPMODE_BRIDGE is for bridging two different physical
> interfaces.
> An example is sending raw bytes from hardware to USB - this can be
> used
> if a PC connected by USB would require the data in the MAP format.

Like a usb gadget rmnet interface for debugging?

Dan

Re: [PATCH net-next 1/1 v2] net: rmnet_data: Initial implementation

2017-03-24 Thread Subash Abhinov Kasiviswanathan 

(re-sending from an address that's actually subscribed to netdev@...)

The first thing that jumps out at me is "why isn't this using
rtnl_link_ops?"

To me (and perhaps I'm completely wrong) the structure here is a lot
like VLAN interfaces.  You have a base device (whether that's a netdev
or not) and you essentially "ip link add link cdc-wdm0 name rmnet0 type
rmnet id 5".  Does the aggregation happen only on the downlink (eg,
device -> host) or can the host send aggregated packets too?


Hi Dan

Yes, you are correct. We associate this driver with a physical device 
and

then create rmnet devices over it as needed for multiplexing.

Aggregation is supported both on downlink and uplink by Qualcomm
Technologies, Inc. modem hardware. This initial patchset implements only
downlink aggregation since uplink aggregation is rarely enabled or used.
I'll send a separate patchset for that.


Using rtnl_link_ops would get rid of ASSOC_NET_DEV, UNASSOC_NET_DEV,
NEW_VND, NEW_VND_WITH_PREFIX, and FREE_VND.  GET_NET_DEV_ASSOC goes
away becuase you use normal 'kobject' associations and you can derive
the rmnet parent through sysfs links.  rmnet_nl_msg_s goes away,
because you can use nla_policy.

Just a thought; there seems to be a ton of overlap with rtnl_link_ops
in the control plane here.


As of now, we have been using a custom netlink userspace tool for
configuring the interfaces by listening to RMNET_NETLINK_PROTO events.
Does that mean that configuration needs to be moved to ip tool by
adding a new option for rmnet (like how you have mentioned above)
and add additional options for end point configuration as well?


Any thoughts on how this plays with net namespaces?


We have not tried it with different net namespaces since we never had
such use cases internally. We can look into this.


Also, I'm not sure if it make sense to provide first class tracepoints
for a specific driver, as it's not clear if they are userspace API or
not and thus may need to be kept stable.   Or are perf probes enough
instead?


We have some tracepoints which are in datapath and some for specific
events such as device unregistration and configuration events 
association.

Most of these devices are on ARM64 and need to support older kernels,
(from 3.10) so we had to rely on tracepoints. I believe ARM64 got trace
point support somewhat recently. I was not aware of the restriction of
tracepoints, so I can remove that.



What's RMNET_EPMODE_BRIDGE and how is it used?


RMNET_EPMODE_BRIDGE is for bridging two different physical interfaces.
An example is sending raw bytes from hardware to USB - this can be used
if a PC connected by USB would require the data in the MAP format.

--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora 
Forum,

a Linux Foundation Collaborative Project

Re: [PATCH net-next 1/1 v2] net: rmnet_data: Initial implementation

2017-03-24 Thread Dan Williams 
On Mon, 2017-03-13 at 01:43 -0600, Subash Abhinov Kasiviswanathan
wrote:
> RmNet Data driver provides a transport agnostic MAP (multiplexing and
> aggregation protocol) support in embedded and bridge modes. Module
> provides virtual network devices which can be attached to any IP-mode
> physical device. This will be used to provide all MAP functionality
> on future hardware in a single consistent location.

(re-sending from an address that's actually subscribed to netdev@...)

The first thing that jumps out at me is "why isn't this using
rtnl_link_ops?"

To me (and perhaps I'm completely wrong) the structure here is a lot
like VLAN interfaces.  You have a base device (whether that's a netdev
or not) and you essentially "ip link add link cdc-wdm0 name rmnet0 type
rmnet id 5".  Does the aggregation happen only on the downlink (eg,
device -> host) or can the host send aggregated packets too?

Using rtnl_link_ops would get rid of ASSOC_NET_DEV, UNASSOC_NET_DEV,
NEW_VND, NEW_VND_WITH_PREFIX, and FREE_VND.  GET_NET_DEV_ASSOC goes
away becuase you use normal 'kobject' associations and you can derive
the rmnet parent through sysfs links.  rmnet_nl_msg_s goes away,
because you can use nla_policy.

Just a thought; there seems to be a ton of overlap with rtnl_link_ops
in the control plane here.

Any thoughts on how this plays with net namespaces?

Also, I'm not sure if it make sense to provide first class tracepoints
for a specific driver, as it's not clear if they are userspace API or
not and thus may need to be kept stable.   Or are perf probes enough
instead?

What's RMNET_EPMODE_BRIDGE and how is it used?

Dan

> Signed-off-by: Subash Abhinov Kasiviswanathan
> 
> ---
>  Documentation/networking/rmnet_data.txt |   82 +++
>  include/uapi/linux/Kbuild   |1 +
>  include/uapi/linux/if_arp.h |1 +
>  include/uapi/linux/if_ether.h   |4 +-
>  include/uapi/linux/rmnet_data.h |  214 ++
>  net/Kconfig |1 +
>  net/Makefile|1 +
>  net/rmnet_data/Kconfig  |   21 +
>  net/rmnet_data/Makefile |   14 +
>  net/rmnet_data/rmnet_data_config.c  | 1168
> +++
>  net/rmnet_data/rmnet_data_config.h  |  107 +++
>  net/rmnet_data/rmnet_data_handlers.c|  556 +++
>  net/rmnet_data/rmnet_data_handlers.h|   24 +
>  net/rmnet_data/rmnet_data_main.c|   60 ++
>  net/rmnet_data/rmnet_data_private.h |   76 ++
>  net/rmnet_data/rmnet_data_stats.c   |   86 +++
>  net/rmnet_data/rmnet_data_stats.h   |   61 ++
>  net/rmnet_data/rmnet_data_trace.h   |  198 ++
>  net/rmnet_data/rmnet_data_vnd.c |  460 
>  net/rmnet_data/rmnet_data_vnd.h |   34 +
>  net/rmnet_data/rmnet_map.h  |  100 +++
>  net/rmnet_data/rmnet_map_command.c  |  180 +
>  net/rmnet_data/rmnet_map_data.c |  148 
>  23 files changed, 3596 insertions(+), 1 deletion(-)
>  create mode 100644 Documentation/networking/rmnet_data.txt
>  create mode 100644 include/uapi/linux/rmnet_data.h
>  create mode 100644 net/rmnet_data/Kconfig
>  create mode 100644 net/rmnet_data/Makefile
>  create mode 100644 net/rmnet_data/rmnet_data_config.c
>  create mode 100644 net/rmnet_data/rmnet_data_config.h
>  create mode 100644 net/rmnet_data/rmnet_data_handlers.c
>  create mode 100644 net/rmnet_data/rmnet_data_handlers.h
>  create mode 100644 net/rmnet_data/rmnet_data_main.c
>  create mode 100644 net/rmnet_data/rmnet_data_private.h
>  create mode 100644 net/rmnet_data/rmnet_data_stats.c
>  create mode 100644 net/rmnet_data/rmnet_data_stats.h
>  create mode 100644 net/rmnet_data/rmnet_data_trace.h
>  create mode 100644 net/rmnet_data/rmnet_data_vnd.c
>  create mode 100644 net/rmnet_data/rmnet_data_vnd.h
>  create mode 100644 net/rmnet_data/rmnet_map.h
>  create mode 100644 net/rmnet_data/rmnet_map_command.c
>  create mode 100644 net/rmnet_data/rmnet_map_data.c
> 
> diff --git a/Documentation/networking/rmnet_data.txt
> b/Documentation/networking/rmnet_data.txt
> new file mode 100644
> index 000..ff6cce8
> --- /dev/null
> +++ b/Documentation/networking/rmnet_data.txt
> @@ -0,0 +1,82 @@
> +1. Introduction
> +
> +rmnet_data driver is used for supporting the Multiplexing and
> aggregation
> +Protocol (MAP). This protocol is used by all recent chipsets using
> Qualcomm
> +Technologies, Inc. modems.
> +
> +This driver can be used to register onto any physical network device
> in
> +IP mode. Physical transports include USB, HSIC, PCIe and IP
> accelerator.
> +
> +Multiplexing allows for creation of logical netdevices (rmnet_data
> devices) to
> +handle multiple private data networks (PDN) like a default internet,
> tethering,
> +multimedia messaging service (MMS) or IP media subsystem (IMS).
> Hardware sends
> +packets with MAP headers to rmnet_data. Based on the multiplexer id,
> rmnet_data
> +routes to

Re: [PATCH net-next 1/1 v2] net: rmnet_data: Initial implementation

2017-03-24 Thread Dan Williams 
On Mon, 2017-03-13 at 01:43 -0600, Subash Abhinov Kasiviswanathan
wrote:
> RmNet Data driver provides a transport agnostic MAP (multiplexing and
> aggregation protocol) support in embedded and bridge modes. Module
> provides virtual network devices which can be attached to any IP-mode
> physical device. This will be used to provide all MAP functionality
> on future hardware in a single consistent location.

The first thing that jumps out at me is "why isn't this using
rtnl_link_ops?"

To me (and perhaps I'm completely wrong) the structure here is a lot
like VLAN interfaces.  You have a base device (whether that's a netdev
or not) and you essentially "ip link add link cdc-wdm0 name rmnet0 type
rmnet id 5".  Does the aggregation happen only on the downlink (eg,
device -> host) or can the host send aggregated packets too?

Using rtnl_link_ops would get rid of ASSOC_NET_DEV, UNASSOC_NET_DEV,
NEW_VND, NEW_VND_WITH_PREFIX, and FREE_VND.  GET_NET_DEV_ASSOC goes
away becuase you use normal 'kobject' associations and you can derive
the rmnet parent through sysfs links.  rmnet_nl_msg_s goes away,
because you can use nla_policy.

Just a thought; there seems to be a ton of overlap with rtnl_link_ops
in the control plane here.

Any thoughts on how this plays with net namespaces?

Also, I'm not sure if it make sense to provide first class tracepoints
for a specific driver, as it's not clear if they are userspace API or
not and thus may need to be kept stable.   Or are perf probes enough
instead?

What's RMNET_EPMODE_BRIDGE and how is it used?

Dan

> Signed-off-by: Subash Abhinov Kasiviswanathan
> 
> ---
>  Documentation/networking/rmnet_data.txt |   82 +++
>  include/uapi/linux/Kbuild   |1 +
>  include/uapi/linux/if_arp.h |1 +
>  include/uapi/linux/if_ether.h   |4 +-
>  include/uapi/linux/rmnet_data.h |  214 ++
>  net/Kconfig |1 +
>  net/Makefile|1 +
>  net/rmnet_data/Kconfig  |   21 +
>  net/rmnet_data/Makefile |   14 +
>  net/rmnet_data/rmnet_data_config.c  | 1168
> +++
>  net/rmnet_data/rmnet_data_config.h  |  107 +++
>  net/rmnet_data/rmnet_data_handlers.c|  556 +++
>  net/rmnet_data/rmnet_data_handlers.h|   24 +
>  net/rmnet_data/rmnet_data_main.c|   60 ++
>  net/rmnet_data/rmnet_data_private.h |   76 ++
>  net/rmnet_data/rmnet_data_stats.c   |   86 +++
>  net/rmnet_data/rmnet_data_stats.h   |   61 ++
>  net/rmnet_data/rmnet_data_trace.h   |  198 ++
>  net/rmnet_data/rmnet_data_vnd.c |  460 
>  net/rmnet_data/rmnet_data_vnd.h |   34 +
>  net/rmnet_data/rmnet_map.h  |  100 +++
>  net/rmnet_data/rmnet_map_command.c  |  180 +
>  net/rmnet_data/rmnet_map_data.c |  148 
>  23 files changed, 3596 insertions(+), 1 deletion(-)
>  create mode 100644 Documentation/networking/rmnet_data.txt
>  create mode 100644 include/uapi/linux/rmnet_data.h
>  create mode 100644 net/rmnet_data/Kconfig
>  create mode 100644 net/rmnet_data/Makefile
>  create mode 100644 net/rmnet_data/rmnet_data_config.c
>  create mode 100644 net/rmnet_data/rmnet_data_config.h
>  create mode 100644 net/rmnet_data/rmnet_data_handlers.c
>  create mode 100644 net/rmnet_data/rmnet_data_handlers.h
>  create mode 100644 net/rmnet_data/rmnet_data_main.c
>  create mode 100644 net/rmnet_data/rmnet_data_private.h
>  create mode 100644 net/rmnet_data/rmnet_data_stats.c
>  create mode 100644 net/rmnet_data/rmnet_data_stats.h
>  create mode 100644 net/rmnet_data/rmnet_data_trace.h
>  create mode 100644 net/rmnet_data/rmnet_data_vnd.c
>  create mode 100644 net/rmnet_data/rmnet_data_vnd.h
>  create mode 100644 net/rmnet_data/rmnet_map.h
>  create mode 100644 net/rmnet_data/rmnet_map_command.c
>  create mode 100644 net/rmnet_data/rmnet_map_data.c
> 
> diff --git a/Documentation/networking/rmnet_data.txt
> b/Documentation/networking/rmnet_data.txt
> new file mode 100644
> index 000..ff6cce8
> --- /dev/null
> +++ b/Documentation/networking/rmnet_data.txt
> @@ -0,0 +1,82 @@
> +1. Introduction
> +
> +rmnet_data driver is used for supporting the Multiplexing and
> aggregation
> +Protocol (MAP). This protocol is used by all recent chipsets using
> Qualcomm
> +Technologies, Inc. modems.
> +
> +This driver can be used to register onto any physical network device
> in
> +IP mode. Physical transports include USB, HSIC, PCIe and IP
> accelerator.
> +
> +Multiplexing allows for creation of logical netdevices (rmnet_data
> devices) to
> +handle multiple private data networks (PDN) like a default internet,
> tethering,
> +multimedia messaging service (MMS) or IP media subsystem (IMS).
> Hardware sends
> +packets with MAP headers to rmnet_data. Based on the multiplexer id,
> rmnet_data
> +routes to the appropriate PDN after removing the MAP header.
> +
> +Aggregation

Re: [PATCH net-next 1/1 v2] net: rmnet_data: Initial implementation

2017-03-14 Thread Subash Abhinov Kasiviswanathan 

I believe that this code should be a part of that driver, not a generic
code in net/




ok, so?


Hi Jiri

I will move it to drivers/net and rename it to rmnet.

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
Linux Foundation Collaborative Project

Re: [PATCH net-next 1/1 v2] net: rmnet_data: Initial implementation

2017-03-14 Thread Jiri Pirko 
Mon, Mar 13, 2017 at 11:01:15PM CET, subas...@codeaurora.org wrote:
>On 2017-03-13 02:54, Jiri Pirko wrote:
>> Mon, Mar 13, 2017 at 08:43:09AM CET, subas...@codeaurora.org wrote:
>> > RmNet Data driver provides a transport agnostic MAP (multiplexing and
>> 
>> Why "data"? Why not just "rmnet"??
>> 
>> Btw, what is "RmNet". Google does not give me much. Is it some
>> priprietady Qualcomm thing? Is there some standard behind it?
>> 
>
>Hi Jiri
>
>Rm interface is used to describe an application processor tethered to
>Qualcomm Technologies, Inc. modems. Since these are netdevices,

I believe that this code should be a part of that driver, not a generic
code in net/


>the term RmNet is used. I don't think there are published standards
>available for this but I can provide relevant information and
>document it as well.
>
>rmnet was used for a USB based physical transport earlier, hence
>this platform agnostic multiplexing driver was named as rmnet_data.

ok, so?

Re: [PATCH net-next 1/1 v2] net: rmnet_data: Initial implementation

2017-03-13 Thread kbuild test robot 
Hi Subash,

[auto build test WARNING on net-next/master]

url:
https://github.com/0day-ci/linux/commits/Subash-Abhinov-Kasiviswanathan/net-rmnet_data-Initial-implementation/20170313-174754
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__


sparse warnings: (new ones prefixed by >>)

   include/linux/compiler.h:264:8: sparse: attribute 'no_sanitize_address': 
unknown attribute
>> include/uapi/linux/rmnet_data.h:46:25: sparse: invalid bitfield specifier 
>> for type restricted __le16.
   include/uapi/linux/rmnet_data.h:47:19: sparse: invalid bitfield specifier 
for type restricted __le16.

vim +46 include/uapi/linux/rmnet_data.h

30  #define RMNET_EGRESS_FORMAT_AGGREGATION (1<<2)
31  #define RMNET_EGRESS_FORMAT_MUXING  (1<<3)
32  #define RMNET_EGRESS_FORMAT_MAP_CKSUMV3 (1<<4)
33  #define RMNET_EGRESS_FORMAT_MAP_CKSUMV4 (1<<5)
34  
35  #define RMNET_INGRESS_FIX_ETHERNET  (1<<0)
36  #define RMNET_INGRESS_FORMAT_MAP(1<<1)
37  #define RMNET_INGRESS_FORMAT_DEAGGREGATION  (1<<2)
38  #define RMNET_INGRESS_FORMAT_DEMUXING   (1<<3)
39  #define RMNET_INGRESS_FORMAT_MAP_COMMANDS   (1<<4)
40  #define RMNET_INGRESS_FORMAT_MAP_CKSUMV3(1<<5)
41  #define RMNET_INGRESS_FORMAT_MAP_CKSUMV4(1<<6)
42  
43  struct rmnet_nl_msg_s {
44  __le16 reserved;
45  __le16 message_type;
  > 46  __le16 reserved2:14;
47  __le16 crd:2;
48  union {
49  __le16 arg_length;
50  __le16 return_code;
51  };
52  union {
53  __u8 data[RMNET_NL_DATA_MAX_LEN];
54  struct {

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation

Re: [PATCH net-next 1/1 v2] net: rmnet_data: Initial implementation

2017-03-13 Thread Subash Abhinov Kasiviswanathan 

On 2017-03-13 02:54, Jiri Pirko wrote:

Mon, Mar 13, 2017 at 08:43:09AM CET, subas...@codeaurora.org wrote:

RmNet Data driver provides a transport agnostic MAP (multiplexing and


Why "data"? Why not just "rmnet"??

Btw, what is "RmNet". Google does not give me much. Is it some
priprietady Qualcomm thing? Is there some standard behind it?



Hi Jiri

Rm interface is used to describe an application processor tethered to
Qualcomm Technologies, Inc. modems. Since these are netdevices,
the term RmNet is used. I don't think there are published standards
available for this but I can provide relevant information and
document it as well.

rmnet was used for a USB based physical transport earlier, hence
this platform agnostic multiplexing driver was named as rmnet_data.

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
Linux Foundation Collaborative Project

Re: [PATCH net-next 1/1 v2] net: rmnet_data: Initial implementation

2017-03-13 Thread Jiri Pirko 
Mon, Mar 13, 2017 at 08:43:09AM CET, subas...@codeaurora.org wrote:
>RmNet Data driver provides a transport agnostic MAP (multiplexing and

Why "data"? Why not just "rmnet"??

Btw, what is "RmNet". Google does not give me much. Is it some
priprietady Qualcomm thing? Is there some standard behind it?




>aggregation protocol) support in embedded and bridge modes. Module
>provides virtual network devices which can be attached to any IP-mode
>physical device. This will be used to provide all MAP functionality
>on future hardware in a single consistent location.
>
>Signed-off-by: Subash Abhinov Kasiviswanathan 
>---
> Documentation/networking/rmnet_data.txt |   82 +++
> include/uapi/linux/Kbuild   |1 +
> include/uapi/linux/if_arp.h |1 +
> include/uapi/linux/if_ether.h   |4 +-
> include/uapi/linux/rmnet_data.h |  214 ++
> net/Kconfig |1 +
> net/Makefile|1 +
> net/rmnet_data/Kconfig  |   21 +
> net/rmnet_data/Makefile |   14 +
> net/rmnet_data/rmnet_data_config.c  | 1168 +++
> net/rmnet_data/rmnet_data_config.h  |  107 +++
> net/rmnet_data/rmnet_data_handlers.c|  556 +++
> net/rmnet_data/rmnet_data_handlers.h|   24 +
> net/rmnet_data/rmnet_data_main.c|   60 ++
> net/rmnet_data/rmnet_data_private.h |   76 ++
> net/rmnet_data/rmnet_data_stats.c   |   86 +++
> net/rmnet_data/rmnet_data_stats.h   |   61 ++
> net/rmnet_data/rmnet_data_trace.h   |  198 ++
> net/rmnet_data/rmnet_data_vnd.c |  460 
> net/rmnet_data/rmnet_data_vnd.h |   34 +
> net/rmnet_data/rmnet_map.h  |  100 +++
> net/rmnet_data/rmnet_map_command.c  |  180 +
> net/rmnet_data/rmnet_map_data.c |  148 
> 23 files changed, 3596 insertions(+), 1 deletion(-)
> create mode 100644 Documentation/networking/rmnet_data.txt
> create mode 100644 include/uapi/linux/rmnet_data.h
> create mode 100644 net/rmnet_data/Kconfig
> create mode 100644 net/rmnet_data/Makefile
> create mode 100644 net/rmnet_data/rmnet_data_config.c
> create mode 100644 net/rmnet_data/rmnet_data_config.h
> create mode 100644 net/rmnet_data/rmnet_data_handlers.c
> create mode 100644 net/rmnet_data/rmnet_data_handlers.h
> create mode 100644 net/rmnet_data/rmnet_data_main.c
> create mode 100644 net/rmnet_data/rmnet_data_private.h
> create mode 100644 net/rmnet_data/rmnet_data_stats.c
> create mode 100644 net/rmnet_data/rmnet_data_stats.h
> create mode 100644 net/rmnet_data/rmnet_data_trace.h
> create mode 100644 net/rmnet_data/rmnet_data_vnd.c
> create mode 100644 net/rmnet_data/rmnet_data_vnd.h
> create mode 100644 net/rmnet_data/rmnet_map.h
> create mode 100644 net/rmnet_data/rmnet_map_command.c
> create mode 100644 net/rmnet_data/rmnet_map_data.c
>
>diff --git a/Documentation/networking/rmnet_data.txt 
>b/Documentation/networking/rmnet_data.txt
>new file mode 100644
>index 000..ff6cce8
>--- /dev/null
>+++ b/Documentation/networking/rmnet_data.txt
>@@ -0,0 +1,82 @@
>+1. Introduction
>+
>+rmnet_data driver is used for supporting the Multiplexing and aggregation
>+Protocol (MAP). This protocol is used by all recent chipsets using Qualcomm
>+Technologies, Inc. modems.
>+
>+This driver can be used to register onto any physical network device in
>+IP mode. Physical transports include USB, HSIC, PCIe and IP accelerator.
>+
>+Multiplexing allows for creation of logical netdevices (rmnet_data devices) to
>+handle multiple private data networks (PDN) like a default internet, 
>tethering,
>+multimedia messaging service (MMS) or IP media subsystem (IMS). Hardware sends
>+packets with MAP headers to rmnet_data. Based on the multiplexer id, 
>rmnet_data
>+routes to the appropriate PDN after removing the MAP header.
>+
>+Aggregation is required to achieve high data rates. This involves hardware
>+sending aggregated bunch of MAP frames. rmnet_data driver will de-aggregate
>+these MAP frames and send them to appropriate PDN's.
>+
>+2. Packet format
>+
>+a. MAP packet (data / control)
>+
>+MAP header has the same endianness of the IP packet.
>+
>+Packet format -
>+
>+Bit 0 1   2-7  8 - 15   16 - 31
>+Function   Command / Data   Reserved Pad   Multiplexer IDPayload 
>length
>+Bit32 - x
>+Function Raw  Bytes
>+
>+Command (1)/ Data (0) bit value is to indicate if the packet is a MAP command
>+or data packet. Control packet is used for transport level flow control. Data
>+packets are standard IP packets.
>+
>+Reserved bits are usually zeroed out and to be ignored by receiver.
>+
>+Padding is number of bytes to be added for 4 byte alignment if required by
>+hardware.
>+
>+Multiplexer ID is to indicate the PDN on which data has to be sent.
>+
>+Payload length includes the padding length but does not include MAP header
>+length.
>+

[PATCH net-next 1/1 v2] net: rmnet_data: Initial implementation

2017-03-13 Thread Subash Abhinov Kasiviswanathan 
RmNet Data driver provides a transport agnostic MAP (multiplexing and
aggregation protocol) support in embedded and bridge modes. Module
provides virtual network devices which can be attached to any IP-mode
physical device. This will be used to provide all MAP functionality
on future hardware in a single consistent location.

Signed-off-by: Subash Abhinov Kasiviswanathan 
---
 Documentation/networking/rmnet_data.txt |   82 +++
 include/uapi/linux/Kbuild   |1 +
 include/uapi/linux/if_arp.h |1 +
 include/uapi/linux/if_ether.h   |4 +-
 include/uapi/linux/rmnet_data.h |  214 ++
 net/Kconfig |1 +
 net/Makefile|1 +
 net/rmnet_data/Kconfig  |   21 +
 net/rmnet_data/Makefile |   14 +
 net/rmnet_data/rmnet_data_config.c  | 1168 +++
 net/rmnet_data/rmnet_data_config.h  |  107 +++
 net/rmnet_data/rmnet_data_handlers.c|  556 +++
 net/rmnet_data/rmnet_data_handlers.h|   24 +
 net/rmnet_data/rmnet_data_main.c|   60 ++
 net/rmnet_data/rmnet_data_private.h |   76 ++
 net/rmnet_data/rmnet_data_stats.c   |   86 +++
 net/rmnet_data/rmnet_data_stats.h   |   61 ++
 net/rmnet_data/rmnet_data_trace.h   |  198 ++
 net/rmnet_data/rmnet_data_vnd.c |  460 
 net/rmnet_data/rmnet_data_vnd.h |   34 +
 net/rmnet_data/rmnet_map.h  |  100 +++
 net/rmnet_data/rmnet_map_command.c  |  180 +
 net/rmnet_data/rmnet_map_data.c |  148 
 23 files changed, 3596 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/networking/rmnet_data.txt
 create mode 100644 include/uapi/linux/rmnet_data.h
 create mode 100644 net/rmnet_data/Kconfig
 create mode 100644 net/rmnet_data/Makefile
 create mode 100644 net/rmnet_data/rmnet_data_config.c
 create mode 100644 net/rmnet_data/rmnet_data_config.h
 create mode 100644 net/rmnet_data/rmnet_data_handlers.c
 create mode 100644 net/rmnet_data/rmnet_data_handlers.h
 create mode 100644 net/rmnet_data/rmnet_data_main.c
 create mode 100644 net/rmnet_data/rmnet_data_private.h
 create mode 100644 net/rmnet_data/rmnet_data_stats.c
 create mode 100644 net/rmnet_data/rmnet_data_stats.h
 create mode 100644 net/rmnet_data/rmnet_data_trace.h
 create mode 100644 net/rmnet_data/rmnet_data_vnd.c
 create mode 100644 net/rmnet_data/rmnet_data_vnd.h
 create mode 100644 net/rmnet_data/rmnet_map.h
 create mode 100644 net/rmnet_data/rmnet_map_command.c
 create mode 100644 net/rmnet_data/rmnet_map_data.c

diff --git a/Documentation/networking/rmnet_data.txt 
b/Documentation/networking/rmnet_data.txt
new file mode 100644
index 000..ff6cce8
--- /dev/null
+++ b/Documentation/networking/rmnet_data.txt
@@ -0,0 +1,82 @@
+1. Introduction
+
+rmnet_data driver is used for supporting the Multiplexing and aggregation
+Protocol (MAP). This protocol is used by all recent chipsets using Qualcomm
+Technologies, Inc. modems.
+
+This driver can be used to register onto any physical network device in
+IP mode. Physical transports include USB, HSIC, PCIe and IP accelerator.
+
+Multiplexing allows for creation of logical netdevices (rmnet_data devices) to
+handle multiple private data networks (PDN) like a default internet, tethering,
+multimedia messaging service (MMS) or IP media subsystem (IMS). Hardware sends
+packets with MAP headers to rmnet_data. Based on the multiplexer id, rmnet_data
+routes to the appropriate PDN after removing the MAP header.
+
+Aggregation is required to achieve high data rates. This involves hardware
+sending aggregated bunch of MAP frames. rmnet_data driver will de-aggregate
+these MAP frames and send them to appropriate PDN's.
+
+2. Packet format
+
+a. MAP packet (data / control)
+
+MAP header has the same endianness of the IP packet.
+
+Packet format -
+
+Bit 0 1   2-7  8 - 15   16 - 31
+Function   Command / Data   Reserved Pad   Multiplexer IDPayload length
+Bit32 - x
+Function Raw  Bytes
+
+Command (1)/ Data (0) bit value is to indicate if the packet is a MAP command
+or data packet. Control packet is used for transport level flow control. Data
+packets are standard IP packets.
+
+Reserved bits are usually zeroed out and to be ignored by receiver.
+
+Padding is number of bytes to be added for 4 byte alignment if required by
+hardware.
+
+Multiplexer ID is to indicate the PDN on which data has to be sent.
+
+Payload length includes the padding length but does not include MAP header
+length.
+
+b. MAP packet (command specific)
+
+Bit 0 1   2-7  8 - 15   16 - 31
+Function   Command Reserved Pad   Multiplexer IDPayload length
+Bit  32 - 3940 - 4546 - 47   48 - 63
+Function   Command nameReserved   Command Type   Reserved
+Bit  64 - 95