> From: Stephen Hemminger [mailto:[email protected]] > Sent: Tuesday, 24 March 2026 18.12 > > On Mon, 16 Mar 2026 16:55:29 +0100 > Morten Brørup <[email protected]> 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>
