RE: [PATCH v3] mbuf: add ESP packet type

[Alexander Kozyrev <akozyrev@nvidia.com>]

> As per IPSEC ESP RFC 4303, for both tunnel mode or transport mode,
> next proto 50, so we cannot identify a packet is for tunnel mode or
> transport mode by just packet parsing.
> Am I missing something ?
You are absolutely correct, the only way to tell the difference is
to parse the next_proto field in the ESP header itself.
But this field is encrypted, according to RFC, and not really available for parsing. 

> Currently there is already a PTYPE `RTE_PTYPE_TUNNEL_ESP` being used
> by all drivers / ipsec-secgw to indicate ESP packet. So why is this
> needed ?
The idea was to add the possibility to distinguish packets in these two modes.
But you are right, it doesn't seem achievable without decrypting the packet first.

> There is also a documentation issue with `RTE_PTYPE_TUNNEL_ESP` where
> it indicates next-proto of 51 but it should have been 50.
> next-proto of 51 is for IPSEC AH.
Yes, documentation is incorrect there.

Thanks for bringing this up, Nithin, I think we can live with RTE_PTYPE_TUNNEL_ESP.