21/09/2022 04:02, Chaoyong He:
> > On 9/15/2022 11:44 AM, Chaoyong He wrote:
> > > Adds the setup/start logic for the ctrl vNIC. This vNIC is used by the
> > > PMD and flower firmware application as a communication channel
> > between
> > > driver and firmware. In the case of OVS it is also used to communicate
> > > flow statistics from hardware to the driver.
> > >
> > > A rte_eth device is not exposed to DPDK for this vNIC as it is
> > > strictly used internally by flower logic.
> > >
> > 
> > Hi Chaoyong,
> > 
> > Similar comment with previous versions, interface is created using regular
> > 'rte_eth_dev_allocate()' API, I think interface will be visible to 
> > application, I
> > can't understand the need of creating an interface for control.

You didn't reply to this.
Why the control port should be exposed to the application?
We recommend not using ethdev for this.


> > What is the communication method between driver and FW?
> > Since one of the following patches (09/12) introduces Rx/Tx for ctrl 
> > interface,
> > is device interface is control packets (similar to network data packets)?
> > 
> 
> Basically, the 'control message' is exist in the form of normal data packets.
> 
> When we use the flower firmware application, there exist two types of packets 
> for now,
> and they are identified only from the prepend meta-data.
> 
> Bit    3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0
> -----\ 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
> Word  +---------------+---------------+---------------+---------------+
>    0  |    type       |     type      |     type      |     type      |
>       +---------------+---------------+---------------+---------------+
> The 'control message' packets are processed by the ctrl vNIC.
> The 'normal' packets are processed by the pf vNIC.
> 
> The communication method between driver and firmware is decided by the
> designment of hardware and firmware.
> 
> The kernel driver also has the same ctrl vNIC and pf vNIC ethdev and the 
> usage is same.
> 
> > > Because of the add of ctrl vNIC, a new PCItoCPPBar is needed. Modify
> > > the related logics.
> > >
> > > Signed-off-by: Chaoyong He <chaoyong...@corigine.com>
> > > Reviewed-by: Niklas Söderlund <niklas.soderl...@corigine.com>



Reply via email to