[v4,1/2] ethdev: add new ext hdr for gtp psc

Message ID 20210404074552.24190-2-rasland@nvidia.com (mailing list archive)
State Changes Requested, archived
Delegated to: Ferruh Yigit
Headers
Series fix gtp psc qfi support |

Checks

Context Check Description
ci/checkpatch success coding style OK

Commit Message

Raslan Darawsheh April 4, 2021, 7:45 a.m. UTC
  Define new rte header for gtp PDU session container
based on RFC 38415-g30

Signed-off-by: Raslan Darawsheh <rasland@nvidia.com>
---
 lib/librte_net/rte_gtp.h | 34 ++++++++++++++++++++++++++++++++++
 1 file changed, 34 insertions(+)
  

Comments

Olivier Matz April 8, 2021, 12:29 p.m. UTC | #1
Hi Raslan,

On Sun, Apr 04, 2021 at 10:45:51AM +0300, Raslan Darawsheh wrote:
> Define new rte header for gtp PDU session container
> based on RFC 38415-g30

Do you have a link to this RFC?

> Signed-off-by: Raslan Darawsheh <rasland@nvidia.com>
> ---
>  lib/librte_net/rte_gtp.h | 34 ++++++++++++++++++++++++++++++++++
>  1 file changed, 34 insertions(+)
> 
> diff --git a/lib/librte_net/rte_gtp.h b/lib/librte_net/rte_gtp.h
> index 6a6f9b238d..088b0b5a53 100644
> --- a/lib/librte_net/rte_gtp.h
> +++ b/lib/librte_net/rte_gtp.h
> @@ -61,6 +61,40 @@ struct rte_gtp_hdr_ext_word {
>  	uint8_t next_ext;     /**< Next Extension Header Type. */
>  }  __rte_packed;
>  
> +/**
> + * Optional extension for GTP with next_ext set to 0x85
> + * defined based on RFC 38415-g30.
> + */
> +__extension__
> +struct rte_gtp_psc_hdr {
> +	uint8_t ext_hdr_len; /**< PDU ext hdr len in multiples of 4 bytes */
> +	uint8_t type:4; /**< PDU type */
> +	uint8_t qmp:1; /**< Qos Monitoring Packet */
> +	union {
> +		struct {
> +			uint8_t snp:1; /**< Sequence number presence */
> +			uint8_t spare_dl1:2; /**< spare down link bits */
> +		};
> +		struct {
> +			uint8_t dl_delay_ind:1; /**< dl delay result presence */
> +			uint8_t ul_delay_ind:1; /**< ul delay result presence */
> +			uint8_t snp_ul1:1; /**< Sequence number presence ul */
> +		};
> +	};
> +	union {
> +		struct {
> +			uint8_t ppp:1; /**< Paging policy presence */
> +			uint8_t rqi:1; /**< Reflective Qos Indicator */
> +		};
> +		struct {
> +			uint8_t n_delay_ind:1; /**< N3/N9 delay result presence */
> +			uint8_t spare_ul2:1; /**< spare up link bits */
> +		};
> +	};
> +	uint8_t qfi:6; /**< Qos Flow Identifier */
> +	uint8_t data[0]; /**< data feilds */
> +} __rte_packed;

With this header, sizeof(rte_gtp_psc_hdr) = 5, is it really expected?

It would help to see the specification to have a better idea of how to
split, but a possible solution is to do something like this:

struct rte_gtp_psc_generic_hdr {
	uint8_t ext_hdr_len;
	uint8_t type:4
	uint8_t qmp:1;
	uint8_t pad:3;
};

struct rte_gtp_psc_<name1>_hdr {
	uint8_t ext_hdr_len;
	uint8_t type:4
	uint8_t qmp:1;
	uint8_t uint8_t snp:1;
	uint8_t spare_dl1:2;
	...
};

...

struct rte_gtp_psc_hdr {
	union {
		struct rte_gtp_psc_generic_hdr generic;
		struct rte_gtp_psc_<name1>_hdr <name1>;
		struct rte_gtp_psc_<name2>_hdr <name2>;
	};
};

