On Mon, Oct 27, 2025 at 08:57:31AM -0400, Aaron Conole wrote: > Adrián Moreno <[email protected]> writes: > > > On Tue, Sep 30, 2025 at 12:46:58PM -0400, Aaron Conole wrote: > >> This commit wires up support for the socket() action, which will > >> create a recirculation on the datapath to bypass as many extra > >> recirculations as possible before the output. The rough idea is > >> that a data packet can 'bypass' certain parts of the networking > >> stack and experience a faster delivery. This makes some of the > >> tracking features (for example, simple tcpdump type operations) > >> much more complicated because the underlying datapath will not > >> use the complete routing / sockets layer in datapath, but it > >> instead directly will queue the data portion of the packet to > >> the socket buffer. For non-data packets, the socket() action > >> will hit the 'else' directive and take the recirc chain. > >> > >> One area that still needs enhancement is the ct() path. The > >> conntrack portions are only doing the socket call after the > >> recirculation chain. However, the proper way to do this is > >> to rewrite the original recirculation state to hit the socket > >> path first. That will require quite a bit more context and > >> logic in the compose ct action, so it isn't done here, and > >> it isn't recommended to use this with a really complex flow > >> pipeline yet (since this is still a WIP). Future work will > >> focus on this area so that an existing flow after freezing > >> that looks like: > >> > >> recirc_id(0),eth(...),eth_type(...),ipv4(...), > >> actions=ct(commit,nat(dst=1.2.3.4)),recirc(0x1) > >> > >> would be rewritten as: > >> > >> recirc_id(0),eth(...),eth_type(...),ipv4(...),... > >> actions=socket(netns=...,inode=...,else(recirc(1)) > >> recirc_id(0x1),eth(...)... > >> actions=ct(commit,nat(dst=1.2.3.4)),recirc(0x2) > > > > How would that be done? IIUC the first flow could be shared between > > multiple connections. > > Do you mean that we are going from: > > recirc_id(0),eth(...),eth_type(...)... actions=ct() > > to a more restrictive matching flow? Yes, that's what will happen. But > I don't know of a better way to do that without managing extra state in > the datapath. Do you think it would be a problem? >
IIUC, the resulting flow must match on the connection 5-tuple. So if it has more generic (say L2-only) match that is reused for N different connections, the rewrite is not just a flow edit, it has to be a deletion and N insertions. And that is considerably more complex, right? I don't have a good alternative that doesn't make the action more opaque (e.g. encoding all the possible sockets in a single action such as sock(hash1=netns1/inode1,hash2=netns2/inode2)), or going back to the sock(try) approach. Thanks. Adrián _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
