DPDK patches and discussions
 help / color / mirror / Atom feed
From: Aws Ismail <aws.ismail@gmail.com>
To: "Dumitrescu, Cristian" <cristian.dumitrescu@intel.com>
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] Explanation of the QoS offset values used in the QoS scheduler example app.
Date: Mon, 16 Feb 2015 08:05:06 -0500	[thread overview]
Message-ID: <CAMHMu0OJY1aWZSnZZjMs7XXV=MqHnipmKwgsmpj-0OumOah4Jw@mail.gmail.com> (raw)
In-Reply-To: <3EB4FA525960D640B5BDFFD6A3D8912632315B1F@IRSMSX108.ger.corp.intel.com>

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@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@dpdk.org] On Behalf Of Aws Ismail
> Sent: Saturday, February 14, 2015 7:35 PM
> To: dev@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.
>
>

      reply	other threads:[~2015-02-16 13:05 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAMHMu0MwKozt2A2Gp_s2yHT=dt2cZBE6Np_2guAWGjKfaMLD_Q@mail.gmail.com>
2015-02-14 19:34 ` Aws Ismail
2015-02-16 11:34   ` Dumitrescu, Cristian
2015-02-16 13:05     ` Aws Ismail [this message]

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='CAMHMu0OJY1aWZSnZZjMs7XXV=MqHnipmKwgsmpj-0OumOah4Jw@mail.gmail.com' \
    --to=aws.ismail@gmail.com \
    --cc=cristian.dumitrescu@intel.com \
    --cc=dev@dpdk.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;
as well as URLs for NNTP newsgroup(s).