[dpdk-users] Why packet_type is zero?

[dpdk-users] Why packet_type is zero?

[Arseniy Zaostrovnykh]

Hello,

I have the following setup of VirtualBox machines on a single host:
node2:
  eth0: VBox NAT, connecting to the host internet
  eth1: 192.168.1.12/24
   and additional route for 192.168.0.0/16 -> gateway 192.168.1.11

dpdk-node:
  eth0: VBox NaT, connecting to the host internet
  eth1: 192.168.1.11/24
  eth2: 192.168.2.11/24

Now I run
     node2 $ ping 192.168.2.13
so, following the route, it sends the ping ICMP messages to 192.168.1.11 
(dpdk-node).

On the dpdk-node I run l3fwd:
     dpdk-node $ sudo examples/l3fwd/build/app/l3fwd -c 0x01 -n 2 -- -p 
0x03 --config="(0,0,0),(1,0,0)"
with APP_LOOKUP_METHOD = APP_LOOKUP_EXACT_MATCH, and with some 
debug-printfs. In particular I printf
m->packet_type in the beginning of the l3fwd_simple_forward function.

Question:
Why does it prints 0? What is a possible causes?

P.S. my DPDK version is 2.1.0; The printf is executed on each ping 
message; tcpdump shows no other traffic in this internal network.

-- 
Respectfully,
Arseniy.

Re: [dpdk-users] Why packet_type is zero?

[Arseniy Zaostrovnykh]

Forgot to mention:
I tried KNI (first detaching eth1 and eth2 from the kernel) and pcap PMD 
drivers, with:
     dpdk-node $ sudo examples/l3fwd/build/app/l3fwd -c 0x01 -n 2 
--vdev=eth_pcap0,iface=eth2 --vdev=eth_pcap1,iface=eth1 -p 0x03 
--config="(0,0,0),(1,0,0)"
The sysptoms are identical.

On 06.11.2015 15:57, Arseniy Zaostrovnykh wrote:
> Hello,
>
> I have the following setup of VirtualBox machines on a single host:
> node2:
>  eth0: VBox NAT, connecting to the host internet
>  eth1: 192.168.1.12/24
>   and additional route for 192.168.0.0/16 -> gateway 192.168.1.11
>
> dpdk-node:
>  eth0: VBox NaT, connecting to the host internet
>  eth1: 192.168.1.11/24
>  eth2: 192.168.2.11/24
>
> Now I run
>     node2 $ ping 192.168.2.13
> so, following the route, it sends the ping ICMP messages to 
> 192.168.1.11 (dpdk-node).
>
> On the dpdk-node I run l3fwd:
>     dpdk-node $ sudo examples/l3fwd/build/app/l3fwd -c 0x01 -n 2 -- -p 
> 0x03 --config="(0,0,0),(1,0,0)"
> with APP_LOOKUP_METHOD = APP_LOOKUP_EXACT_MATCH, and with some 
> debug-printfs. In particular I printf
> m->packet_type in the beginning of the l3fwd_simple_forward function.
>
> Question:
> Why does it prints 0? What is a possible causes?
>
> P.S. my DPDK version is 2.1.0; The printf is executed on each ping 
> message; tcpdump shows no other traffic in this internal network.
>

-- 
Respectfully,
Arseniy.

Re: [dpdk-users] Why packet_type is zero?

[Arseniy Zaostrovnykh]

Is the pcap driver obsolete?

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

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


On 06.11.2015 16:05, Arseniy Zaostrovnykh wrote:
> Forgot to mention:
> I tried KNI (first detaching eth1 and eth2 from the kernel) and pcap 
> PMD drivers, with:
>     dpdk-node $ sudo examples/l3fwd/build/app/l3fwd -c 0x01 -n 2 
> --vdev=eth_pcap0,iface=eth2 --vdev=eth_pcap1,iface=eth1 -p 0x03 
> --config="(0,0,0),(1,0,0)"
> The sysptoms are identical.
>
> On 06.11.2015 15:57, Arseniy Zaostrovnykh wrote:
>> Hello,
>>
>> I have the following setup of VirtualBox machines on a single host:
>> node2:
>>  eth0: VBox NAT, connecting to the host internet
>>  eth1: 192.168.1.12/24
>>   and additional route for 192.168.0.0/16 -> gateway 192.168.1.11
>>
>> dpdk-node:
>>  eth0: VBox NaT, connecting to the host internet
>>  eth1: 192.168.1.11/24
>>  eth2: 192.168.2.11/24
>>
>> Now I run
>>     node2 $ ping 192.168.2.13
>> so, following the route, it sends the ping ICMP messages to 
>> 192.168.1.11 (dpdk-node).
>>
>> On the dpdk-node I run l3fwd:
>>     dpdk-node $ sudo examples/l3fwd/build/app/l3fwd -c 0x01 -n 2 -- 
>> -p 0x03 --config="(0,0,0),(1,0,0)"
>> with APP_LOOKUP_METHOD = APP_LOOKUP_EXACT_MATCH, and with some 
>> debug-printfs. In particular I printf
>> m->packet_type in the beginning of the l3fwd_simple_forward function.
>>
>> Question:
>> Why does it prints 0? What is a possible causes?
>>
>> P.S. my DPDK version is 2.1.0; The printf is executed on each ping 
>> message; tcpdump shows no other traffic in this internal network.
>>
>

-- 
Respectfully,
Arseniy.

Re: [dpdk-users] Why packet_type is zero?

[Thomas Monjalon]

Thanks for reporting.

2015-11-10 15:46, Arseniy Zaostrovnykh:
> Is the pcap driver obsolete?

No

> 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
> 
> 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.