On Thu, Aug 30, 2018 at 7:55 PM Sunil Kovvuri [off-list ref] wrote:

On Thu, Aug 30, 2018 at 7:37 PM Arnd Bergmann [off-list ref] wrote:

quoted

On Tue, Aug 28, 2018 at 3:10 PM Sunil Kovvuri [off-list ref] wrote:
Ok, I think I understand the PF/VF distinction now. One (to me)
surprising aspect here is that you not just have one physical function
that you can use to assign resources to multiple virtual functions,
but also a second level of virtualization that is used to assign
resources to "physical functions" that are less physical than the
name suggests.

Yes, PF is just for name sake, on-boot there is no difference between
PFs/VFs as such.
PF0 has privilege access to assign resources to all PFs and their VFs.
This admin function driver loads for PF0.

ok

quoted

The part that I have not grasped yet is what the split between
the CGX and the AF is for, how they relate to one another, and
what the software abstraction for the two is going to be.

In HW, CGX is a separate PCI device which handles the serdes and
physical ethernet interface.
Ethernet driver in drivers/net/ethernet can only communicate to
admin function driver since they share a mailbox memory.
So we had to bind both CGX and admin function drivers to almost work as one,
inorder to provide relavent info to ethernet drivers. That's why we
have many functions
from CGX driver which AF uses.

eg: Firmware gets to know about a physical interface status change,
which CGX driver gets
to know and it uses AF's mailbox communication to inform ethernet
driver about the event.

Would it make sense then to combine the CGX driver and the AF
driver into a single module? It sounds like you can never really
use one without the other anyway, and that would make it easier
to have a sensible abstraction to user space.

      Arnd