Awesome, looks like you already signed up on the spreadsheet. Thanks, Tom

[...] Great. hmm interesting "see" here is going to get pretty lose when the hardware is modifying fields and packet data. But I think I agree with the spirit. The XDP program shouldn't be trying to

<hannes@...> wrote: ixgbe, mlx, e1000 drivers can disable vlan filtering. What happens with internal nic switch and vlan doesn't matter. If internal nic switch doesn't have 'vlan'

There's a couple of us in the OVS space that are interested in the potential for an eBPF/XDP datapath, so I'd like to join the discussions. <iovisor-dev@...> wrote:

I asked that during the meeting because of my limited exposure with hardware and their programmability, but maybe John can answer those. Does e.g. a VF connected to a network card internal switch

Exactly. I think that very much resonates with what Thomas said in the other thread: sounds like we all are on the same page here. I also think the program should see the packet the way it is

+1 the stack should be sufficient for long time.

<brouer@...> wrote: Yes, we'll probably need offset and length as input and output. But I think we are restricting packets to a single page so we don't need a vector of these. Yes, but IMO we

Thanks all for attending! Please find the meeting minutes below. == Progress Updates Brenden + Ari: Made some ixgbe driver progress for early drop, changes are visible at:

The high level idea is to not hard code the metadata as we have traditionally done in NIC descriptors but to let this be programmed via the XDP program. For example a parser block written in bpf can

Not in the meta data structure itself, but it may be visible to the verifier/jit for accounting purposes. I do foresee a need for grow/shrink head/tail, which would be exposed as a helper function

The plan is to keep it on the stack. It should be quite small. So far it is a data pointer, a data_end pointer, and we can add a rx hash later. The current implementation keeps these in a per-cpu

I see little value in enabling VLAN acceleration in an XDP environment. A VLAN header would be parsed or constructed with BPF instructions. Any offload of VLAN parsing or constructions should be done

What should be the content of the XDP meta-data structure? I find the HW RX-hash very useful for DDoS filtering, and I would like for it to survive until TX completion. Do we need the (page-)offset

Once pages comes from the page-pool, then we actually "own" the struct-page. Thus, we do have the option of storing some meta-data inside struct-page. Another option, given our requirement that the

I also want a XDP/eBPF hook placed at TX DMA completion time, or when the page is recycled back to the page-pool. This will allow innovating more advanced DDoS filter solutions, as this creates a

Many NICs today does VLAN acceleration by delivering the VLAN TCI in the RX descriptor, and stripping/starting the packet-data after the VLAN header. For XDP this special case handling for VLANs is

It is a fundamental requirement that the RX pages (handed over to XDP) are writable. This is usually _not_ the case in NIC drivers. Thus, the current XDP prove-of-concept code violates the DMA

More people from Brocade may come as well

I might be able to come. Haven't been to the Brocade office in a while, kind of overdue for a trip south.