Re: RFC: Disable defered bridge hooks by default

[Patrick McHardy <kaber@trash.net>]

Amin Azez wrote:
> * Patrick McHardy wrote, On 19/07/06 17:36:
> 
>>The routing code shouldn't know anything about the bridge FDB.
>>  
> 
> True, I only suggest that the bridge work out what it is going to do
> with the packet just after routing (if any) but before post-routing. I
> can't think of much else that will happen to the packets between
> postrouting and bridge output that would spoil this.
> 
> I wasn't suggesting that bridging and routing modules should peer over
> eachothers shoulders, but rather than defer the hooks we bring forward
> the bridge decision.


But at that point again you can't even be sure if the packet will
finally exit a bridge device. TC action could direct the packet
to a different device from the bridge output queue. There is no
clean solution for this which integrates well with all the other
things Linux networking can do.

>>>I think if ebtables becomes the answer it will just grow to be as big as
>>>iptables with all the extra matches iptables has, just as iptables has
>>>extra -p tcp and -p udp matches.
>>>    
>>
>>Thats where MARK will be useful, but only if the target is available
>>in ebtables. SNAT based on bridge port won't be possible anymore.
>>  
> 
> Yes but the ebtables could get as big as turing machine as the possible
> ebtables actions end up getting encoded into the mark; with such side
> deferred effects as:
> * set dscp to various values
> * set mark (for tc)
> * drop
> 
> all multipled by the number of output ports, so that these actions can
> be taken based on the output port.


Worst case will need some space, but common sense tells me that this is
not what users are doing (DSCP based on bridge output port combined with
criteria only usable within iptables? What for?). Marking for tc can
be done within iptables, and ebtables just needs to encode the output
port in the mark if you really need it (why would you? you have a
seperate device, the bridge port, to do QoS on).

Anyway, I'll submit the patch soon, which gives us at least 6 more month
to work this out.