On 17 November 2016 at 10:12, Rony Efraim <[email protected]> wrote: <snip>
>> * ufid_to_handle/handle_to_ufid - I'm a little confused by these, UFID >> is supposed to uniquely identify a flow and that's what a handle does >> (at least for a particular device, right?) so at a naive first look I >> would have though that these can be statelessly translated between >> without map storage. There's a couple of different places where >> puthandle() is called so I wasn't exactly sure how the handle is determined. > [RONY] the UFID is unique but the tc use 32 bit as a handle per priority and > may not have all the fields That make unimpossible to have a direct translate. OK, I think that part of the issue is that with the OVS netlink datapath, the UFID is generated by userspace during upcall processing; whereas for the TC you have to install the flow before you get a TC handle. >> * mask_to_prio - I think this is just a cache to avoid malloc() calls? By the way, I'm also curious why you use different priorities? The code above dpif never passes down overlapping flows so there's no need to prioritize them. >> This direction might suggest that each platform can choose how to do >> its hardware offloads and we put that logic into the 'struct netdev' >> in userspace, then we don't need an additional dpif just for tc flower >> hardware offloads. This assumes that each platform comes up with one >> way to do hardware offloads. >> >> If particular platforms or implementations decide not to include a >> separate API for hardware offloads, they can always do the offloads >> transparently as they already do, and just ignore this interface. >> >> I had some discussions with Johann offline and there was some concern >> that we end up with, say, four dpifs with potentially arbitrary ordering >> between them. >> This is a lot of permutations. If the above logic makes sense, then >> the offloads is an attribute of the netdevice and not a dedicated >> dpif, so there are less possible permutations. In terms of handling >> the different possible configurations of two dpifs like shadowing or >> duplicating flows etc, this logic could exist within the hw- offload-policy >> module. > [RONY] yes, it will be simpler. And take same code to a library and reuse it > if needed. >> >> The last part would be to extend the dpif-netlink a bit so that during >> startup there is an attempt to query the hardware offload capabilities >> so that, eg, if there is no offloads available there is a simple >> switch to turn this logic off and there is minimal change for that >> path; and ideally it gathers enough information so that the typical >> offloads case doesn't involve attempting + failing to install hardware flow >> followed by installing the software flow. > [RONY] yes, we need to have a state per port, because there can be mix of > devices in the system. > We need to keep in mind that we also want to have partial offload ( like HW > classification) Then the dpif should call the HW to classify and use the flow > id in the datapath. >> >> Thoughts? > _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
