Hey Mohsin,
This is how the packet trace goes:
00:42:45:147623: dpdk-input
VirtualFunctionEthernet1/10/0 rx queue 0
buffer 0x9ad1b: current data 0, length 124, buffer-pool 0, ref-count 1,
totlen-nifb 0, trace handle 0x1000001
ext-hdr-valid
l4-cksum-computed l4-cksum-correct
PKT MBUF: port 0, nb_segs 1, pkt_len 124
buf_len 2176, data_len 124, ol_flags 0x182, data_off 128, phys_addr
0x26b4740
packet_type 0x211 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0
rss 0xc8173f29 fdir.hi 0x0 fdir.lo 0xc8173f29
Packet Offload Flags
PKT_RX_RSS_HASH (0x0002) RX packet with RSS hash result
PKT_RX_IP_CKSUM_GOOD (0x0080) IP cksum of RX pkt. is valid
PKT_RX_L4_CKSUM_GOOD (0x0100) L4 cksum of RX pkt. is valid
Packet Types
RTE_PTYPE_L2_ETHER (0x0001) Ethernet packet
RTE_PTYPE_L3_IPV4 (0x0010) IPv4 packet without extension headers
RTE_PTYPE_L4_UDP (0x0200) UDP packet
IP4: 00:10:94:00:00:03 -> 2e:16:e9:9e:3e:5d
UDP: 171.23.49.58 -> 192.168.45.200
tos 0x04, ttl 255, length 110, checksum 0xf0b7 dscp unknown ecn NON_ECN
fragment id 0x0001
UDP: 4444 -> 1025
length 90, checksum 0xffff
00:42:45:147644: ethernet-input
frame: flags 0x3, hw-if-index 2, sw-if-index 2
IP4: 00:10:94:00:00:03 -> 2e:16:e9:9e:3e:5d
00:42:45:147659: ip4-input-no-checksum
UDP: 171.23.49.58 -> 192.168.45.200
tos 0x04, ttl 255, length 110, checksum 0xf0b7 dscp unknown ecn NON_ECN
fragment id 0x0001
UDP: 4444 -> 1025
length 90, checksum 0xffff
00:42:45:147666: ip4-lookup
fib 0 dpo-idx 6 flow hash: 0x00000000
UDP: 171.23.49.58 -> 192.168.45.200
tos 0x04, ttl 255, length 110, checksum 0xf0b7 dscp unknown ecn NON_ECN
fragment id 0x0001
UDP: 4444 -> 1025
length 90, checksum 0xffff
00:42:45:147676: ip4-rewrite
tx_sw_if_index 4 dpo-idx 6 : ipv4 via 0.0.0.0 gtpu_tunnel0: mtu:9000
next:5 flags:[] flow hash: 0x00000000
00000000: 4504006e00010000fe11f1b7ab17313ac0a82dc8115c0401005affff00000000
00000020: 00000000000000000000000000000000000000000000000000000000
00:42:45:147682: gtpu4-encap
GTPU encap to gtpu_tunnel0 tteid 8892
POLICER_CLASSIFY: sw_if_index 4 next 4 table 0 offset 1280 policer_index 0
00:42:49:659573: ip4-load-balance
fib 4 dpo-idx 5 flow hash: 0x7f9759da
UDP: 10.43.67.108 -> 172.16.34.129
tos 0x00, ttl 254, length 154, checksum 0xa02a dscp CS0 ecn NON_ECN
fragment id 0x0000
UDP: 55897 -> 2152
length 134, checksum 0x686f
00:42:49:659593: ip4-rewrite
tx_sw_if_index 3 dpo-idx 5 : ipv4 via 10.43.67.1
VirtualFunctionEthernet1/10/1: mtu:1500 next:3 flags:[]
0242424242420209c0b746100800 flow hash: 0x7f9759da
00000000: 0242424242420209c0b7461008004500009a00000000fd11a12a0a2b436cac10
00000020: 2281da5908680086686f34ff0076000022bc00000085010009004540
00:42:49:659608: VirtualFunctionEthernet1/10/1-output
VirtualFunctionEthernet1/10/1
IP4: 02:09:c0:b7:46:10 -> 02:42:42:42:42:42
UDP: 10.43.67.108 -> 172.16.34.129
tos 0x00, ttl 253, length 154, checksum 0xa12a dscp CS0 ecn NON_ECN
fragment id 0x0000
UDP: 55897 -> 2152
length 134, checksum 0x686f
00:42:49:659618: VirtualFunctionEthernet1/10/1-tx
VirtualFunctionEthernet1/10/1 tx queue 1
buffer 0x9ad1b: current data -44, length 168, buffer-pool 0, ref-count 1,
totlen-nifb 0, trace handle 0x1000001
ext-hdr-valid
l4-cksum-computed l4-cksum-correct l2-hdr-offset 0
l3-hdr-offset 14
PKT MBUF: port 0, nb_segs 1, pkt_len 168
buf_len 2176, data_len 168, ol_flags 0x182, data_off 84, phys_addr
0x26b4740
packet_type 0x211 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0
rss 0xc8173f29 fdir.hi 0x0 fdir.lo 0xc8173f29
Packet Offload Flags
PKT_RX_RSS_HASH (0x0002) RX packet with RSS hash result
PKT_RX_IP_CKSUM_GOOD (0x0080) IP cksum of RX pkt. is valid
PKT_RX_L4_CKSUM_GOOD (0x0100) L4 cksum of RX pkt. is valid
Packet Types
RTE_PTYPE_L2_ETHER (0x0001) Ethernet packet
RTE_PTYPE_L3_IPV4 (0x0010) IPv4 packet without extension headers
RTE_PTYPE_L4_UDP (0x0200) UDP packet
IP4: 02:09:c0:b7:46:10 -> 02:42:42:42:42:42
UDP: 10.43.67.108 -> 172.16.34.129
tos 0x00, ttl 253, length 154, checksum 0xa12a dscp CS0 ecn NON_ECN
fragment id 0x0000
UDP: 55897 -> 2152
length 134, checksum 0x686f
Interface details are as follows : (Tried with SRIOV as well as vfio-pci)
Network devices using DPDK-compatible driver
============================================
0000:01:10.0 '82599 Ethernet Controller Virtual Function 10ed' drv=vfio-pci
unused=ixgbevf
0000:01:10.1 '82599 Ethernet Controller Virtual Function 10ed' drv=vfio-pci
unused=ixgbevf
Thanks,
Akash
On Tue, Oct 19, 2021 at 4:54 PM Mohsin Kazmi (sykazmi) <[email protected]>
wrote:
> Hi Akash,
>
>
>
> Please provide the information about the interface(s) you are using either
> with vpp native driver or with dpdk? And ‘show trace’ will help here.
>
>
>
> -br
>
> Mohsin
>
>
>
> *From: *<[email protected]> on behalf of Akash S R <
> [email protected]>
> *Date: *Tuesday, October 19, 2021 at 11:03 AM
> *To: *Pim van Pelt <[email protected]>
> *Cc: *vpp-dev <[email protected]>, Ole Troan <[email protected]>,
> Dave Barach <[email protected]>
> *Subject: *Re: [vpp-dev] VPP adding extra payload of 0's to packet in
> some node
>
>
>
> Hi Pim,
>
>
>
> This is the packet which was encapsulated with GTP Header and sent out of
> the Interface.
>
> Frame size received/below is 106. Why did NIC add 0's here ? Frame size
> without 0's is 90 > 64 right.
>
> Thats why was suspecting VPP if it add's any extra 0'x based on flags or
> in some node.
>
>
>
> 0000 00 00 00 01 00 06 a0 36 9f 37 dc ec 00 00 08 00
> 0010 45 00 00 5a 00 00 00 00 fd 11 b4 a0 42 42 42 32
> 0020 42 42 42 3c 4e 98 08 68 00 46 00 79 34 ff 00 36
> 0030 00 00 00 01 00 00 00 85 01 00 05 00 45 00 00 1e
> 0040 ef 1b 40 00 3f 11 b0 0a 42 42 42 5a 0b 0c 0d 01
> 0050 11 5d 11 62 00 0a f8 08 48 69
> *00 00 00 00 00 00 0060 00 00 00 00 00 00 00 00 00 00*
>
>
>
> /Akash
>
>
>
> On Tue, Oct 19, 2021 at 2:28 PM Pim van Pelt <[email protected]> wrote:
>
> Hoi Akash,
>
>
>
> You asked a similar question last week. Is it still the case that you're
> describing a packet which is smaller than the 64b frame size described in
> IEEE 802.3?
>
> See https://en.wikipedia.org/wiki/Ethernet_frame and a rather informative
> context at
> https://www.sciencedirect.com/topics/computer-science/minimum-frame-size
>
>
>
> If not, can you show the packet you're intending on sending, how long it
> is, and how long you intend for it to be ?
>
>
>
> groet,
>
> Pim
>
>
>
> On Tue, Oct 19, 2021 at 8:31 AM Akash S R <[email protected]>
> wrote:
>
> Hi Mates,
>
>
>
> In my case, VPP is adding some 0's as extra payload onto the packet and
> sending it out to NIC which is nearly 14 - 18 bytes. What is the node which
> add's this ?
>
> Or b0->flags is responsible for such case? Please help
>
>
>
>
>
> /Akash
>
>
>
>
>
>
> --
>
> Pim van Pelt <[email protected]>
> PBVP1-RIPE - http://www.ipng.nl/
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20346): https://lists.fd.io/g/vpp-dev/message/20346
Mute This Topic: https://lists.fd.io/mt/86434059/21656
Group Owner: [email protected]
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
