[dpdk-dev,v2] nfp: handle packets with length 0 as usual ones
Checks
Commit Message
A DPDK app could, whatever the reason, send packets with size 0.
The PMD is not sending those packets, which does make sense,
but the problem is the mbuf is not released either. That leads
to mbufs not being available, because the app trusts the
PMD will do it.
Although this is a problem related to app wrong behaviour, we
should harden the PMD in this regard. Not sending a packet with
size 0 could be problematic, needing special handling inside the
PMD xmit function. It could be a burst of those packets, which can
be easily handled, but it could also be a single packet in a burst,
what is harder to handle.
It would be simpler to just send that kind of packets, which will
likely be dropped by the hw at some point. The main problem is how
the fw/hw handles the DMA, because a dma read to a hypothetical 0x0
address could trigger an IOMMU error. It turns out, it is safe to
send a descriptor with packet size 0 to the hardware: the DMA never
happens, from the PCIe point of view.
v2: remove code for handling zero-length mbuf chained.
Signed-off-by: Alejandro Lucero <alejandro.lucero@netronome.com>
---
drivers/net/nfp/nfp_net.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
Comments
On 8/22/2017 11:41 AM, Alejandro Lucero wrote:
> A DPDK app could, whatever the reason, send packets with size 0.
> The PMD is not sending those packets, which does make sense,
> but the problem is the mbuf is not released either. That leads
> to mbufs not being available, because the app trusts the
> PMD will do it.
>
> Although this is a problem related to app wrong behaviour, we
> should harden the PMD in this regard. Not sending a packet with
> size 0 could be problematic, needing special handling inside the
> PMD xmit function. It could be a burst of those packets, which can
> be easily handled, but it could also be a single packet in a burst,
> what is harder to handle.
>
> It would be simpler to just send that kind of packets, which will
> likely be dropped by the hw at some point. The main problem is how
> the fw/hw handles the DMA, because a dma read to a hypothetical 0x0
> address could trigger an IOMMU error. It turns out, it is safe to
> send a descriptor with packet size 0 to the hardware: the DMA never
> happens, from the PCIe point of view.
>
> Signed-off-by: Alejandro Lucero <alejandro.lucero@netronome.com>
Applied to dpdk-next-net/master, thanks.
@@ -2094,7 +2094,7 @@ uint32_t nfp_net_txq_full(struct nfp_net_txq *txq)
*/
pkt_size = pkt->pkt_len;
- while (pkt_size) {
+ while (pkt) {
/* Copying TSO, VLAN and cksum info */
*txds = txd;
@@ -2126,13 +2126,13 @@ uint32_t nfp_net_txq_full(struct nfp_net_txq *txq)
txq->wr_p = 0;
pkt_size -= dma_size;
- if (!pkt_size) {
+ if (!pkt_size)
/* End of packet */
txds->offset_eop |= PCIE_DESC_TX_EOP;
- } else {
+ else
txds->offset_eop &= PCIE_DESC_TX_OFFSET_MASK;
- pkt = pkt->next;
- }
+
+ pkt = pkt->next;
/* Referencing next free TX descriptor */
txds = &txq->txds[txq->wr_p];
lmbuf = &txq->txbufs[txq->wr_p].mbuf;