similar to: [RFC 1/2] vhost: IFC VF hardware operation layer

Displaying 20 results from an estimated 4000 matches similar to: "[RFC 1/2] vhost: IFC VF hardware operation layer"

2019 Oct 16
0
[RFC 1/2] vhost: IFC VF hardware operation layer
On 2019/10/16 ??9:30, Zhu Lingshan wrote: > This commit introduced ifcvf_base layer, which handles IFC VF NIC > hardware operations and configurations. It's better to describe the difference between ifc vf and virtio in the commit log or is there a open doc for this? > > Signed-off-by: Zhu Lingshan <lingshan.zhu at intel.com> > --- >
2019 Oct 21
0
[RFC 1/2] vhost: IFC VF hardware operation layer
On 2019/10/21 ??6:00, Zhu, Lingshan wrote: > > On 10/16/2019 4:40 PM, Jason Wang wrote: >> >> On 2019/10/16 ??9:30, Zhu Lingshan wrote: >>> This commit introduced ifcvf_base layer, which handles IFC VF NIC >>> hardware operations and configurations. >> >> >> It's better to describe the difference between ifc vf and virtio in >> the
2019 Nov 08
0
[PATCH 1/2] IFC hardware operation layer
On Tue, Nov 05, 2019 at 05:37:39PM +0800, Zhu Lingshan wrote: > This commit introduced ifcvf_base layer, which handles hardware > operations and configurations. > > Signed-off-by: Zhu Lingshan <lingshan.zhu at intel.com> > --- > drivers/vhost/ifcvf/ifcvf_base.c | 344 +++++++++++++++++++++++++++++++++++++++ > drivers/vhost/ifcvf/ifcvf_base.h | 132 +++++++++++++++ >
2019 Nov 05
1
[PATCH 1/2] IFC hardware operation layer
On Tue, Nov 05, 2019 at 05:37:39PM +0800, Zhu Lingshan wrote: > This commit introduced ifcvf_base layer, which handles hardware > operations and configurations. > > Signed-off-by: Zhu Lingshan <lingshan.zhu at intel.com> > --- > drivers/vhost/ifcvf/ifcvf_base.c | 344 +++++++++++++++++++++++++++++++++++++++ > drivers/vhost/ifcvf/ifcvf_base.h | 132 +++++++++++++++ >
2019 Nov 05
0
[PATCH 1/2] IFC hardware operation layer
On Tue, Nov 05, 2019 at 05:37:39PM +0800, Zhu Lingshan wrote: > This commit introduced ifcvf_base layer, which handles hardware > operations and configurations. > > Signed-off-by: Zhu Lingshan <lingshan.zhu at intel.com> > --- > drivers/vhost/ifcvf/ifcvf_base.c | 344 +++++++++++++++++++++++++++++++++++++++ > drivers/vhost/ifcvf/ifcvf_base.h | 132 +++++++++++++++ >
2019 Nov 06
0
[PATCH 1/2] IFC hardware operation layer
On 2019/11/5 ??5:37, Zhu Lingshan wrote: > This commit introduced ifcvf_base layer, which handles hardware > operations and configurations. It looks like the PCI layout is pretty similar to virtio. Can we reuse e.g virtio_pci_modern_probe() (or helpers in virtio_pci_modern.c) to do the probing? > > Signed-off-by: Zhu Lingshan <lingshan.zhu at intel.com> > --- >
2019 Oct 16
0
[RFC 2/2] vhost: IFC VF vdpa layer
On 2019/10/16 ??9:30, Zhu Lingshan wrote: > This commit introduced IFC VF operations for vdpa, which complys to > vhost_mdev interfaces, handles IFC VF initialization, > configuration and removal. > > Signed-off-by: Zhu Lingshan <lingshan.zhu at intel.com> > --- > drivers/vhost/ifcvf/ifcvf_main.c | 541 +++++++++++++++++++++++++++++++++++++++ > 1 file changed, 541
2019 Oct 23
0
[RFC 2/2] vhost: IFC VF vdpa layer
On 2019/10/23 ??2:19, Zhu, Lingshan wrote: > > On 10/22/2019 9:05 PM, Jason Wang wrote: >> >> On 2019/10/22 ??2:53, Zhu Lingshan wrote: >>> >>> On 10/21/2019 6:19 PM, Jason Wang wrote: >>>> >>>> On 2019/10/21 ??5:53, Zhu, Lingshan wrote: >>>>> >>>>> On 10/16/2019 6:19 PM, Jason Wang wrote:
2019 Oct 22
0
[RFC 2/2] vhost: IFC VF vdpa layer
On 2019/10/22 ??2:53, Zhu Lingshan wrote: > > On 10/21/2019 6:19 PM, Jason Wang wrote: >> >> On 2019/10/21 ??5:53, Zhu, Lingshan wrote: >>> >>> On 10/16/2019 6:19 PM, Jason Wang wrote: >>>> >>>> On 2019/10/16 ??9:30, Zhu Lingshan wrote: >>>>> This commit introduced IFC VF operations for vdpa, which complys to
2019 Oct 21
0
[RFC 2/2] vhost: IFC VF vdpa layer
On 2019/10/21 ??5:53, Zhu, Lingshan wrote: > > On 10/16/2019 6:19 PM, Jason Wang wrote: >> >> On 2019/10/16 ??9:30, Zhu Lingshan wrote: >>> This commit introduced IFC VF operations for vdpa, which complys to >>> vhost_mdev interfaces, handles IFC VF initialization, >>> configuration and removal. >>> >>> Signed-off-by: Zhu Lingshan
2019 Oct 22
0
[RFC 1/2] vhost: IFC VF hardware operation layer
On 2019/10/22 ??12:31, Simon Horman wrote: > On Mon, Oct 21, 2019 at 05:55:33PM +0800, Zhu, Lingshan wrote: >> On 10/16/2019 5:53 PM, Simon Horman wrote: >>> Hi Zhu, >>> >>> thanks for your patch. >>> >>> On Wed, Oct 16, 2019 at 09:10:40AM +0800, Zhu Lingshan wrote: > ... > >>>> +static void ifcvf_read_dev_config(struct
2019 Oct 23
0
[RFC 1/2] vhost: IFC VF hardware operation layer
On 2019/10/23 ??6:13, Simon Horman wrote: > On Tue, Oct 22, 2019 at 09:32:36AM +0800, Jason Wang wrote: >> On 2019/10/22 ??12:31, Simon Horman wrote: >>> On Mon, Oct 21, 2019 at 05:55:33PM +0800, Zhu, Lingshan wrote: >>>> On 10/16/2019 5:53 PM, Simon Horman wrote: >>>>> Hi Zhu, >>>>> >>>>> thanks for your patch.
2019 Nov 06
0
[PATCH 2/2] IFC VDPA layer
----- Original Message ----- > This commit introduced IFC operations for vdpa, which complys to > virtio_mdev and vhost_mdev interfaces, handles IFC VF > initialization, configuration and removal. > > Signed-off-by: Zhu Lingshan <lingshan.zhu at intel.com> > --- > drivers/vhost/ifcvf/ifcvf_main.c | 605 > +++++++++++++++++++++++++++++++++++++++ > 1 file changed,
2019 Oct 21
0
[RFC 1/2] vhost: IFC VF hardware operation layer
On 2019/10/21 ??5:57, Zhu, Lingshan wrote: > > On 10/16/2019 4:45 PM, Jason Wang wrote: >> >> On 2019/10/16 ??9:30, Zhu Lingshan wrote: >>> + */ >>> +#define IFCVF_TRANSPORT_F_START 28 >>> +#define IFCVF_TRANSPORT_F_END?? 34 >>> + >>> +#define IFC_SUPPORTED_FEATURES \ >>> +??????? ((1ULL << VIRTIO_NET_F_MAC)??????????? |
2019 Oct 16
0
[RFC 1/2] vhost: IFC VF hardware operation layer
On Wed, 16 Oct 2019 09:03:17 +0800 Zhu Lingshan <lingshan.zhu at intel.com> wrote: > + IFC_INFO(&dev->dev, "PCI capability mapping:\n" > + "common cfg: %p\n" > + "notify base: %p\n" > + "isr cfg: %p\n" > + "device cfg: %p\n" > + "multiplier: %u\n", > + hw->common_cfg, > +
2023 Mar 31
1
[PATCH 3/5] retire ifcvf_start_datapath and ifcvf_add_status
Rather than former lazy-initialization mechanism, now the virtqueue operations and driver_features related ops access the virtio registers directly to take immediate actions. So ifcvf_start_datapath() should retire. ifcvf_add_status() is retierd because we should not change device status by a vendor driver's decision, this driver should only set device status which is from virito drivers upon
2019 Oct 16
0
[RFC 1/2] vhost: IFC VF hardware operation layer
On 2019/10/16 ??9:30, Zhu Lingshan wrote: > + */ > +#define IFCVF_TRANSPORT_F_START 28 > +#define IFCVF_TRANSPORT_F_END 34 > + > +#define IFC_SUPPORTED_FEATURES \ > + ((1ULL << VIRTIO_NET_F_MAC) | \ > + (1ULL << VIRTIO_F_ANY_LAYOUT) | \ > + (1ULL << VIRTIO_F_VERSION_1) | \ > + (1ULL << VHOST_F_LOG_ALL) | \ Let's avoid using
2020 May 13
0
[PATCH V2] ifcvf: move IRQ request/free to status change handlers
On 2020/5/12 ??4:00, Zhu Lingshan wrote: > This commit move IRQ request and free operations from probe() > to VIRTIO status change handler to comply with VIRTIO spec. > > VIRTIO spec 1.1, section 2.1.2 Device Requirements: Device Status Field > The device MUST NOT consume buffers or send any used buffer > notifications to the driver before DRIVER_OK. This comment needs to be
2020 May 11
0
[PATCH] ifcvf: move IRQ request/free to status change handlers
On 2020/5/11 ??3:19, Zhu Lingshan wrote: > This commit move IRQ request and free operations from probe() > to VIRTIO status change handler to comply with VIRTIO spec. > > VIRTIO spec 1.1, section 2.1.2 Device Requirements: Device Status Field > The device MUST NOT consume buffers or send any used buffer > notifications to the driver before DRIVER_OK. My previous explanation
2020 May 12
1
[PATCH] ifcvf: move IRQ request/free to status change handlers
On 2020/5/11 ??6:11, Zhu, Lingshan wrote: > > > On 5/11/2020 5:26 PM, Jason Wang wrote: >> >> On 2020/5/11 ??3:19, Zhu Lingshan wrote: >>> This commit move IRQ request and free operations from probe() >>> to VIRTIO status change handler to comply with VIRTIO spec. >>> >>> VIRTIO spec 1.1, section 2.1.2 Device Requirements: Device Status