[dpdk-dev] Explanation of the QoS offset values used in the QoS scheduler example app.

[Aws Ismail]

Thanks Cristian and Ariel your reply and explanation.

It is clear to me now.

Cheers.

Aws\
On Feb 16, 2015 6:34 AM, "Dumitrescu, Cristian" <
cristian.dumitrescu at intel.com> wrote:

> Hi,
>
> These are byte offsets used for reading these packet fields, considering
> that packet bytes are stored in memory in network order, while the CPU is
> little endian, so byte swapping takes place on read.
>
> This is probably not the best way to write this code, and I agree this
> portion of the app code is a bit more cryptic than it should be. Using data
> structures to describe the header format for the input packet
> (Ethernet/SVLAN/CVLAN/IPv4) and using portable byte swapping macros is
> probably a better alternative.
>
> This being said, the code implementation, code comments and Sample App
> Guide description seem to be consistent and correct.
>
> Regards,
> Cristian
>
>
> -----Original Message-----
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Aws Ismail
> Sent: Saturday, February 14, 2015 7:35 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] Explanation of the QoS offset values used in the QoS
> scheduler example app.
>
> Hi everyone,
>
> I am looking at this portion of the code in the app_thread.c file of the
> QoS scheduler example application:
>
> /*
> * QoS parameters are encoded as follows:
> * Outer VLAN ID defines subport
> * Inner VLAN ID defines pipe
> * Destination IP 0.0.XXX.0 defines traffic class
> * Destination IP host (0.0.0.XXX) defines queue
> * Values below define offset to each field from start of frame
> */
> #define SUBPORT_OFFSET 7
> #define PIPE_OFFSET 9
> #define TC_OFFSET 20
> #define QUEUE_OFFSET 20
> #define COLOR_OFFSET 19
>
> static inline int get_pkt_sched(struct rte_mbuf *m, uint32_t *subport,
> uint32_t *pipe, uint32_t *traffic_class, uint32_t *queue, uint32_t *color)
> {
> uint16_t *pdata = rte_pktmbuf_mtod(m, uint16_t *);
>
> *subport = (rte_be_to_cpu_16(pdata[SUBPORT_OFFSET]) & 0x0FFF) &
> (port_params.n_subports_per_port - 1); /* Outer VLAN ID*/
>
> *pipe = (rte_be_to_cpu_16(pdata[PIPE_OFFSET]) & 0x0FFF) &
> (port_params.n_pipes_per_subport - 1); /* Inner VLAN ID */
>
> *traffic_class = (pdata[QUEUE_OFFSET] & 0x0F) &
> (RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE - 1); /* Destination IP */
>
> *queue = ((pdata[QUEUE_OFFSET] >> 8) & 0x0F) &
> (RTE_SCHED_QUEUES_PER_TRAFFIC_CLASS - 1) ; /* Destination IP */
>
> *color = pdata[COLOR_OFFSET] & 0x03; /* Destination IP */
>
> return 0;
> }
>
> The offset values do not make sense to me. According to the programmer
> guide, the queue selection is SVID/CVID/TC/QID based. And those offset seem
> off in this case. Is this because it is assuming that the packet is being
> altered before it gets to this stage ?
>
> Can anyone provide a better explanation or at least the reason behind
> choosing those offset values shown above.
>
> Thanks.
> --------------------------------------------------------------
> Intel Shannon Limited
> Registered in Ireland
> Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
> Registered Number: 308263
> Business address: Dromore House, East Park, Shannon, Co. Clare
>
> This e-mail and any attachments may contain confidential material for the
> sole use of the intended recipient(s). Any review or distribution by others
> is strictly prohibited. If you are not the intended recipient, please
> contact the sender and delete all copies.
>
>