DPDK usage discussions
 help / color / mirror / Atom feed
* [dpdk-users] Understanding the Proper way of using ip fragmentation
@ 2018-11-05  3:06 Sungho Hong
  0 siblings, 0 replies; 3+ messages in thread
From: Sungho Hong @ 2018-11-05  3:06 UTC (permalink / raw)
  To: users

Hello DPDK experts,
I am having trouble applying ip fragmentation in multiple cores.
Really thankful if somebody can point out what I am doing wrong here.

*Purpose*
I am trying to apply ip fragmentation in multiple cores, and maximize the
throughput performance with messages that are bigger than MTU.

for each local & remote host (using 1 to 8 logical cores)
1 ~ 4 for transferring fragmented message
4 ~ 8 for receiving and assemble message

*Method of Throughput -testing *
Sending 4KB message from local and remote echos the message back to the
local.


*Problem *
If I try to allocate fragmentation table to each of the cores, I get a
segmentation error, and this happens no matter I shrink the size of the
fragmentation table.
The way I have tried to allocate the pools and frag-table are like this
below.

for each coreid, coreid < allocated cores; coreid++
     fragmentation_table[coreid] = rte_ip_frag_table_create(...);
     direct_pool[coreid] = rte_pktmbuf_pool_create(...);
     indirect_pool[coreid] rte_pktmbuf_pool_create(...);

So alternatively, I have allocated multiple fragmentation table for each
lcores but let the direct and indirect pools be shared together.

for each coreid, coreid < allocated cores; coreid++
     fragmentation_table[coreid] = rte_ip_frag_table_create(...);

direct_pool = rte_pktmbuf_pool_create(...);
indirect_pool = rte_pktmbuf_pool_create(...);

*Situation*
Now when I send messages using multiple cores from local to remote host,
the remote host only successfully receive the message when I send the
message adding a delay such as ( adding sleep(1); for each message send. )
I was able to receive the message from local to remote. But, cannot receive
any data when I try to send them without any delay.


Personally, I suspect that I should allocate direct pool and indirect pool
for each logical cores, and I think that is the main issue. Since I was
only able to successfully use the frag-table using only one logical core, I
suspect that I am not using the fragmentation table correctly in multiple
cores.


I really want to hear from the DPDK experts about this issue I am facing,
and will be really grateful for any advice on this...

^ permalink raw reply	[flat|nested] 3+ messages in thread
* [dpdk-users] Understanding the Proper way of using ip fragmentation
@ 2018-11-05  3:57 Sungho Hong
  0 siblings, 0 replies; 3+ messages in thread
From: Sungho Hong @ 2018-11-05  3:57 UTC (permalink / raw)
  To: users

Hello DPDK experts,
I am having trouble applying ip fragmentation in multiple cores.
*My ultimate questions is whether it is possible to have multiple ip
fragmentation table allocated with each different direct and indirect
pool. *
Really thankful if somebody can point out what I am doing wrong here or
provide me with some alternative solutions.

*Purpose*
I am trying to apply ip fragmentation in multiple cores, and maximize the
throughput performance with messages that are bigger than MTU.

for each local & remote host (using 1 to 8 logical cores)
1 ~ 4 for transferring fragmented message
4 ~ 8 for receiving and assemble message

*Method of Throughput -testing *
Sending 4KB message from local and remote echos the message back to the
local.


*Problem *
If I try to allocate fragmentation table to each of the cores, I get a
segmentation error, and this happens no matter I shrink the size of the
fragmentation table.
The way I have tried to allocate the pools and frag-table are like this
below.

for each coreid, coreid < allocated cores; coreid++
     fragmentation_table[coreid] = rte_ip_frag_table_create(...);
     direct_pool[coreid] = rte_pktmbuf_pool_create(...);
     indirect_pool[coreid] rte_pktmbuf_pool_create(...);

So alternatively, I have allocated multiple fragmentation table for each
lcores but let the direct and indirect pools be shared together.

for each coreid, coreid < allocated cores; coreid++
     fragmentation_table[coreid] = rte_ip_frag_table_create(...);

direct_pool = rte_pktmbuf_pool_create(...);
indirect_pool = rte_pktmbuf_pool_create(...);

*Situation*
Now when I send messages using multiple cores from local to remote host,
the remote host only successfully receive the message when I send the
message adding a delay such as ( adding sleep(1); for each message send. )
I was able to receive the message from local to remote. But, cannot receive
any data when I try to send them without any delay.


Personally, I suspect that I should allocate direct pool and indirect pool
for each logical cores, and I think that is the main issue. Since I was
only able to successfully use the frag-table using only one logical core, I
suspect that I am not using the fragmentation table correctly in multiple
cores.


I really want to hear from the DPDK experts about this issue I am facing,
and will be really grateful for any advice on this...

^ permalink raw reply	[flat|nested] 3+ messages in thread
* [dpdk-users] Understanding the Proper way of using ip fragmentation
@ 2018-11-05 21:54 Sungho Hong
  0 siblings, 0 replies; 3+ messages in thread
From: Sungho Hong @ 2018-11-05 21:54 UTC (permalink / raw)
  To: users

Hello DPDK experts,
I am having trouble applying ip fragmentation in multiple cores.
*My ultimate questions is whether it is possible to have multiple ip
fragmentation table allocated with each different direct and indirect
pool. *
Really thankful if somebody can point out what I am doing wrong here or
provide me with some alternative solutions.

*Purpose*
I am trying to apply ip fragmentation in multiple cores, and maximize the
throughput performance with messages that are bigger than MTU.

for each local & remote host (using 1 to 8 logical cores)
1 ~ 4 for transferring fragmented message
4 ~ 8 for receiving and assemble message

*Method of Throughput -testing *
Sending 4KB message from local and remote echos the message back to the
local.


*Problem *
If I try to allocate fragmentation table to each of the cores, I get a
segmentation error, and this happens no matter I shrink the size of the
fragmentation table.
The way I have tried to allocate the pools and frag-table are like this
below.

for each coreid, coreid < allocated cores; coreid++
     fragmentation_table[coreid] = rte_ip_frag_table_create(...);
     direct_pool[coreid] = rte_pktmbuf_pool_create(...);
     indirect_pool[coreid] rte_pktmbuf_pool_create(...);

So alternatively, I have allocated multiple fragmentation table for each
lcores but let the direct and indirect pools be shared together.

for each coreid, coreid < allocated cores; coreid++
     fragmentation_table[coreid] = rte_ip_frag_table_create(...);

direct_pool = rte_pktmbuf_pool_create(...);
indirect_pool = rte_pktmbuf_pool_create(...);

*Situation*
Now when I send messages using multiple cores from local to remote host,
the remote host only successfully receive the message when I send the
message adding a delay such as ( adding sleep(1); for each message send. )
I was able to receive the message from local to remote. But, cannot receive
any data when I try to send them without any delay.


Personally, I suspect that I should allocate direct pool and indirect pool
for each logical cores, and I think that is the main issue. Since I was
only able to successfully use the frag-table using only one logical core, I
suspect that I am not using the fragmentation table correctly in multiple
cores.


I really want to hear from the DPDK experts about this issue I am facing,
and will be really grateful for any advice on this...

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2018-11-05 21:54 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-11-05  3:06 [dpdk-users] Understanding the Proper way of using ip fragmentation Sungho Hong
2018-11-05  3:57 Sungho Hong
2018-11-05 21:54 Sungho Hong

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).