[dpdk-dev] [PATCH v2] fm10k: set packet type for multi-segment packets
When building a chain of mbufs for a multi-segment packet, the
packet_type field resides at the end of the chain. It should be
copied forward to the head of the list.
Also, uses RTE_LIBRTE_FM10K_RX_OLFLAGS_ENABLE to guard packet-type
computation. The mbuf fields are not copied when this define is not set.
Fixes: fe65e1e1ce61 ("fm10k: add vector scatter Rx")
Signed-off-by: Michael Frasca
---
v2:
- Only copy hash, ol_flags, and packet_type to 'start' when
RTE_LIBRTE_FM10K_RX_OLFLAGS_ENABLE is defined.
drivers/net/fm10k/fm10k_rxtx_vec.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/fm10k/fm10k_rxtx_vec.c
b/drivers/net/fm10k/fm10k_rxtx_vec.c
index f8efe8f..03e4a5c 100644
--- a/drivers/net/fm10k/fm10k_rxtx_vec.c
+++ b/drivers/net/fm10k/fm10k_rxtx_vec.c
@@ -606,8 +606,11 @@ fm10k_reassemble_packets(struct fm10k_rx_queue *rxq,
if (!split_flags[buf_idx]) {
/* it's the last packet of the set */
+#ifdef RTE_LIBRTE_FM10K_RX_OLFLAGS_ENABLE
start->hash = end->hash;
start->ol_flags = end->ol_flags;
+ start->packet_type = end->packet_type;
+#endif
pkts[pkt_idx++] = start;
start = end = NULL;
}
--
2.5.0
[dpdk-dev] [PATCH] fm10k: set packet type for multi-segment packets
Hi Mark,
Not a problem. I?ll post a v2 change with check for
RTE_LIBRTE_FM10K_RX_OLFLAGS_ENABLE.
Thanks,
Michael
> On Apr 18, 2016, at 4:40 AM, Chen, Jing D wrote:
>
> Hi, Frasca,
>
>> -Original Message-
>> From: Michael Frasca [mailto:michael.frasca at oracle.com]
>> Sent: Friday, April 15, 2016 3:32 AM
>> To: Chen, Jing D
>> Cc: dev at dpdk.org; Michael Frasca
>> Subject: [PATCH] fm10k: set packet type for multi-segment packets
>>
>> When building a chain of mbufs for a multi-segment packet, the
>> packet_type field resides at the end of the chain. It should be
>> copied forward to the head of the list.
>>
>> Fixes: fe65e1e1ce61 ("fm10k: add vector scatter Rx")
>>
>> Signed-off-by: Michael Frasca
>> ---
>> drivers/net/fm10k/fm10k_rxtx_vec.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/net/fm10k/fm10k_rxtx_vec.c
>> b/drivers/net/fm10k/fm10k_rxtx_vec.c
>> index f8efe8f..66f126f 100644
>> --- a/drivers/net/fm10k/fm10k_rxtx_vec.c
>> +++ b/drivers/net/fm10k/fm10k_rxtx_vec.c
>> @@ -608,6 +608,7 @@ fm10k_reassemble_packets(struct fm10k_rx_queue
>> *rxq,
>> /* it's the last packet of the set */
>> start->hash = end->hash;
>> start->ol_flags = end->ol_flags;
>> +start->packet_type = end->packet_type;
>> pkts[pkt_idx++] = start;
>> start = end = NULL;
>> }
>> --
>> 2.5.0
> Good catch. Just one comment. We'll parse packet type until
> "RTE_LIBRTE_FM10K_RX_OLFLAGS_ENABLE" is applied. Can we add this macro for
> your change? Same to "hash" and "olf_flags".
>
> Best Regards,
> Mark
[dpdk-dev] [PATCH] fm10k: set packet type for multi-segment packets
When building a chain of mbufs for a multi-segment packet, the
packet_type field resides at the end of the chain. It should be
copied forward to the head of the list.
Fixes: fe65e1e1ce61 ("fm10k: add vector scatter Rx")
Signed-off-by: Michael Frasca
---
drivers/net/fm10k/fm10k_rxtx_vec.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/fm10k/fm10k_rxtx_vec.c
b/drivers/net/fm10k/fm10k_rxtx_vec.c
index f8efe8f..66f126f 100644
--- a/drivers/net/fm10k/fm10k_rxtx_vec.c
+++ b/drivers/net/fm10k/fm10k_rxtx_vec.c
@@ -608,6 +608,7 @@ fm10k_reassemble_packets(struct fm10k_rx_queue *rxq,
/* it's the last packet of the set */
start->hash = end->hash;
start->ol_flags = end->ol_flags;
+ start->packet_type = end->packet_type;
pkts[pkt_idx++] = start;
start = end = NULL;
}
--
2.5.0
[dpdk-dev] [PATCH] fm10k: conditionally disable RSS during device initialization
Jing, Thanks for your assistance. The experiment that you have built should allow you to observe the bug. In [5], I would expect that queue 0 receives roughly 1/4 of the packets that you sending, assuming the input packets have varied IP addresses. Can you measure what % of packets are actually being received in this single queue setup (after first running a 4-queue setup)? When trying to running with only one RX queue, the fm10k retains the same RSS hash function and redirection table that was configured from a previous run. As a result, some packets are still being directed to other receive queues. I have confirmed this by polling the queue specific stats, which I retrieved via rte_eth_xstats_get(). Looking at fm10k_dev_rss_configure(), one should see that there is no modification of fm10k registers when nb_rx_queues == 1. As far as I can tell, this is the reason that only a certain partition of packets are being receive in a single queue setup (after first running a multi-queue configuration). I am unable to access my development environment today, but if you need, I can later craft a patch to l3fwd that shows the measurement of packets received at each queue. Thanks, Mike > On Mar 24, 2016, at 2:40 AM, Chen, Jing D wrote: > > Hi, Frasca, > > > >> -Original Message- >> From: Michael Frasca [mailto:michael.frasca at oracle.com >> <mailto:michael.frasca at oracle.com>] >> Sent: Wednesday, March 23, 2016 9:43 PM >> To: Chen, Jing D >> Cc: dev at dpdk.org <mailto:dev at dpdk.org> >> Subject: Re: [PATCH] fm10k: conditionally disable RSS during device >> initialization >> >> Hi Jing, >> >> I ran into this issue while trying to run experiments with different RSS >> configurations (no RSS being one cases). It is not clear to me that setting >> this >> register to zero is the best way to disable RSS. >> >> After digging further, I have a theory that I'm having this issues because >> I've >> only attached my DPDK application to SR-IOV ports. In >> fm10k_dev_dglort_map_configure(), I see that 'RSS Length' is set for the >> DGLORT >> decoder. However, it appears that this is only invoked for physical >> functions. >> >> Could this be my problem? Is it required that I bind to the physical function >> if I want to properly manipulate RSS? >> >> Thanks, >> Mike >> > I don't know exactly what problem you ran into. I think we needn't worry > about > those DGLORT setting when using VF device. > > I've followed steps to use SRIOV device with RSS enabled and disabled, both > are worked well from my side after applying your patch. Below is my setup. > > 1. PF with Linux driver "fm10k-next_0.19.3". > 2. DPDK with latest code from master branch, apply your patch. > 3. Use 1 VF device created by kernel driver. > 4. use l3fwd with " ./examples/l3fwd/build/l3fwd -c fc -n 4 -- -p 0x1 > --config="(0,0,2),(0,1,2),(0,2,3),(0,3,3)"" >with RSS enabled. After sending packets, I can see all 4 queues received > packets. > 5. use l3fwd with " ./examples/l3fwd/build/l3fwd -c fc -n 4 -- -p 0x1 > --config="(0,0,2)"" >with RSS disabled. After sending packets, I can see queue 0 received > packets. > > Can you explain what actual problem is? > We can talk offline.
[dpdk-dev] [PATCH] fm10k: conditionally disable RSS during device initialization
Hi Jing,
I ran into this issue while trying to run experiments with different RSS
configurations (no RSS being one cases). It is not clear to me that setting this
register to zero is the best way to disable RSS.
After digging further, I have a theory that I'm having this issues because I've
only attached my DPDK application to SR-IOV ports. In
fm10k_dev_dglort_map_configure(), I see that 'RSS Length' is set for the DGLORT
decoder. However, it appears that this is only invoked for physical functions.
Could this be my problem? Is it required that I bind to the physical function
if I want to properly manipulate RSS?
Thanks,
Mike
> On Mar 22, 2016, at 11:14 PM, Chen, Jing D wrote:
>
> Hi,
>
>> -Original Message-
>> From: Michael Frasca [mailto:michael.frasca at oracle.com]
>> Sent: Wednesday, March 23, 2016 12:58 AM
>> To: Chen, Jing D
>> Cc: dev at dpdk.org; Michael Frasca
>> Subject: [PATCH] fm10k: conditionally disable RSS during device
>> initialization
>>
>> If the provided configuration does not call for RSS, then RSS is
>> explicitly disabled. Without this change, the device continues to
>> operate under the previous RSS configuration.
>>
>> Fixes: 57033cdf8fdc ("fm10k: add PF RSS")
>>
>> Signed-off-by: Michael Frasca
> Acked-by : Jing Chen
>
[dpdk-dev] [PATCH] fm10k: conditionally disable RSS during device initialization
If the provided configuration does not call for RSS, then RSS is
explicitly disabled. Without this change, the device continues to
operate under the previous RSS configuration.
Fixes: 57033cdf8fdc ("fm10k: add PF RSS")
Signed-off-by: Michael Frasca
---
drivers/net/fm10k/fm10k_ethdev.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/fm10k/fm10k_ethdev.c b/drivers/net/fm10k/fm10k_ethdev.c
index 4b07a8b..4d5365a 100644
--- a/drivers/net/fm10k/fm10k_ethdev.c
+++ b/drivers/net/fm10k/fm10k_ethdev.c
@@ -531,8 +531,10 @@ fm10k_dev_rss_configure(struct rte_eth_dev *dev)
if (dev->data->nb_rx_queues == 1 ||
dev_conf->rxmode.mq_mode != ETH_MQ_RX_RSS ||
- dev_conf->rx_adv_conf.rss_conf.rss_hf == 0)
+ dev_conf->rx_adv_conf.rss_conf.rss_hf == 0) {
+ FM10K_WRITE_REG(hw, FM10K_MRQC(0), 0);
return;
+ }
/* random key is rss_intel_key (default) or user provided (rss_key) */
if (dev_conf->rx_adv_conf.rss_conf.rss_key == NULL)
--
2.5.0
