Re: [dpdk-dev] [PATCH 3/4] crypto: add sgl support for sw PMDs
2016-12-02 18:07 GMT+01:00 Tomasz Kulasek <tomaszx.kula...@intel.com>:
> This patch introduces RTE_CRYPTODEV_FF_MBUF_SCATTER_GATHER feature flag
> informing that selected crypto device supports segmented mbufs natively
> and doesn't need to be coalesced before crypto operation.
>
> While using segmented buffers in crypto devices may have unpredictable
> results, for PMDs which doesn't support it natively, additional check is
> made for debug compilation.
>
[...]
> +#ifdef RTE_LIBRTE_PMD_AESNI_GCM_DEBUG
> + if (!rte_pktmbuf_is_contiguous(ops[i]->sym->m_src) ||
> + (ops[i]->sym->m_dst != NULL &&
> + !rte_pktmbuf_is_contiguous(
> + ops[i]->sym->m_dst))) {
> + ops[i]->status = RTE_CRYPTO_OP_STATUS_INVALID_ARGS;
> + GCM_LOG_ERR("PMD supports only contiguous mbufs, "
> + "op (%p) provides noncontiguous mbuf as "
> + "source/destination buffer.\n", ops[i]);
> + qp->qp_stats.enqueue_err_count++;
> + break;
> + }
> +#endif
[...]
Why are there so many copies of this code?
Best Regards,
Michał Mirosław
[dpdk-dev] [PATCH v4] drivers/net:new PMD using tun/tap host interface
2016-10-11 22:56 GMT+02:00 Wiles, Keith :
>> On Oct 11, 2016, at 6:30 AM, Micha? Miros?aw wrote:
>>
>> 2016-10-04 16:45 GMT+02:00, Keith Wiles :
>>> The rte_eth_tap.c PMD creates a device using TUN/TAP interfaces
>>> on the local host. The PMD allows for DPDK and the host to
>>> communicate using a raw device interface on the host and in
>>> the DPDK application. The device created is a Tap device with
>>> a L2 packet header.
>> [...]
>>> +static uint16_t
>>> +pmd_rx_burst(void *queue, struct rte_mbuf **bufs, uint16_t nb_pkts)
>>> +{
>>> +int len, n;
>>> +struct rte_mbuf *mbuf;
>>> +struct rx_queue *rxq = queue;
>>> +struct pollfd pfd;
>>> +uint16_t num_rx;
>>> +unsigned long num_rx_bytes = 0;
>>> +
>>> +pfd.events = POLLIN;
>>> +pfd.fd = rxq->fd;
>>> +for (num_rx = 0; num_rx < nb_pkts; ) {
>>> +n = poll(, 1, 0);
>>> +
>>> +if (n <= 0)
>>> +break;
>>> +
>>
>> Considering that syscalls are rather expensive, it would be cheaper to
>> allocate an mbuf here and free it when read() returns -1 instead of
>> calling poll() to check whether a packet is waiting. This way you
>> save a syscall per packet and replace one syscall with one mbuf free
>> per poll.
>
> I made this change, but saw no performance difference in the two methods.
> Removing poll seems reasonable as it is simpler. TAP is already so slow is
> why the performance did not change is my guess. Anyone wanting to use TAP as
> a high performance interface is going to be surprised. I believe the best use
> case for the TAP interface is for control or exception path.
Agreed, TAP does not look like designed for performance as a first goal.
You could do the same simplification for TX path, BTW.
Best Regards,
Micha? Miros?aw
[dpdk-dev] [PATCH v4] drivers/net:new PMD using tun/tap host interface
2016-10-04 16:45 GMT+02:00, Keith Wiles :
> The rte_eth_tap.c PMD creates a device using TUN/TAP interfaces
> on the local host. The PMD allows for DPDK and the host to
> communicate using a raw device interface on the host and in
> the DPDK application. The device created is a Tap device with
> a L2 packet header.
[...]
> +static uint16_t
> +pmd_rx_burst(void *queue, struct rte_mbuf **bufs, uint16_t nb_pkts)
> +{
> + int len, n;
> + struct rte_mbuf *mbuf;
> + struct rx_queue *rxq = queue;
> + struct pollfd pfd;
> + uint16_t num_rx;
> + unsigned long num_rx_bytes = 0;
> +
> + pfd.events = POLLIN;
> + pfd.fd = rxq->fd;
> + for (num_rx = 0; num_rx < nb_pkts; ) {
> + n = poll(, 1, 0);
> +
> + if (n <= 0)
> + break;
> +
Considering that syscalls are rather expensive, it would be cheaper to
allocate an mbuf here and free it when read() returns -1 instead of
calling poll() to check whether a packet is waiting. This way you
save a syscall per packet and replace one syscall with one mbuf free
per poll.
Best Regards,
Micha??Miros?aw