Also, you need to take care about endianness.


Regards,
Olivier
  
Raslan Darawsheh April 8, 2021, 12:37 p.m. UTC | #2
Hi Olivier,

> -----Original Message-----
> From: Olivier Matz <olivier.matz@6wind.com>
> Sent: Thursday, April 8, 2021 3:30 PM
> To: Raslan Darawsheh <rasland@nvidia.com>
> Cc: dev@dpdk.org; ferruh.yigit@intel.com; Ori Kam <orika@nvidia.com>;
> andrew.rybchenko@oktetlabs.ru; ivan.malov@oktetlabs.ru;
> ying.a.wang@intel.com; Slava Ovsiienko <viacheslavo@nvidia.com>; Shiri
> Kuzin <shirik@nvidia.com>
> Subject: Re: [PATCH v4 1/2] ethdev: add new ext hdr for gtp psc
> 
> Hi Raslan,
> 
> On Sun, Apr 04, 2021 at 10:45:51AM +0300, Raslan Darawsheh wrote:
> > Define new rte header for gtp PDU session container
> > based on RFC 38415-g30
> 
> Do you have a link to this RFC?
Yes sure,
https://www.3gpp.org/ftp/Specs/archive/38_series/38.415/38415-g30.zip

> 
> > Signed-off-by: Raslan Darawsheh <rasland@nvidia.com>
> > ---
> >  lib/librte_net/rte_gtp.h | 34 ++++++++++++++++++++++++++++++++++
> >  1 file changed, 34 insertions(+)
> >
> > diff --git a/lib/librte_net/rte_gtp.h b/lib/librte_net/rte_gtp.h
> > index 6a6f9b238d..088b0b5a53 100644
> > --- a/lib/librte_net/rte_gtp.h
> > +++ b/lib/librte_net/rte_gtp.h
> > @@ -61,6 +61,40 @@ struct rte_gtp_hdr_ext_word {
> >  	uint8_t next_ext;     /**< Next Extension Header Type. */
> >  }  __rte_packed;
> >
> > +/**
> > + * Optional extension for GTP with next_ext set to 0x85
> > + * defined based on RFC 38415-g30.
> > + */
> > +__extension__
> > +struct rte_gtp_psc_hdr {
> > +	uint8_t ext_hdr_len; /**< PDU ext hdr len in multiples of 4 bytes */
> > +	uint8_t type:4; /**< PDU type */
> > +	uint8_t qmp:1; /**< Qos Monitoring Packet */
> > +	union {
> > +		struct {
> > +			uint8_t snp:1; /**< Sequence number presence */
> > +			uint8_t spare_dl1:2; /**< spare down link bits */
> > +		};
> > +		struct {
> > +			uint8_t dl_delay_ind:1; /**< dl delay result presence
> */
> > +			uint8_t ul_delay_ind:1; /**< ul delay result presence
> */
> > +			uint8_t snp_ul1:1; /**< Sequence number presence
> ul */
> > +		};
> > +	};
> > +	union {
> > +		struct {
> > +			uint8_t ppp:1; /**< Paging policy presence */
> > +			uint8_t rqi:1; /**< Reflective Qos Indicator */
> > +		};
> > +		struct {
> > +			uint8_t n_delay_ind:1; /**< N3/N9 delay result
> presence */
> > +			uint8_t spare_ul2:1; /**< spare up link bits */
> > +		};
> > +	};
> > +	uint8_t qfi:6; /**< Qos Flow Identifier */
> > +	uint8_t data[0]; /**< data feilds */
> > +} __rte_packed;
> 
> With this header, sizeof(rte_gtp_psc_hdr) = 5, is it really expected?
The data[0] is variable length data, I guess I should send another version to mention that in the comment maybe.
The header size according to the spec should be 4 octets aligned in general.
> 
> It would help to see the specification to have a better idea of how to
Sure, I've just posted the link above, please let me know of any suggestion that you have, and I'll be glad to do accordingly.

