Infrastructure Data-Plane Function

>From: idpf@lists.oasis-open.org <idpf@lists.oasis-open.org> On Behalf Of Singhai, Anjali >Sent: Monday, April 10, 2023 10:27 AM >To: idpf@lists.oasis-open.org; Orr, Michael <michael.orr@intel.com>; Michael S. Tsirkin <mst@redhat.com> >Subject: [EXT] [idpf] Gentle reminder for IDPF Spec review version 0.9 posted in Early Feb >External Email >________________________________________ >Hi All, >   IF you haven't had a chance to review please do and send any feedback to the group. I plan on send the next version for review by End of April/Early May. Here are the additions that we have planned for the next >review I was waiting for a tex format spec to be able to quote better. Anyway here is some feedback. I have added statements from sections as context. >From: idpf@lists.oasis-open.org <idpf@lists.oasis-open.org> On Behalf Of Singhai, Anjali >Sent: Monday, April 10, 2023 10:27 AM >To: idpf@lists.oasis-open.org; Orr, Michael <michael.orr@intel.com>; Michael S. Tsirkin <mst@redhat.com> >Subject: [EXT] [idpf] Gentle reminder for IDPF Spec review version 0.9 posted in Early Feb >External Email >________________________________________ >Hi All, > IF you haven't had a chance to review please do and send any feedback to the group. I plan on send the next version for review by End of April/Early May. Here are the additions that we have planned for the next >review I was waiting for a tex format spec to be able to quote better. Anyway here is some feedback. I have added statements from sections as context. Section: Vport "When a vPort is a group of DMA queues, there is a host side load balancer or classifier implemented in the Device/SW Data path past the vSwitch to pick one of the queues of the vPort for final delivery of the packet." Does this load balancer mean RSS? Does SW Data Path mean implementation of data path in an emulated IDPF device? "These Descriptor queues are often used in pairs, with one queue used in the Host-to-Device direction, and the other in Device-To-Host direction". Does the spec mandate usage in pairs? Or can tx/rx queue counts be asymmetric? Section: Mailbox "A typical implementation uses a specific agreed-upon pair of Descriptor queues to pass back and forth Commands from the driver to the Control-plane of the Device and responses and event notifications from the Device control-plane to the driver" Can the same queues be also used for data? Or they are exclusive for mailbox? "Typically, this out-of-band communication is assumed to be not very chatty and can be implemented as a low throughput mechanism." How are flow offload rules (tc/RTE_FLOW etc) implemented? Do they use some other path? These days there are requirements for higher insertion/deletion rates. Section: BARs Doesn't IDPF device support expansion ROM bar ? Section: PCI express Nothing was mentioned about class code and subclass code. But I have seen a ballot for registering a programming interface with PCISIG. So I assume this will be eventually added Section: Registers "Note : When the driver writes a device register and then reads that same register the device might return the old register value (value before the register write) unless the driver keeps 2 ms latency between the write access and the read accesses." This does not seem to be compliant with PCIe ordering Specification. PCIe specification requires that read requests cannot pass posted writes irrespective of latency. Section: Out of order split queue model "In this model, descriptor completions can be reported "out of order" - not according to the descriptor placement order in the buffer queue." Out of order and split queue are 2 different features. Is it not possible to have a in order split queue, where rx completion is received in one queue and rx buffers are received in another queue but are to be posted in order that they were received? Section: Rx descriptor LPBK field "Loop back indication which means that the packet originated from this system rather than the network" How is this field supposed to be used by host driver? Is a VF to VF switched packet considered loopback? Section: Rx descriptor PKTL and HDRL field "PKTL - Packet content length in the packet buffer defined in byte units. HDRL - Bits 0:9 - Packet content length in the header buffer defined in byte units. Bit 10 reserved." So Max packet length can only be 16K bytes ? In case the packet length is more than 16K, (maximum size of IP packet is 64K) how is it represented? Section: Capability and Offload Negotiation Max_sriov_vfs: "The PF sends the maximum VFs it is requesting. The CP responds with the maximum VFs granted CP responds with max_num_vfs set to min (n, x) where x is the max number of VFs allowed by CP's policy. max_sriov_vfs is not applicable for VFs." This seems to be subverting the PCIe SRIOV specification. A PCIe PF function is supposed to honor the numbers declared in sriov extended capability (total_vfs and Initial_vfs). What is the significance of the values provided by SRIOV capability if the CP and Host PF driver can negotiate later ? Does the capability change based on these values and host is required to rescan ? Section: Function Level Reset "When the driver is unloading, it triggers Function Level Reset (FLR/XLR) according to the type of the function it is working on (Physical Function Reset (PFR) or Virtual function reset (VFR)) to clean all its pending transactions and release its owned resources" What does XLR stand for? Regards Satananda

