mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Alex Elder <elder@ieee.org>
To: Sharath Chandra Vurukala <sharathv@codeaurora.org>,
	davem@davemloft.net, kuba@kernel.org, elder@kernel.org,
	cpratapa@codeaurora.org, subashab@codeaurora.org,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH net-next v4 1/3] docs: networking: Add documentation for MAPv5
Date: Fri, 23 Apr 2021 07:32:03 -0500	[thread overview]
Message-ID: <cb52178a-166b-3d8d-37bc-db229eb07d4e@ieee.org> (raw)
In-Reply-To: <1619121731-17782-2-git-send-email-sharathv@codeaurora.org>

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@codeaurora.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@linaro.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
> 


  reply	other threads:[~2021-04-23 12:32 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-22 20:02 [PATCH net-next v4 0/3] net: qualcomm: rmnet: Enable Mapv5 Sharath Chandra Vurukala
2021-04-22 20:02 ` [PATCH net-next v4 1/3] docs: networking: Add documentation for MAPv5 Sharath Chandra Vurukala
2021-04-23 12:32   ` Alex Elder [this message]
2021-04-22 20:02 ` [PATCH net-next v4 2/3] net: ethernet: rmnet: Support for ingress MAPv5 checksum offload Sharath Chandra Vurukala
2021-04-23 12:32   ` Alex Elder
2021-04-22 20:02 ` [PATCH net-next v4 3/3] net: ethernet: rmnet: Add support for MAPv5 egress packets Sharath Chandra Vurukala
2021-04-23 12:32   ` Alex Elder
2021-04-22 20:14 ` [PATCH net-next v4 0/3] net: qualcomm: rmnet: Enable Mapv5 Alex Elder
2021-04-22 23:14   ` subashab
2021-04-23  0:54     ` Alex Elder
2021-04-23 12:31 ` Alex Elder

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=cb52178a-166b-3d8d-37bc-db229eb07d4e@ieee.org \
    --to=elder@ieee.org \
    --cc=cpratapa@codeaurora.org \
    --cc=davem@davemloft.net \
    --cc=elder@kernel.org \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=sharathv@codeaurora.org \
    --cc=subashab@codeaurora.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®