> split, but a possible solution is to do something like this:
> 
> struct rte_gtp_psc_generic_hdr {
> 	uint8_t ext_hdr_len;
> 	uint8_t type:4
> 	uint8_t qmp:1;
> 	uint8_t pad:3;
> };
> 
> struct rte_gtp_psc_<name1>_hdr {
> 	uint8_t ext_hdr_len;
> 	uint8_t type:4
> 	uint8_t qmp:1;
> 	uint8_t uint8_t snp:1;
> 	uint8_t spare_dl1:2;
> 	...
> };
> 
> ...
> 
> struct rte_gtp_psc_hdr {
> 	union {
> 		struct rte_gtp_psc_generic_hdr generic;
> 		struct rte_gtp_psc_<name1>_hdr <name1>;
> 		struct rte_gtp_psc_<name2>_hdr <name2>;
> 	};
> };
> 
> Also, you need to take care about endianness.
> 
> 
> Regards,
> Olivier
Kindest regards
Raslan Darawsheh
  
Ferruh Yigit April 8, 2021, 2:10 p.m. UTC | #3
On 4/8/2021 1:37 PM, Raslan Darawsheh wrote:
> Hi Olivier,
> 
>> -----Original Message-----
>> From: Olivier Matz <olivier.matz@6wind.com>
>> Sent: Thursday, April 8, 2021 3:30 PM
>> To: Raslan Darawsheh <rasland@nvidia.com>
>> Cc: dev@dpdk.org; ferruh.yigit@intel.com; Ori Kam <orika@nvidia.com>;
>> andrew.rybchenko@oktetlabs.ru; ivan.malov@oktetlabs.ru;
>> ying.a.wang@intel.com; Slava Ovsiienko <viacheslavo@nvidia.com>; Shiri
>> Kuzin <shirik@nvidia.com>
>> Subject: Re: [PATCH v4 1/2] ethdev: add new ext hdr for gtp psc
>>
>> Hi Raslan,
>>
>> On Sun, Apr 04, 2021 at 10:45:51AM +0300, Raslan Darawsheh wrote:
>>> Define new rte header for gtp PDU session container
>>> based on RFC 38415-g30
>>
>> Do you have a link to this RFC?
> Yes sure,
> https://www.3gpp.org/ftp/Specs/archive/38_series/38.415/38415-g30.zip
> 
>>
>>> Signed-off-by: Raslan Darawsheh <rasland@nvidia.com>
>>> ---
>>>   lib/librte_net/rte_gtp.h | 34 ++++++++++++++++++++++++++++++++++
>>>   1 file changed, 34 insertions(+)
>>>
>>> diff --git a/lib/librte_net/rte_gtp.h b/lib/librte_net/rte_gtp.h
>>> index 6a6f9b238d..088b0b5a53 100644
>>> --- a/lib/librte_net/rte_gtp.h
>>> +++ b/lib/librte_net/rte_gtp.h
>>> @@ -61,6 +61,40 @@ struct rte_gtp_hdr_ext_word {
>>>   	uint8_t next_ext;     /**< Next Extension Header Type. */
>>>   }  __rte_packed;
>>>
>>> +/**
>>> + * Optional extension for GTP with next_ext set to 0x85
>>> + * defined based on RFC 38415-g30.
>>> + */
>>> +__extension__
>>> +struct rte_gtp_psc_hdr {
>>> +	uint8_t ext_hdr_len; /**< PDU ext hdr len in multiples of 4 bytes */
>>> +	uint8_t type:4; /**< PDU type */
>>> +	uint8_t qmp:1; /**< Qos Monitoring Packet */
>>> +	union {
>>> +		struct {
>>> +			uint8_t snp:1; /**< Sequence number presence */
>>> +			uint8_t spare_dl1:2; /**< spare down link bits */
>>> +		};
>>> +		struct {
>>> +			uint8_t dl_delay_ind:1; /**< dl delay result presence
>> */
>>> +			uint8_t ul_delay_ind:1; /**< ul delay result presence
>> */
>>> +			uint8_t snp_ul1:1; /**< Sequence number presence
>> ul */
>>> +		};
>>> +	};
>>> +	union {
>>> +		struct {
>>> +			uint8_t ppp:1; /**< Paging policy presence */
>>> +			uint8_t rqi:1; /**< Reflective Qos Indicator */
>>> +		};
>>> +		struct {
>>> +			uint8_t n_delay_ind:1; /**< N3/N9 delay result
>> presence */
>>> +			uint8_t spare_ul2:1; /**< spare up link bits */
>>> +		};
>>> +	};
>>> +	uint8_t qfi:6; /**< Qos Flow Identifier */
>>> +	uint8_t data[0]; /**< data feilds */
>>> +} __rte_packed;
>>
>> With this header, sizeof(rte_gtp_psc_hdr) = 5, is it really expected?
> The data[0] is variable length data, I guess I should send another version to mention that in the comment maybe.
> The header size according to the spec should be 4 octets aligned in general.

