Strip layer 2 headers like mpls and pppoe

[HKalbasi]

Currently retina strips vlan header using dpdk, but it ignores packets with other layer 2 headers like mpls and pppoe. What is the best way to handle packets containing these headers? I think dpdk can't offload striping some of them to the NIC. Should retina handle them itself? Or should we add some plugins to dpdk using things like ddp or p4? And what about higher layer tunnels like gre, gtpu, ip in ip, ipsec, ...? They are not my problem currently, but I think they are related and it is good to think about them and find some solution to cover them as well.

[HKalbasi]

@tbarbette What is your opinion on this? Would you accept PR adding support for parsing and stripping these headers in retina, or you prefer to offload it to other things like dpdk?

[tbarbette]

The cleanest way would be to check if the stripping is supported through DPDK capacity flags, and if not, do it in software yes.

I didn't know DDP was programmable by the end users. Is it now?

For P4, it likely does not make sense to combine DPDK RTE_FLOW and P4. Probably, if you've got a P4 NIC (which does not really exist in the end and is certainly not a commodity, so aside from academic research, I wouldn't bother), you want to do the whole parsing in P4 anyway. So, it would be a P4 backend for Retina instead of RTE_FLOW, and this is something else than just the problem of decapsulating.

[HKalbasi]

The cleanest way would be to check if the stripping is supported through DPDK capacity flags

I checked, and it doesn't support it afaict, at least on my NICs.

if you've got a P4 NIC which does not really exist in the end and is certainly not a commodity, so aside from academic research, I wouldn't bother

I heard about dpdk pipeline had software support for P4, but I guess there is no point in P4 if it is not going to be offloaded to the NIC or switch.

So I went ahead with implementing this in retina, and it was straight forward. But the problem is that now all pppoe packets are on a single core. I searched a bit, and it seems at least on i40e NICs RSS doesn't support pppoe. If it ends up being true, what is the solution? My idea was to capture packets in a different NIC/machine, strip pppoe and other irrelevant headers, and send the packet again to the retina's NIC. This should work but it seems very wasteful.

[tbarbette]

I meant it should be checked and runtime and use software only if HW is not supported, just to be sure. Yes definitely some NIC won't support PPPoE or any peculiar encapsulation (or domain specific like GTP).

I'm not surprised RSS is not compatible with PPPoE. Can i40e have different RSS actions? If so, maybe with PPPoE you can use an RSS on flexible bytes and hash on 2 bytes that you identify as pseudo-random for PPPoE (PPPoE session id?).

This kind of stuff can be done with CX5+ at least.