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

Morten Brørup
2026-03-16T15:55:33Z

> From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> Sent: Monday, 16 March 2026 16.34
>
> On Tue, Mar 10, 2026 at 09:10:03AM -0700, Stephen Hemminger wrote:
> > When the source port has VLAN strip enabled, captured packets have
> > the VLAN tag in mbuf metadata (vlan_tci) but not in the packet data.
> > Similarly, TX captures with pending VLAN insert have the tag only
> > in metadata. The resulting pcap files contain untagged packets.
> >
> > Convert RX_VLAN_STRIPPED metadata to TX_VLAN offload requests on
> > dequeued mbufs and call rte_eth_tx_prepare() before
> rte_eth_tx_burst()
> > so the pcap vdev inserts the tag into the packet data.
> >
>
> 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.

Let's say an application adds 1 to the mbufs' refcnt before each Tx, so the mbufs still exist after Tx.
Then, the application captures/mirrors the packets consumed by the driver, and logs/drops the packets the driver was unable to consume.
If the capture/mirror is filtering by VLAN ID, modifying the packets in the driver's Tx function is bad.

-Morten