[dpdk-dev] [PATCH v5 3/3] mbuf:replace the inner_l2_len and the inner_l3_len fields

Olivier MATZ olivier.matz at 6wind.com
Wed Dec 3 12:45:21 CET 2014


Hi Jijiang,

On 12/02/2014 04:06 PM, Jijiang Liu wrote:
> Replace the inner_l2_len and the inner_l3_len field with the outer_l2_len and outer_l3_len field, and rework csum forward engine and i40e PMD due to  these changes.
>
> Signed-off-by: Jijiang Liu <jijiang.liu at intel.com>
> ---
>   app/test-pmd/csumonly.c         |   58 +++++++++++++++++++++------------------
>   lib/librte_mbuf/rte_mbuf.h      |    4 +-
>   lib/librte_pmd_i40e/i40e_rxtx.c |   38 +++++++++++++------------
>   3 files changed, 53 insertions(+), 47 deletions(-)
>

One more thing about the arguments of testpmd, thay may be changed
a bit to make it clearer. We may also remove the distinction between
udp/tcp/sctp and just have l4 instead.

We don't need to add a tunnel-type argument in the testpmd
command line, because the application is already able to parse
the packet and can set the proper tunnel flag by itself.

This is the current description of the csumonly forward engine:

  * Receive a burst of packets, and for each packet:
  *  - parse packet, and try to recognize a supported packet type (1)
  *  - if it's not a supported packet type, don't touch the packet, else:
  *  - modify the IPs in inner headers and in outer headers if any
  *  - reprocess the checksum of all supported layers. This is done in SW
  *    or HW, depending on testpmd command line configuration
  *  - if TSO is enabled in testpmd command line, also flag the mbuf for
  *    TCP segmentation offload (this implies HW TCP checksum)
  * Then transmit packets on the output port.
  *
  * (1) Supported packets are:
  *   Ether / (vlan) / IP|IP6 / UDP|TCP|SCTP .
  *   Ether / (vlan) / outer IP|IP6 / outer UDP / VxLAN / Ether / IP|IP6
  *            / UDP|TCP|SCTP
  *
  * The testpmd command line for this forward engine sets the flags
  * TESTPMD_TX_OFFLOAD_* in ports[tx_port].tx_ol_flags. They control
  * wether a checksum must be calculated in software or in hardware. The
  * IP, UDP, TCP and SCTP flags always concern the inner layer.  The
  * VxLAN flag concerns the outer IP and UDP layer (if packet is
  * recognized as a vxlan packet).


This would give:

   tx_cksum set (outer-ip|outer-l4|ip|l4) (hw|sw) (port_id)


A/ outer-ip=sw, outer-l4=sw, ip=sw, l4=sw

   Ether / IP / UDP
     IP, UDP checksum reprocessed in sw

   Ether / IP1 / UDP1 / VxLAN / Ether / IP2 / UDP2:
     IP1, UDP1, IP2, UDP2 checksums reprocessed in sw



B/ outer-ip=hw, outer-l4=hw, ip=sw, l4=sw

   Ether / IP / UDP
     IP, UDP checksum reprocessed in sw

   Ether / IP1 / UDP1 / VxLAN / Ether / IP2 / UDP2:
     IP1, UDP1 checksums reprocessed in hw (using l2_len, l3_len)
     IP2, UDP2 checksums reprocessed in sw



C/ outer-ip=hw, outer-l4=hw, ip=hw, l4=hw

   Ether / IP / UDP
     IP, UDP checksum reprocessed in hw (using l2_len, l3_len)

   Ether / IP1 / UDP1 / VxLAN / Ether / IP2 / UDP2:
     IP1 checksums reprocessed in hw (using outer_l2_len, outer_l3_len)
     UDP1 checksum must be 0 in packet (I think it's not supported by hw
        or driver today)
     IP2, UDP2 checksums reprocessed in hw (using l2_len, l3_len)



D/ outer-ip=sw, outer-l4=sw, ip=hw, l4=hw

   Ether / IP / UDP
     IP, UDP checksum reprocessed in hw (using l2_len and l3_len)

   Ether / IP1 / UDP1 / VxLAN / Ether / IP2 / UDP2:
     not supported, we are not able to calculate the outer
     checksum in sw as some inner fields will be filled by the hw


What is your opinion?

Regards,
Olivier



More information about the dev mailing list