Skip to contentSkip to conversation

Why packet_type is zero?

dpdk-users Thomas Monjalon 1 participant 1 message Nov 10, 2015 3 messages not in the archive

lore
Share & tools
lore

A message that is not in the archive (sent off-list or not yet received): [email protected]

A message that is not in the archive (sent off-list or not yet received): [email protected]

A message that is not in the archive (sent off-list or not yet received): [email protected]

#3 lore raw

Thanks for reporting.

2015-11-10 15:46, Arseniy Zaostrovnykh:

Quoted 1 line

Is the pcap driver obsolete?

No

Quoted 16 lines

L3fwd example(http://dpdk.org/doc/guides/sample_app_ug/l3_forward.html) check the mbuf field packet_type, and in the zero case (which is a default value, as far as I know) it does nothing. At the same time, only few drivers even mention this field:

dpdk-2.1.0 $ grep packet_type drivers -Rl

     drivers/net/enic/enic_main.c
     drivers/net/e1000/igb_rxtx.c
     drivers/net/ixgbe/ixgbe_rxtx.c
     drivers/net/mlx4/mlx4.c
     drivers/net/i40e/i40e_rxtx.c
     drivers/net/mpipe/mpipe_tilegx.c
     drivers/net/vmxnet3/vmxnet3_rxtx.c
     drivers/net/fm10k/fm10k_rxtx.c
     drivers/net/cxgbe/sge.c
Quoted 2 lines

And a PCap driver (drivers/net/pcap/rte_eth_pcap.c) specifically, does not alter the field, so L3fwd application drops all packets.

The zero value is acceptable.
#define RTE_PTYPE_UNKNOWN 0x00000000

Maybe a fix is required in the l3fwd example?
Or maybe it should be explicit that it works with only few drivers.

More generally, the packet type is not mandatory for drivers. At a time we were talking about implementing a generic callback to fill it. Or it can be filled in an application fallback with parsing.