The struct is 5 btyes, this is not related to data[0], please check the pahole 
output:
http://inbox.dpdk.org/dev/536631b9-c634-ddac-c154-91978ffc29a5@intel.com/

>>
>> It would help to see the specification to have a better idea of how to
> Sure, I've just posted the link above, please let me know of any suggestion that you have, and I'll be glad to do accordingly.
> 
>> split, but a possible solution is to do something like this:
>>
>> struct rte_gtp_psc_generic_hdr {
>> 	uint8_t ext_hdr_len;
>> 	uint8_t type:4
>> 	uint8_t qmp:1;
>> 	uint8_t pad:3;
>> };
>>
>> struct rte_gtp_psc_<name1>_hdr {
>> 	uint8_t ext_hdr_len;
>> 	uint8_t type:4
>> 	uint8_t qmp:1;
>> 	uint8_t uint8_t snp:1;
>> 	uint8_t spare_dl1:2;
>> 	...
>> };
>>
>> ...
>>
>> struct rte_gtp_psc_hdr {
>> 	union {
>> 		struct rte_gtp_psc_generic_hdr generic;
>> 		struct rte_gtp_psc_<name1>_hdr <name1>;
>> 		struct rte_gtp_psc_<name2>_hdr <name2>;
>> 	};
>> };
>>
>> Also, you need to take care about endianness.
>>
>>
>> Regards,
>> Olivier
> Kindest regards
> Raslan Darawsheh
>
  
