| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <cb52178a-166b-3d8d-37bc-db229eb07d4e@ieee.org>
Date: Fri, 23 Apr 2021 07:32:03 -0500
From: Alex Elder <elder@...e.org>
To: Sharath Chandra Vurukala <sharathv@...eaurora.org>,
davem@...emloft.net, kuba@...nel.org, elder@...nel.org,
cpratapa@...eaurora.org, subashab@...eaurora.org,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next v4 1/3] docs: networking: Add documentation for
MAPv5
On 4/22/21 3:02 PM, Sharath Chandra Vurukala wrote:
> Adding documentation explaining the new MAPv4/v5 packet formats
> and the corresponding checksum offload headers.
>
> Signed-off-by: Sharath Chandra Vurukala <sharathv@...eaurora.org>
Thank you for updating this document, and in particular
for adding documentation for QMAPv4.
While I might suggest minor changes here or there to
wording, I think the document does a good enough job
of describing RMNet data structures.
My main interest right now is enabling inline checksum
offload functionality, so for now I'm content to just
acknowledge this patch.
Acked-by: Alex Elder <elder@...aro.org>
> ---
> .../device_drivers/cellular/qualcomm/rmnet.rst | 126 +++++++++++++++++++--
> 1 file changed, 114 insertions(+), 12 deletions(-)
>
> diff --git a/Documentation/networking/device_drivers/cellular/qualcomm/rmnet.rst b/Documentation/networking/device_drivers/cellular/qualcomm/rmnet.rst
> index 70643b5..4118384 100644
> --- a/Documentation/networking/device_drivers/cellular/qualcomm/rmnet.rst
> +++ b/Documentation/networking/device_drivers/cellular/qualcomm/rmnet.rst
> @@ -27,34 +27,136 @@ these MAP frames and send them to appropriate PDN's.
> 2. Packet format
> ================
>
> -a. MAP packet (data / control)
> +a. MAP packet v1 (data / control)
>
> -MAP header has the same endianness of the IP packet.
> +MAP header fields are in big endian format.
>
> Packet format::
>
> - Bit 0 1 2-7 8 - 15 16 - 31
> + Bit 0 1 2-7 8-15 16-31
> Function Command / Data Reserved Pad Multiplexer ID Payload length
> - Bit 32 - x
> - Function Raw Bytes
> +
> + Bit 32-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
> +or data packet. Command 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.
> +Reserved bits must be zero when sent and ignored when received.
>
> -Padding is number of bytes to be added for 4 byte alignment if required by
> -hardware.
> +Padding is the number of bytes to be appended to the payload to
> +ensure 4 byte alignment.
>
> 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)::
> +b. Map packet v4 (data / control)
> +
> +MAP header fields are in big endian format.
> +
> +Packet format::
> +
> + Bit 0 1 2-7 8-15 16-31
> + Function Command / Data Reserved Pad Multiplexer ID Payload length
> +
> + Bit 32-(x-33) (x-32)-x
> + Function Raw bytes Checksum offload header
> +
> +Command (1)/ Data (0) bit value is to indicate if the packet is a MAP command
> +or data packet. Command packet is used for transport level flow control. Data
> +packets are standard IP packets.
> +
> +Reserved bits must be zero when sent and ignored when received.
> +
> +Padding is the number of bytes to be appended to the payload to
> +ensure 4 byte alignment.
> +
> +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.
> +
> +Checksum offload header, has the information about the checksum processing done
> +by the hardware.Checksum offload header fields are in big endian format.
> +
> +Packet format::
> +
> + Bit 0-14 15 16-31
> + Function Reserved Valid Checksum start offset
> +
> + Bit 31-47 48-64
> + Function Checksum length Checksum value
> +
> +Reserved bits must be zero when sent and ignored when received.
> +
> +Valid bit indicates whether the partial checksum is calculated and is valid.
> +Set to 1, if its is valid. Set to 0 otherwise.
> +
> +Padding is the number of bytes to be appended to the payload to
> +ensure 4 byte alignment.
> +
> +Checksum start offset, Indicates the offset in bytes from the beginning of the
> +IP header, from which modem computed checksum.
> +
> +Checksum length is the Length in bytes starting from CKSUM_START_OFFSET,
> +over which checksum is computed.
> +
> +Checksum value, indicates the checksum computed.
> +
> +c. MAP packet v5 (data / control)
> +
> +MAP header fields are in big endian format.
> +
> +Packet format::
> +
> + Bit 0 1 2-7 8-15 16-31
> + Function Command / Data Next header Pad Multiplexer ID Payload length
> +
> + Bit 32-x
> + Function Raw bytes
> +
> +Command (1)/ Data (0) bit value is to indicate if the packet is a MAP command
> +or data packet. Command packet is used for transport level flow control. Data
> +packets are standard IP packets.
> +
> +Next header is used to indicate the presence of another header, currently is
> +limited to checksum header.
> +
> +Padding is the number of bytes to be appended to the payload to
> +ensure 4 byte alignment.
> +
> +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.
> +
> +d. Checksum offload header v5
> +
> +Checksum offload header fields are in big endian format.
> +
> + Bit 0 - 6 7 8-15 16-31
> + Function Header Type Next Header Checksum Valid Reserved
> +
> +Header Type is to indicate the type of header, this usually is set to CHECKSUM
> +
> +Header types
> += ==========================================
> +0 Reserved
> +1 Reserved
> +2 checksum header
> +
> +Checksum Valid is to indicate whether the header checksum is valid. Value of 1
> +implies that checksum is calculated on this packet and is valid, value of 0
> +indicates that the calculated packet checksum is invalid.
> +
> +Reserved bits must be zero when sent and ignored when received.
> +
> +e. MAP packet v1/v5 (command specific)::
>
> - Bit 0 1 2-7 8 - 15 16 - 31
> + Bit 0 1 2-7 8 - 15 16 - 31
> Function Command Reserved Pad Multiplexer ID Payload length
> Bit 32 - 39 40 - 45 46 - 47 48 - 63
> Function Command name Reserved Command Type Reserved
> @@ -74,7 +176,7 @@ Command types
> 3 is for error during processing of commands
> = ==========================================
>
> -c. Aggregation
> +f. Aggregation
>
> Aggregation is multiple MAP packets (can be data or command) delivered to
> rmnet in a single linear skb. rmnet will process the individual
>
Powered by blists - more mailing lists