* [dpdk-dev] Regarding changing RTE_RING_SZ_MASK to 0x7FFFFFFF
@ 2017-08-14 18:01 Venkatesh Nuthula
2017-09-06 15:07 ` Olivier MATZ
0 siblings, 1 reply; 2+ messages in thread
From: Venkatesh Nuthula @ 2017-08-14 18:01 UTC (permalink / raw)
To: users, dev
Hi all,
I am a newbie to DPDK and in one of the applications I am building , I am
trying to capture more than 150M packets and save them to file. I noticed
that with packet count > 134M, the check 'count > RTE_RING_SZ_MASK' fails
as RTE_RING_SZ_MASK is set to 0x0FFFFFFF. So I tried changing
RTE_RING_SZ_MASK to 0x7FFFFFFF and it took me past the check
'count > RTE_RING_SZ_MASK' and the DPDK booted successfully. No error
messages. But when I try to save the packets captured in memory pool into
the file, I notice that it fails(my application exits without any error
message) to write beyond a number of packets.
I noticed that this failure to write packets happens only when I change the
RTE_RING_SZ_MASK to 0x7FFFFFFF from original value 0x0FFFFFFF. I have below
questions to understand this further.
*1) Why is RTE_RING_SZ_MASK set to 0x0FFFFFFF. Why are the 4 bits left
unused? Is it because ring size shouldn't exceed 2 power 32?2) If yes to
above question, can anybody please explain why ring size can't exceed 2
power 32 as ssize_t can hold more than 2 power 32? *
*3) What should be the approach if we want to capture more than
200M(200,000,000) packets? *
Thanks in Advance
venky
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [dpdk-dev] Regarding changing RTE_RING_SZ_MASK to 0x7FFFFFFF
2017-08-14 18:01 [dpdk-dev] Regarding changing RTE_RING_SZ_MASK to 0x7FFFFFFF Venkatesh Nuthula
@ 2017-09-06 15:07 ` Olivier MATZ
0 siblings, 0 replies; 2+ messages in thread
From: Olivier MATZ @ 2017-09-06 15:07 UTC (permalink / raw)
To: Venkatesh Nuthula; +Cc: users, dev
Hi Venky,
Sorry for the late reply.
On Mon, Aug 14, 2017 at 11:01:38AM -0700, Venkatesh Nuthula wrote:
> Hi all,
>
> I am a newbie to DPDK and in one of the applications I am building , I am
> trying to capture more than 150M packets and save them to file. I noticed
> that with packet count > 134M, the check 'count > RTE_RING_SZ_MASK' fails
> as RTE_RING_SZ_MASK is set to 0x0FFFFFFF. So I tried changing
> RTE_RING_SZ_MASK to 0x7FFFFFFF and it took me past the check
> 'count > RTE_RING_SZ_MASK' and the DPDK booted successfully. No error
> messages. But when I try to save the packets captured in memory pool into
> the file, I notice that it fails(my application exits without any error
> message) to write beyond a number of packets.
>
> I noticed that this failure to write packets happens only when I change the
> RTE_RING_SZ_MASK to 0x7FFFFFFF from original value 0x0FFFFFFF. I have below
> questions to understand this further.
>
>
>
> *1) Why is RTE_RING_SZ_MASK set to 0x0FFFFFFF. Why are the 4 bits left
> unused? Is it because ring size shouldn't exceed 2 power 32?2) If yes to
> above question, can anybody please explain why ring size can't exceed 2
> power 32 as ssize_t can hold more than 2 power 32? *
I don't see any good reason today to limit the size of the ring to
0x0FFFFFFF. Looking in the history, this was probably done to keep
some room for flags. See 50d769054872 ("ring: add burst API").
The only flag used (RTE_RING_QUOT_EXCEED) has been removed recently
in commit 77dd3064270c ("ring: remove watermark support").
So I think there is no issue to change the max size to 0x7FFFFFFF.
I don't think it would be straightforward to increase it more,
since ring->size is an uint32_t.
I will submit a patch for this.
Thanks,
Olivier
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2017-09-06 15:07 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-08-14 18:01 [dpdk-dev] Regarding changing RTE_RING_SZ_MASK to 0x7FFFFFFF Venkatesh Nuthula
2017-09-06 15:07 ` Olivier MATZ
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).