Olivier Matz April 8, 2021, 2:10 p.m. UTC | #4
On Thu, Apr 08, 2021 at 12:37:27PM +0000, Raslan Darawsheh wrote:
> Hi Olivier,
> 
> > -----Original Message-----
> > From: Olivier Matz <olivier.matz@6wind.com>
> > Sent: Thursday, April 8, 2021 3:30 PM
> > To: Raslan Darawsheh <rasland@nvidia.com>
> > Cc: dev@dpdk.org; ferruh.yigit@intel.com; Ori Kam <orika@nvidia.com>;
> > andrew.rybchenko@oktetlabs.ru; ivan.malov@oktetlabs.ru;
> > ying.a.wang@intel.com; Slava Ovsiienko <viacheslavo@nvidia.com>; Shiri
> > Kuzin <shirik@nvidia.com>
> > Subject: Re: [PATCH v4 1/2] ethdev: add new ext hdr for gtp psc
> > 
> > Hi Raslan,
> > 
> > On Sun, Apr 04, 2021 at 10:45:51AM +0300, Raslan Darawsheh wrote:
> > > Define new rte header for gtp PDU session container
> > > based on RFC 38415-g30
> > 
> > Do you have a link to this RFC?
> Yes sure,
> https://www.3gpp.org/ftp/Specs/archive/38_series/38.415/38415-g30.zip
> 
> > 
> > > Signed-off-by: Raslan Darawsheh <rasland@nvidia.com>
> > > ---
> > >  lib/librte_net/rte_gtp.h | 34 ++++++++++++++++++++++++++++++++++
> > >  1 file changed, 34 insertions(+)
> > >
> > > diff --git a/lib/librte_net/rte_gtp.h b/lib/librte_net/rte_gtp.h
> > > index 6a6f9b238d..088b0b5a53 100644
> > > --- a/lib/librte_net/rte_gtp.h
> > > +++ b/lib/librte_net/rte_gtp.h
> > > @@ -61,6 +61,40 @@ struct rte_gtp_hdr_ext_word {
> > >  	uint8_t next_ext;     /**< Next Extension Header Type. */
> > >  }  __rte_packed;
> > >
> > > +/**
> > > + * Optional extension for GTP with next_ext set to 0x85
> > > + * defined based on RFC 38415-g30.
> > > + */
> > > +__extension__
> > > +struct rte_gtp_psc_hdr {
> > > +	uint8_t ext_hdr_len; /**< PDU ext hdr len in multiples of 4 bytes */
> > > +	uint8_t type:4; /**< PDU type */
> > > +	uint8_t qmp:1; /**< Qos Monitoring Packet */
> > > +	union {
> > > +		struct {
> > > +			uint8_t snp:1; /**< Sequence number presence */
> > > +			uint8_t spare_dl1:2; /**< spare down link bits */
> > > +		};
> > > +		struct {
> > > +			uint8_t dl_delay_ind:1; /**< dl delay result presence
> > */
> > > +			uint8_t ul_delay_ind:1; /**< ul delay result presence
> > */
> > > +			uint8_t snp_ul1:1; /**< Sequence number presence
> > ul */
> > > +		};
> > > +	};
> > > +	union {
> > > +		struct {
> > > +			uint8_t ppp:1; /**< Paging policy presence */
> > > +			uint8_t rqi:1; /**< Reflective Qos Indicator */
> > > +		};
> > > +		struct {
> > > +			uint8_t n_delay_ind:1; /**< N3/N9 delay result
> > presence */
> > > +			uint8_t spare_ul2:1; /**< spare up link bits */
> > > +		};
> > > +	};
> > > +	uint8_t qfi:6; /**< Qos Flow Identifier */
> > > +	uint8_t data[0]; /**< data feilds */
> > > +} __rte_packed;
> > 
> > With this header, sizeof(rte_gtp_psc_hdr) = 5, is it really expected?
> The data[0] is variable length data, I guess I should send another version to mention that in the comment maybe.
> The header size according to the spec should be 4 octets aligned in general.

What I wanted to highlight is that using union of structs containing
bitfields does not work as you expect: each union is at least 1 byte.
This results in a structure that does not match the expected header.

> > 
> > It would help to see the specification to have a better idea of how to
> Sure, I've just posted the link above, please let me know of any suggestion that you have, and I'll be glad to do accordingly.
> 
> > split, but a possible solution is to do something like this:
> > 
> > struct rte_gtp_psc_generic_hdr {
> > 	uint8_t ext_hdr_len;
> > 	uint8_t type:4
> > 	uint8_t qmp:1;
> > 	uint8_t pad:3;
> > };
> > 
> > struct rte_gtp_psc_<name1>_hdr {
> > 	uint8_t ext_hdr_len;
> > 	uint8_t type:4
> > 	uint8_t qmp:1;
> > 	uint8_t uint8_t snp:1;
> > 	uint8_t spare_dl1:2;
> > 	...
> > };
> > 
> > ...
> > 
> > struct rte_gtp_psc_hdr {
> > 	union {
> > 		struct rte_gtp_psc_generic_hdr generic;
> > 		struct rte_gtp_psc_<name1>_hdr <name1>;
> > 		struct rte_gtp_psc_<name2>_hdr <name2>;
> > 	};
> > };

From what I see in the documation, I think this approach should
work. From afar, I suggest:

struct rte_gtp_psc_generic_hdr {
#if big endian
	uint8_t type:4
	uint8_t qmp:1;
	uint8_t pad:3;
#else
	uint8_t pad:3;
	uint8_t qmp:1;
	uint8_t type:4
#endif
};

struct rte_gtp_psc_type0_hdr {
#if big endian
	uint8_t type:4
	uint8_t qmp:1;
	uint8_t snp:1;
	uint8_t spare:2;

	uint8_t ppp:1;
	...
#else
	uint8_t pad:3;
	uint8_t qmp:1;
	uint8_t type:4
	uint8_t spare:2;
	uint8_t snp:1;

