On 24/09/2019 12:48, Paul Blakey wrote: > The 'miss' for all or nothing is easy, but the hard part is combining > all the paths a packet can take in software to a single 'all or nothing' > rule in hardware. But you don't combine them to a single rule in hardware, because you have multiple sequential tables. (I just spent the last few weeks telling our hardware guys that no, they can't just give us one big table and expect the driver to do all that combining, because as you say, it's 'the hard part'.)
> What if you 'miss' on the match for the tuple? You already did some > processing in hardware, so either you revert those, or you continue in > software where you left off (the action ct). But the only processing you did was to match stuff and generate metadata in the form of lookup keys (e.g. a ct_zone) for the next round of matching. There's nothing to "revert" unless you've actually modified the packet before sending it to CT, and as I said I don't believe that's worth supporting. > The all or nothing approach will require changing the software model to > allow > > merging the ct zone table matches into the hardware rules I don't know how much more clearly I can say this: all-or-nothing does not require merging. It just requires any actions that come before a matching stage (and that the hw doesn't have the capability to revert) to put a rule straight in the 'nothing' bucket. So if you write chain 0 dst_mac aa:bb:cc:dd:ee:ff ct_state -trk action vlan push blah action ct action goto chain X the driver can say -EOPNOTSUPP because you pushed a VLAN and might still miss in chain X. But if you write chain 0 dst_mac aa:bb:cc:dd:ee:ff ct_state -trk action ct action goto chain X then the driver will happily offload that because if you miss in the later lookups you've not altered the packet — the chain0-rule is *idempotent* so it doesn't matter if HW and SW both perform it. (Or even all three of HW, tc and OvS.)
