On Wed, Jun 21, 2017 at 12:00:50PM +0300, Or Gerlitz wrote: > On Tue, Jun 20, 2017 at 10:24 PM, Jakub Kicinski > <[email protected]> wrote: > > On Tue, 20 Jun 2017 19:13:43 +0300, Or Gerlitz wrote: > > >>> Control queues are used to send and receive control messages which are > >>> used to communicate configuration information with the firmware. These > >>> are in separate vNIC to the queues belonging to the PF netdev. The control > >>> queues are not exposed to use-space via a netdev or any other means. > > >> Do you have documentation for the control channel or I should look on > >> earlier commits? > > > We don't have any docs, the ctrl channel was merged in e5c5180a2302 > > ("Merge branch 'nfp-ctrl-vNIC'"). The "control channel" is essentially > > a normal data queue which is specially marked as carrying control > > messages. > > >> The control messages you describe here are also the ones that are used > >> to load/unload specific app? > > > No, the app loading, PHY port management and other low-level tasks are > > handled by management FW. The control messages are an application FW > > construct. The control messages are transported by the datapath and > > since the datapath is entirely under control of apps the management FW > > can't depend on it. The apps today also completely reload the PCIe > > datapath implementation (which is software defined), so we need to use > > raw memory mappings to communicate with management FW. > > > The control messages are mostly used for populating tables and reading > > statistics, because those two need to be fast and low overhead. > > Thanks Jakub for that clarification -- I still not sure to see the > high level picture - > will appreciate if you can make a simple text based sketch here of the > source/dest/sequence of calls/messages (say) from the time the driver is > loaded > to when sriov is set with VFs and VF reps > > The VF reps where introduced hand in hand with the devlink way to > create/destroy > them -- e.g the devlink eswitch commands (mode change, show, enable encap, > etc). > > Taking your comment that the channels are mostly used for table > population and such, > is there any real reason for you not to use devlink for applying the > configuration? you can > communicate with the FW from your devlink callbacks, isn't that?
I will leave Jakub to respond to this question. > Simon, another comment on this series/app, is that the VF reps can > apply for more > use cases beyond flower offload -- e.g FDB or FIB offloads and also > the other way > around, flower offloads can apply to more use cases beyond SRIOV, as any easy > example, you can offload native NIC RX TC rule (drop, header re-write, etc). > > Indeed your current app code doesn't have any relation to flower beyond the > name... maybe you can just make a rename and this way it will be less > confusing for you.. when coming to apply more use-cases? > > As for flower offloads being applicable beyond SRIOV, lets see if/how > you re-name/phrase the VF reps. This patchset is in two parts. The first 9 patches add code to allow representors to be instantiated etc... The remaining patches provide the beginning of a flower app which makes use of this infrastructure. So I think there is a clear separation between representor code, in .../nfp/ and app code that uses representors, in this case .../nfp/flower/. I could have supplied a test app to demonstrate using representors - and that is really what the flower app is as of this patchset. But I chose to name it flower as it we have follow-up work to make the app actually offload flower and at that point that will be come its dominant feature.