	...
#endif
	uint8_t data[0]; /* for variable fields */
};

struct rte_gtp_psc_type1_hdr {
	... same for fixed fields of type1


	uint8_t data[0]; /* for variable fields */
};

I don't see in the spec where is the reference to ext_hdr_len.

Regards,
Olivier
  
Raslan Darawsheh April 13, 2021, 7:45 a.m. UTC | #5
Hi and sorry for late response, 


> -----Original Message-----
> From: Olivier Matz <olivier.matz@6wind.com>
> Sent: Thursday, April 8, 2021 5:11 PM
> To: Raslan Darawsheh <rasland@nvidia.com>
> Cc: dev@dpdk.org; ferruh.yigit@intel.com; Ori Kam <orika@nvidia.com>;
> andrew.rybchenko@oktetlabs.ru; ivan.malov@oktetlabs.ru;
> ying.a.wang@intel.com; Slava Ovsiienko <viacheslavo@nvidia.com>; Shiri
> Kuzin <shirik@nvidia.com>
> Subject: Re: [PATCH v4 1/2] ethdev: add new ext hdr for gtp psc
> 
> On Thu, Apr 08, 2021 at 12:37:27PM +0000, Raslan Darawsheh wrote:
> > Hi Olivier,
> >
> > > -----Original Message-----
> > > From: Olivier Matz <olivier.matz@6wind.com>
> > > Sent: Thursday, April 8, 2021 3:30 PM
> > > To: Raslan Darawsheh <rasland@nvidia.com>
> > > Cc: dev@dpdk.org; ferruh.yigit@intel.com; Ori Kam <orika@nvidia.com>;
> > > andrew.rybchenko@oktetlabs.ru; ivan.malov@oktetlabs.ru;
> > > ying.a.wang@intel.com; Slava Ovsiienko <viacheslavo@nvidia.com>; Shiri
> > > Kuzin <shirik@nvidia.com>
> > > Subject: Re: [PATCH v4 1/2] ethdev: add new ext hdr for gtp psc
> > >
> > > Hi Raslan,
> > >
> > > On Sun, Apr 04, 2021 at 10:45:51AM +0300, Raslan Darawsheh wrote:
> > > > Define new rte header for gtp PDU session container
> > > > based on RFC 38415-g30
> > >
> > > Do you have a link to this RFC?
> > Yes sure,
> >
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww
> w.3gpp.org%2Fftp%2FSpecs%2Farchive%2F38_series%2F38.415%2F38415-
> g30.zip&amp;data=04%7C01%7Crasland%40nvidia.com%7C5279dde172024bc
> d1f6b08d8fa981668%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C6
> 37534878435191995%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMD
> AiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=
> LuD7%2FvJgqJbZ78ncaM7UrpiLNPUt7zbPPfSMemyb2Y8%3D&amp;reserved
> =0
> >
> > >
> > > > Signed-off-by: Raslan Darawsheh <rasland@nvidia.com>
> > > > ---
> > > >  lib/librte_net/rte_gtp.h | 34
> ++++++++++++++++++++++++++++++++++
> > > >  1 file changed, 34 insertions(+)
> > > >
> > > > diff --git a/lib/librte_net/rte_gtp.h b/lib/librte_net/rte_gtp.h
> > > > index 6a6f9b238d..088b0b5a53 100644
> > > > --- a/lib/librte_net/rte_gtp.h
> > > > +++ b/lib/librte_net/rte_gtp.h
> > > > @@ -61,6 +61,40 @@ struct rte_gtp_hdr_ext_word {
> > > >  	uint8_t next_ext;     /**< Next Extension Header Type. */
> > > >  }  __rte_packed;
> > > >
> > > > +/**
> > > > + * Optional extension for GTP with next_ext set to 0x85
> > > > + * defined based on RFC 38415-g30.
> > > > + */
> > > > +__extension__
> > > > +struct rte_gtp_psc_hdr {
> > > > +	uint8_t ext_hdr_len; /**< PDU ext hdr len in multiples of 4 bytes */
> > > > +	uint8_t type:4; /**< PDU type */
> > > > +	uint8_t qmp:1; /**< Qos Monitoring Packet */
> > > > +	union {
> > > > +		struct {
> > > > +			uint8_t snp:1; /**< Sequence number presence */
> > > > +			uint8_t spare_dl1:2; /**< spare down link bits */
> > > > +		};
> > > > +		struct {
> > > > +			uint8_t dl_delay_ind:1; /**< dl delay result presence
> > > */
> > > > +			uint8_t ul_delay_ind:1; /**< ul delay result presence
> > > */
> > > > +			uint8_t snp_ul1:1; /**< Sequence number presence
> > > ul */
> > > > +		};
> > > > +	};
> > > > +	union {
> > > > +		struct {
> > > > +			uint8_t ppp:1; /**< Paging policy presence */
> > > > +			uint8_t rqi:1; /**< Reflective Qos Indicator */
> > > > +		};
> > > > +		struct {
> > > > +			uint8_t n_delay_ind:1; /**< N3/N9 delay result
> > > presence */
> > > > +			uint8_t spare_ul2:1; /**< spare up link bits */
> > > > +		};
> > > > +	};
> > > > +	uint8_t qfi:6; /**< Qos Flow Identifier */
> > > > +	uint8_t data[0]; /**< data feilds */
> > > > +} __rte_packed;
> > >
> > > With this header, sizeof(rte_gtp_psc_hdr) = 5, is it really expected?
> > The data[0] is variable length data, I guess I should send another version to
> mention that in the comment maybe.
> > The header size according to the spec should be 4 octets aligned in general.
> 
> What I wanted to highlight is that using union of structs containing
> bitfields does not work as you expect: each union is at least 1 byte.
> This results in a structure that does not match the expected header.
I see thanks for explaining.
> 
> > >
> > > It would help to see the specification to have a better idea of how to
> > Sure, I've just posted the link above, please let me know of any suggestion
> that you have, and I'll be glad to do accordingly.
> >
> > > split, but a possible solution is to do something like this:
> > >
> > > struct rte_gtp_psc_generic_hdr {
> > > 	uint8_t ext_hdr_len;
> > > 	uint8_t type:4
> > > 	uint8_t qmp:1;
> > > 	uint8_t pad:3;
> > > };
> > >
> > > struct rte_gtp_psc_<name1>_hdr {
> > > 	uint8_t ext_hdr_len;
> > > 	uint8_t type:4
> > > 	uint8_t qmp:1;
> > > 	uint8_t uint8_t snp:1;
> > > 	uint8_t spare_dl1:2;
> > > 	...
> > > };
> > >
> > > ...
> > >
> > > struct rte_gtp_psc_hdr {
> > > 	union {
> > > 		struct rte_gtp_psc_generic_hdr generic;
> > > 		struct rte_gtp_psc_<name1>_hdr <name1>;
> > > 		struct rte_gtp_psc_<name2>_hdr <name2>;
> > > 	};
> > > };
> 
> From what I see in the documation, I think this approach should
> work. From afar, I suggest:
> 
> struct rte_gtp_psc_generic_hdr {
> #if big endian
> 	uint8_t type:4
> 	uint8_t qmp:1;
> 	uint8_t pad:3;
> #else
> 	uint8_t pad:3;
> 	uint8_t qmp:1;
> 	uint8_t type:4
> #endif
> };
> 
> struct rte_gtp_psc_type0_hdr {
> #if big endian
> 	uint8_t type:4
> 	uint8_t qmp:1;
> 	uint8_t snp:1;
> 	uint8_t spare:2;
> 
> 	uint8_t ppp:1;
> 	...
> #else
> 	uint8_t pad:3;
> 	uint8_t qmp:1;
> 	uint8_t type:4
> 	uint8_t spare:2;
> 	uint8_t snp:1;
> 
> 	...
> #endif
> 	uint8_t data[0]; /* for variable fields */
> };
> 
> struct rte_gtp_psc_type1_hdr {
> 	... same for fixed fields of type1
> 
> 
> 	uint8_t data[0]; /* for variable fields */
> };
> 
Sure, will consider and do it this way in the next version.

