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 38B25458A7 for ; Fri, 30 Aug 2024 13:06:21 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id AAC3B42E8F; Fri, 30 Aug 2024 13:06:17 +0200 (CEST) Received: from mail-ed1-f50.google.com (mail-ed1-f50.google.com [209.85.208.50]) by mails.dpdk.org (Postfix) with ESMTP id 28A4F42E4C; Fri, 30 Aug 2024 10:14:53 +0200 (CEST) Received: by mail-ed1-f50.google.com with SMTP id 4fb4d7f45d1cf-5bf0261f162so1603648a12.0; Fri, 30 Aug 2024 01:14:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1725005692; x=1725610492; darn=dpdk.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=PcUULqjk4N2fmLb7191RxEPoR17c1VozWSkos3ltqNY=; b=Vue7v8C85DMBv5ZPsZo7C+v5iTS6kGXNlYCcjEAgL45Umvmp5UB2QIvTYCUZxKh4sa tpyIjzbOcuYulqLJsOSZap0dOAuk879+DFNayZNQn2mlEFuZRaWeV6zWhJViuY/vnnqM m+kgyc/hQJGcu8FnueTrJ9Yf5xnhdTaZ7sPMMJRvjxBiXbcnnw2kg2toA9DJ2txhYq70 B7v53RacFCz2ylH5gG9N2DrUr9nxqUjXYaK5zUSsSqCJslnTLOst6mfZf8GoKc3upej5 KgiYe66iCDUUf313nATksTC4HKVZEVTtcxr4i3I4bBaLhmrKqGQ7nZR0Ieh5Yd2IkygO pZKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725005692; x=1725610492; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=PcUULqjk4N2fmLb7191RxEPoR17c1VozWSkos3ltqNY=; b=cF8KsXGuWZA+tLVsuURWFMGGqhDkd2hkMp0g9x/18nAcFNprkfRPBlkhfW4Y6z+FmG KTXcuyZ5qe5oy07S7DgUe9CSmC+BY1qjPY9x7a6X1fHi+jUKVQaY700UtjHxc3f+AldK VKYl5qGY0MN7ZJ5xnk6lUGWUhB5hLOddXl4q7AfTuHTVVhduSbmf+im99kmKH+iz8IwA KvWcKvCJmOxt/8E1aAYnDRQOZnmm0Vwh7DkYrjKkdgS0WbFPFFTtkbjxdzDxUq/XZzFv 1mHyP9v6Xt62P9o5KfR1fiT8OqqZC4iyBpWb4EbqfMaP1GD80YEMxQrpSA7LAjHYBCan cEsw== X-Forwarded-Encrypted: i=1; AJvYcCVmXAp5mCjvug2Ope1/nGZnkxOZt7u0FwIlItDLfVLqfKAjkytmvshTKImXmmVCDAP5Nct/fg==@dpdk.org X-Gm-Message-State: AOJu0YzfKReF5/A4h6OaWDGQwWpyRGj/aYqHu3lwE+ruUMaf5zZBTVtE jKnQBVHiM1+TrrtZIBuf0peJ6341DzHPMBrNTAUz1Li53w3RzVR38ER0P8gru9uL81UKx/WmqLC QZ2uY5ZH6DRyuz3qrmNN20OK01dITdceewyc= X-Google-Smtp-Source: AGHT+IF5ePjf4uiNbKJpGIXpg0WQDcjjalKX3ham2VqyHjswv4BYd0Dq75xhEa85IzoNY+qRBWz/ytfEsJdWWV+WCRU= X-Received: by 2002:a05:6402:3506:b0:5c0:a8b7:f2b8 with SMTP id 4fb4d7f45d1cf-5c21ed8c6b8mr4849349a12.27.1725005692078; Fri, 30 Aug 2024 01:14:52 -0700 (PDT) MIME-Version: 1.0 From: "bala krishnan.k" Date: Fri, 30 Aug 2024 13:44:40 +0530 Message-ID: Subject: v4_acl lookup failed after rte_pktmbuf_adj in dpdk pipeline To: dev@dpdk.org, users@dpdk.org Content-Type: multipart/alternative; boundary="000000000000830fca0620e22f80" X-Mailman-Approved-At: Fri, 30 Aug 2024 13:06:16 +0200 X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: users-bounces@dpdk.org --000000000000830fca0620e22f80 Content-Type: text/plain; charset="UTF-8" Hi All, I using dpdk pipeline and performing table lookup to decide the packet forwarding. One of my use case v4_acl lookup failing could not find the reason. Scenario: pipeline test_pipe1 table match v4_acl ipv4 offset 274 size 1K action test. Acl table offset is set to 274. In coming packets contains vlan header. When normal packet received src and ds tip matching according to the rules I pushed into the table. Packets with GRE header and outer ip header src and dst ip also matching. I wanted to do lookup for inner IP header src and dst fields , to achieve this used *rte_pktmbuf_adj* to remove the gre and outer ip header. Again I placed eth_header and vlan header at the start position. *Code snippet:* rte_memcpy(&temp_hdr, eth_header, (sizeof(struct rte_ether_hdr) + sizeof(struct rte_vlan_hdr) + sizeof(struct rte_ipv4_hdr) + sizeof(gre_hdr_t))); rte_pktmbuf_adj (mb, (sizeof(struct rte_ether_hdr) + sizeof(struct rte_vlan_hdr) + sizeof(struct rte_ipv4_hdr) + sizeof(gre_hdr_t))); rte_pktmbuf_prepend (mb, sizeof (struct rte_ether_hdr) + sizeof(struct rte_vlan_hdr) ); pkt = rte_pktmbuf_mtod(mb, uint8_t *); rte_memcpy (pkt, &temp_hdr, sizeof(struct rte_ether_hdr) + sizeof(struct rte_vlan_hdr) ) ; ip = (struct rte_ipv4_hdr*) (pkt + sizeof(struct rte_ether_hdr) + sizeof(struct rte_vlan_hdr)); My expectation is inner header lookup will work because now I moved the inner header in place of outer header position. But lookup failed could not find the reason for failure. Could any one help on this to solve the issue. Why the table offset is set to 274 to match the IP header fields? Is mbuf ip header will be at offset 274 always, I know mbuf headroom is 128 byte long Could any one explain point me the document to refer the offset calculation for mbuf and acl table? Regards, Bala --000000000000830fca0620e22f80 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi All,

