[PATCH v20 25/25] app/pdump: preserve VLAN tags in captured packets

[Morten Brørup]

> From: Stephen Hemminger [mailto:stephen at networkplumber.org]
> Sent: Tuesday, 24 March 2026 18.12
> 
> On Mon, 16 Mar 2026 16:55:29 +0100
> Morten Brørup <mb at smartsharesystems.com> wrote:
> 
> > >
> > > This is an example of something I previously flagged. Like with
> real
> > > hardware, I think the PMD should be inserting the VLAN tag into the
> > > packet
> > > as part of the Tx function, not the prepare function.
> >
> > Agree with Bruce on this.
> > For simple stuff like VLAN offload, applications should not be
> required to call tx_prep first.
> >
> > However, the Tx function is supposed to not modify the packets;
> relevant when refcnt > 1.
> >
> > Instead of modifying the packet data to insert/strip the VLAN tag,
> > perhaps the driver can split the write/read operation into multiple
> write/read operations:
> > 1. the Ethernet header
> > 2. the VLAN tag
> > 3. the remaining packet data
> >
> > I haven't really followed the pcap driver, so maybe my suggestion
> doesn't make sense.
> 
> The prepare code and VLAN was copied from virtio.
> I assume virtio is widely used already.

OK, that makes it harder to object to.

<rant>

I checked out the virtio code.
virtio_xmit_pkts_prepare() calls rte_vlan_insert().
And rte_vlan_insert() doesn't support mbuf refcnt > 1.

So basically, these drivers don't support simple VLAN tagging when mbuf refcnt > 1.
This seems like a major limitation, which should be prominently documented.

A decade ago, when we started using DPDK for our projects, one of the things I loved about it was its documentation.
But after a while, I noticed that a lot of the documented mbuf library features weren't fully implemented.
These limitations should be documented.

E.g. if an important driver like virtio doesn't support VLAN tagging of indirect/cloned mbufs, this should be prominently highlighted in documentation!

</rant>