Re: nftables: bridge filter with queue to userspace

["Martin Gröger" <mgroeger1@web.de>]

Am 30.10.2015 14:38, schrieb Florian Westphal:
> Martin Gröger <mgroeger1@web.de> wrote:
>>>> Florian told me he will come up sooner or later with native queue
>>>> support for nft (ie. no bridge_netfilter required anymore).
>>> Argh.  I'm a moron and forgot about this.
>> How does a native (indepent on bridge) queue support should work ?
> Highlevel?
> nft add bridge filter forward queue
That's exactly what I expected.
> But on the backend/userspace side its a good question.
>
> For instance, where should NFQA_PAYLOAD point to?
>
> Start of ethernet header?
> Start of network header?
However, the full information contained in the paket (incl. VLAN) should 
be given to the user.
So it wouold make sense to point to the ethernet header with NFQA_PAYLOAD.
>
> If the former, what should NFQA_HWADDR contain?
> Should it even be present?
>
> What about ->hw_protocol in nfqnl_msg_packet_hdr ?
>
> We also should definitely present VLAN headers to userspace
> in some way.  Standard question is if that should be extra attribute
> or if we should inject the vlan header into the packet data.
>
> I'm leaning towards:
> - NFQA_PAYLOAD starts at beginning of ethernet header
ok
> - nfqnl_msg_packet_hdr->hw_protocol is set to skb->protocol OR
>    skb->vlan_proto in offload case (even though this information is
>    redundant since its also present in the ethernet header ...)
> - NFQA_PAYLOAD maintains illusion of disabled/non-existant VLAN hw
> offload, i.e. we insert it into NFQA_PAYLOAD between mac and network
> header.
Sorry, I don't understand this. The VLAN header is (if exists) after the 
source MAC. If a paket is bridged, I would expect, that the VLAN header 
is kept unchanged. I would expect to find the VLAN header exactly there! 
Is this wrong?
> - NFQA_HWADDR attribute is not present (redundant, we have this in
>    NFQA_PAYLOAD).
>>> I still have the q&d hack that makes it work but no reroute (re-bridge,
>>> cough) support, just dump-to-userspace.
>> As far as I understand this would be sufficient for my usecase,
>> since I want simply to inspect the packets and then decide to accept
>> or drop them.
> Yes, in fact I think we should just ignore reroute (bad idea) or rebridge
> (what would be the use case of this...?)
>
> If someone really needs to be able to resend/relay packet they could do
> this in userspace or just use PRE_ROUTING since thats before bridge
> asks the FDB for the output port.
>
> We could add bridge_me_harder to pick another output device for queueing
> in BRIDGE OUTPUT but I have no idea why one would want such feature.
>
I'm currently trying to understand the structure.
So to add the missing parts:
- there is no change in the nftable kernel modules necessary?
- there are changes in the nftnl library necessary?
- there are changes in nft necessary?
Is this correct?

I didn't find much documentation conecrning the architecture.
Only Pablo_nftables-osd-userday-2013.pdf and 
Nftables-osd-2013-developer.pdf.
Is there somethimg more to read to get an better understanding of nftables?

Thanks,
Martin