=C2=A0=C2=A0=C2=A0 I using dpdk pipeline and performing table lookup to decide the packet forwarding.

One of my use case v4_acl lookup failing could not find the reason.

=C2=A0

Scenario:

pipeline test_pipe1 table match v4_acl ipv4 offset 274 size 1K action test.

=C2=A0

Acl table offset is set to 274. In coming packets contains vlan header.

When normal packet received src and ds tip matching according =C2=A0to the rules I push= ed into the table.

Packets with GRE header and outer ip header src and dst ip also matching.

=C2=A0

I wanted to do lookup for inner IP header src and dst fields , to achieve this used = rte_pktmbuf_adj to remove the gre and outer ip header.

Again I placed eth_header and vlan header at the start position.

=C2=A0

Code snippet:

=C2=A0

rte_memcpy(&temp_hdr, eth_header,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (sizeof(struct rte_ether_hdr) + sizeof(struct rte_vlan_hdr) +

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 sizeof(struct rte_ipv4_hdr) +

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 sizeof(gre_hdr_t)));

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 rte_pktmbuf_adj (mb, (sizeof(struct rte_ether_hdr) + sizeof(struct rte_vlan_hdr) +

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 sizeof(struct rte_ipv4_hdr) +

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 sizeof(gre_hdr_t)));

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 rte_pktmbuf_prepend (mb,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 sizeof (struct rte_ether_hdr) + sizeof(struct rte_vlan_hdr) );

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 pkt =3D rte_pktmbuf_mtod(mb, uint8_t *);

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 rte_memcpy (pkt, &temp_hdr,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 sizeof(struct rte_ether_hdr) + sizeof(struct rte_vlan_hdr) ) ;

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ip =3D (struct rte_ipv4_hdr*) (pkt + sizeof(struct rte_ether_hdr) + sizeof(= struct rte_vlan_hdr));

=C2=A0

=C2=A0

My expectation is inner header lookup will work because now I moved the inner header in place of outer header position.

But lookup failed could not find the reason for failure.

=C2=A0

Could any one help on this to solve the issue.

=C2=A0

Why the table offset is set to 274 to match the IP header fields?

Is mbuf ip header will be at offset 274 always, I know mbuf headroom is 128 byte long =

Could any one explain point me the document to refer the offset calculation for mbuf = and acl table?

=C2=A0

=C2=A0

Regards,

Bala=C2=A0



<= /div> --000000000000830fca0620e22f80--