> I don't see in the spec where is the reference to ext_hdr_len.
> 
The ext_hdr_len is part of the definition for all ext_hdrs see this link for more details:
https://en.wikipedia.org/wiki/GPRS_Tunnelling_Protocol
So, it's not mentioned in the doc.

> Regards,
> Olivier
  
Tyler Retzlaff April 29, 2021, 4:29 p.m. UTC | #6
On Thu, Apr 08, 2021 at 02:29:56PM +0200, Olivier Matz wrote:
> Hi Raslan,
> 
> > +/**
> > + * Optional extension for GTP with next_ext set to 0x85
> > + * defined based on RFC 38415-g30.
> > + */
> > +__extension__
> > +struct rte_gtp_psc_hdr {
> > +	uint8_t ext_hdr_len; /**< PDU ext hdr len in multiples of 4 bytes */
> > +	uint8_t type:4; /**< PDU type */
> > +	uint8_t qmp:1; /**< Qos Monitoring Packet */

would it be a lot ot ask to have the structure defined using standard C
instead of using compiler specific extensions?
  
Andrew Rybchenko June 8, 2021, 12:13 p.m. UTC | #7
On 4/29/21 7:29 PM, Tyler Retzlaff wrote:
> On Thu, Apr 08, 2021 at 02:29:56PM +0200, Olivier Matz wrote:
>> Hi Raslan,
>>
>>> +/**
>>> + * Optional extension for GTP with next_ext set to 0x85
>>> + * defined based on RFC 38415-g30.
>>> + */
>>> +__extension__
>>> +struct rte_gtp_psc_hdr {
>>> +	uint8_t ext_hdr_len; /**< PDU ext hdr len in multiples of 4 bytes */
>>> +	uint8_t type:4; /**< PDU type */
>>> +	uint8_t qmp:1; /**< Qos Monitoring Packet */
> 
> would it be a lot ot ask to have the structure defined using standard C
> instead of using compiler specific extensions?
> 

It is a valid request, but I'm afraid bit fields are used
in many-many core DPDK libraries. So, change of the approach
or at least direction for a new code should be discussed and
approved by techboard.
  

Patch

diff --git a/lib/librte_net/rte_gtp.h b/lib/librte_net/rte_gtp.h
index 6a6f9b238d..088b0b5a53 100644
--- a/lib/librte_net/rte_gtp.h
+++ b/lib/librte_net/rte_gtp.h
@@ -61,6 +61,40 @@  struct rte_gtp_hdr_ext_word {
 	uint8_t next_ext;     /**< Next Extension Header Type. */
 }  __rte_packed;
 
+/**
+ * Optional extension for GTP with next_ext set to 0x85
+ * defined based on RFC 38415-g30.
+ */
+__extension__
+struct rte_gtp_psc_hdr {
+	uint8_t ext_hdr_len; /**< PDU ext hdr len in multiples of 4 bytes */
+	uint8_t type:4; /**< PDU type */
+	uint8_t qmp:1; /**< Qos Monitoring Packet */
+	union {
+		struct {
+			uint8_t snp:1; /**< Sequence number presence */
+			uint8_t spare_dl1:2; /**< spare down link bits */
+		};
+		struct {
+			uint8_t dl_delay_ind:1; /**< dl delay result presence */
+			uint8_t ul_delay_ind:1; /**< ul delay result presence */
+			uint8_t snp_ul1:1; /**< Sequence number presence ul */
+		};
+	};
+	union {
+		struct {
+			uint8_t ppp:1; /**< Paging policy presence */
+			uint8_t rqi:1; /**< Reflective Qos Indicator */
+		};
+		struct {
+			uint8_t n_delay_ind:1; /**< N3/N9 delay result presence */
+			uint8_t spare_ul2:1; /**< spare up link bits */
+		};
+	};
+	uint8_t qfi:6; /**< Qos Flow Identifier */
+	uint8_t data[0]; /**< data feilds */
+} __rte_packed;
+
 /** GTP header length */
 #define RTE_ETHER_GTP_HLEN \
 	(sizeof(struct rte_udp_hdr) + sizeof(struct rte_gtp_hdr))