Hello Ferruh,
On Wednesday 28 June 2017 09:20 PM, Ferruh Yigit wrote:
> On 6/16/2017 6:41 AM, Shreyansh Jain wrote:
>> Signed-off-by: Hemant Agrawal <hemant.agra...@nxp.com>
>> Signed-off-by: Shreyansh Jain <shreyansh.j...@nxp.com>
>
> <...>
>
>> @@ -363,6 +439,18 @@ dpaa_eth_queue_tx(void *q, struct rte_mbuf **bufs,
>> uint16_t nb_bufs)
>> }
>> rte_pktmbuf_free(mbuf);
>> }
>> + if (mbuf->ol_flags &
>> DPAA_TX_CKSUM_OFFLOAD_MASK) {
>> + if (mbuf->data_off <
>> DEFAULT_TX_ICEOF +
>> + sizeof(struct
>> dpaa_eth_parse_results_t)) {
>> + PMD_DRV_LOG(DEBUG,
>> "Checksum offload Err: "
>> + "Not enough
>> Headroom "
>> + "space for
>> correct Checksum offload."
>> + "So Calculating
>> checksum in Software.");
>> + dpaa_checksum(mbuf);
>> + } else
>> +
>> dpaa_checksum_offload(mbuf, &fd_arr[loop],
>> + mbuf->buf_addr);
>> + }
>
> There is a tx_pkt_prepare() dev_ops.
> Does it make sense to move this calculations to that function?
I did have a look at this before sending the v2.
In case of DPAA driver, it is not possible to segregate the preparation phase
from transmission phase.
Further, there are still applications which don't call the prep function - in
those cases, the I/O wouldn't happen.
And, making an internal call to prep (on basis of some (!prep) checks), is
performance impact.
>
>> } else {
>> PMD_DRV_LOG(DEBUG, "Number of Segments
>> not supported");
>> /* Set frames_to_send & nb_bufs so that
>
> <...>
>
-
Shreyansh
