From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id B842A43E87; Tue, 16 Apr 2024 20:11:10 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 83CFF40268; Tue, 16 Apr 2024 20:11:10 +0200 (CEST) Received: from dkmailrelay1.smartsharesystems.com (smartserver.smartsharesystems.com [77.243.40.215]) by mails.dpdk.org (Postfix) with ESMTP id 502BF40262 for ; Tue, 16 Apr 2024 20:11:08 +0200 (CEST) Received: from smartserver.smartsharesystems.com (smartserver.smartsharesys.local [192.168.4.10]) by dkmailrelay1.smartsharesystems.com (Postfix) with ESMTP id 51DD92067B; Tue, 16 Apr 2024 20:11:07 +0200 (CEST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [DPDK/ethdev Bug 1416] net/af_packet: tx_burst() can modify packets Date: Tue, 16 Apr 2024 20:11:05 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <98CBD80474FA8B44BF855DF32C47DC35E9F3AA@smartserver.smartshare.dk> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [DPDK/ethdev Bug 1416] net/af_packet: tx_burst() can modify packets Thread-Index: AQHaj+klsHkMFtD6mEu3P6qfirzOCbFq5v0AgAAmCbCAAAQrYIAAB5YQgAAMu+A= References: <20240416083846.08e8dcad@hermes.local> <2b4a3bac389141bbae7a2d0ec31df5c6@huawei.com> <98CBD80474FA8B44BF855DF32C47DC35E9F3A9@smartserver.smartshare.dk> From: =?iso-8859-1?Q?Morten_Br=F8rup?= To: "Konstantin Ananyev" , "Stephen Hemminger" Cc: X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org > > > > > static uint16_t > > > > > eth_af_packet_tx(void *queue, struct rte_mbuf **bufs, uint16_t > > > nb_pkts) > > > > > { > > > > > ... > > > > > for (i =3D 0; i < nb_pkts; i++) { > > > > > mbuf =3D *bufs++; > > > > > > > > > > ... > > > > > > > > > > /* insert vlan info if necessary */ > > > > > if (mbuf->ol_flags & RTE_MBUF_F_TX_VLAN) { > > > > > if (rte_vlan_insert(&mbuf)) { > > > > > rte_pktmbuf_free(mbuf); > > > > > continue; > > > > > > > > > > AFAIU, it does copy of mbuf contents into pbuf anyway (just = few > line > > > below). > > > > > So the fix might be - simply insert VLAN tag at copying stage. > > > > > Feel free to correct me, if I missed something. > > > > > > > > vlan_insert will fail if the mbuf is has refcnt > 1. > > > > > > > > static inline int rte_vlan_insert(struct rte_mbuf **m) > > > > { > > > > struct rte_ether_hdr *oh, *nh; > > > > struct rte_vlan_hdr *vh; > > > > > > > > /* Can't insert header if mbuf is shared */ > > > > if (!RTE_MBUF_DIRECT(*m) || rte_mbuf_refcnt_read(*m) > 1) > > > > return -EINVAL; > > > > > > You are right, I missed that. > > > Will close it then. > > > > Don't close, silent drop is also a bug. > > > > The VLAN tag could be insert when copying, as originally suggested. >=20 > Agree, but to me that would be enhancement request, not a bug report. Hmm... there is still a bug, although slightly different: net/af_packet: tx_burst() silently drops packets with RTE_MBUF_F_TX_VLAN = if mbuf is shared And the suggested fixes would fix this (other) bug. >=20 > > > > Alternatively, set tpacket2_hdr's tp_vlan_tci and tp_vlan_tpid = fields > and set TP_STATUS_VLAN_VALID and > > TP_STATUS_VLAN_TPID_VALID flags in tp_status. If the kernel reads > those?