On Tue, May 23, 2023 at 01:30:04AM +0000, Satananda Burla wrote: > > >From: idpf@lists.oasis-open.org <idpf@lists.oasis-open.org> On Behalf Of Singhai, Anjali > >Sent: Monday, April 10, 2023 10:27 AM > >To: idpf@lists.oasis-open.org; Orr, Michael <michael.orr@intel.com>; Michael S. Tsirkin <mst@redhat.com> > >Subject: [EXT] [idpf] Gentle reminder for IDPF Spec review version 0.9 posted in Early Feb > > >External Email > >________________________________________ > >Hi All, > >   IF you haven't had a chance to review please do and send any feedback to the group. I plan on send the next version for review by End of April/Early May. Here are the additions that we have planned for the next >review > I was waiting for a tex format spec to be able to quote better. Anyway here is some feedback. I have added statements from sections as context. > >From: idpf@lists.oasis-open.org <idpf@lists.oasis-open.org> On Behalf Of Singhai, Anjali > >Sent: Monday, April 10, 2023 10:27 AM > >To: idpf@lists.oasis-open.org; Orr, Michael <michael.orr@intel.com>; Michael S. Tsirkin <mst@redhat.com> > >Subject: [EXT] [idpf] Gentle reminder for IDPF Spec review version 0.9 posted in Early Feb > > >External Email > >________________________________________ > >Hi All, > > IF you haven't had a chance to review please do and send any feedback to the group. I plan on send the next version for review by End of April/Early May. Here are the additions that we have planned for the next >review > I was waiting for a tex format spec to be able to quote better. Anyway here is > some feedback. I have added statements from sections as context. > > Section: Vport "When a vPort is a group of DMA queues, there is a host side load > balancer or classifier implemented in the Device/SW Data path past the vSwitch > to pick one of the queues of the vPort for final delivery of the packet." > Does this load balancer mean RSS? Does SW Data Path mean implementation of data > path in an emulated IDPF device? > > "These Descriptor queues are often used in pairs, with one queue used in the > Host-to-Device direction, and the other in Device-To-Host direction". > Does the spec mandate usage in pairs? Or can tx/rx queue counts be asymmetric? > > Section: Mailbox "A typical implementation uses a specific agreed-upon pair of > Descriptor queues to pass back and forth Commands from the driver to the > Control-plane of the Device and responses and event notifications from the > Device control-plane to the driver" > Can the same queues be also used for data? Or they are exclusive for mailbox? > > "Typically, this out-of-band communication is assumed to be not very chatty and > can be implemented as a low throughput mechanism." > How are flow offload rules (tc/RTE_FLOW etc) implemented? Do they use some other > path? These days there are requirements for higher insertion/deletion rates. > > Section: BARs > Doesn't IDPF device support expansion ROM bar ? > > Section: PCI express > Nothing was mentioned about class code and subclass code. But I have > seen a ballot for registering a programming interface with PCISIG. So I assume > this will be eventually added > > Section: Registers > "Note : When the driver writes a device register and then > reads that same register the device might return the old register value (value > before the register write) unless the driver keeps 2 ms latency between the > write access and the read accesses." > This does not seem to be compliant with PCIe ordering Specification. PCIe specification > requires that read requests cannot pass posted writes irrespective of latency. > > Section: Out of order split queue model > "In this model, descriptor completions can be reported "out of order" - not according > to the descriptor placement order in the buffer queue." > Out of order and split queue are 2 different features. Is it not possible to have > a in order split queue, where rx completion is received in one queue and rx buffers are > received in another queue but are to be posted in order that they were received? > > Section: Rx descriptor LPBK field > "Loop back indication which means that the > packet originated from this system rather than the network" > How is this field supposed to be used by host driver? Is a VF to VF switched > packet considered loopback? > > Section: Rx descriptor > PKTL and HDRL field > "PKTL - Packet content length in the packet buffer defined in byte units. > HDRL - Bits 0:9 - Packet content length in the header buffer defined in byte units. > Bit 10 reserved." > So Max packet length can only be 16K bytes ? In case the packet length is more > than 16K, (maximum size of IP packet is 64K) how is it represented? Support for IPv6 Jumbograms might also be of interest. > Section: Capability and Offload Negotiation > Max_sriov_vfs: "The PF sends the maximum VFs it is requesting. The CP responds > with the maximum VFs granted CP responds with max_num_vfs set to min (n, x) > where x is the max number of VFs allowed by CP's policy. max_sriov_vfs is not > applicable for VFs." > This seems to be subverting the PCIe SRIOV specification. A PCIe PF function is > supposed to honor the numbers declared in sriov extended capability (total_vfs > and Initial_vfs). What is the significance of the values provided by SRIOV > capability if the CP and Host PF driver can negotiate later ? Does the > capability change based on these values and host is required to rescan ? > > Section: Function Level Reset > "When the driver is unloading, it triggers Function Level Reset (FLR/XLR) according > to the type of the function it is working on (Physical Function Reset (PFR) or > Virtual function reset (VFR)) to clean all its pending transactions and release its > owned resources" > What does XLR stand for? > > Regards > Satananda > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php