Re: [idpf] RE: Gentle reminder for IDPF Spec review version 0.9 posted in Early Feb

["Michael S. Tsirkin" <mst@redhat.com>]

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