[dpdk-dev] [PATCH v3 00/15] Introduce SoC device/driver framework for EAL
On 18 September 2016 at 15:22, Jan Viktorin wrote: > On Sun, 18 Sep 2016 13:58:50 +0800 > Jianbo Liu wrote: > >> On 9 September 2016 at 16:43, Shreyansh Jain >> wrote: >> > Introduction: >> > = >> > >> > This patch set is direct derivative of Jan's original series [1],[2]. >> > >> > - As this deviates substantially from original series, if need be I can >> >post it as a separate patch rather than v2. Please suggest. >> > - Also, there are comments on original v1 ([4]) which are _not_ >> >incorporated in this series as they refer to section no more in new >> >version. >> > - This v3 version is based on the rte_driver/device patchset v9 [10]. >> >That series introduced device structures (rte_driver/rte_device) >> >generalizing devices into PCI, VDEV, XXX. For the purpose of this >> >patchset, XXX=>SOC. > > [...] > >> > >> > 5) Design considerations that are different from PCI: >> > - Each driver implements its own scan and match function. PCI uses the BDF >> >format to read the device from sysfs, but this _may_not_ be a case for a >> >SoC ethernet device. >> >= This is an important change from initial proposal by Jan in [2]. >> > Unlike >> >his attempt to use /sys/bus/platform, this patch relies on the PMD to >> >> It could be many redundant code if Each PMD driver has the scan >> function if its own. >> I think Jan's implementation is common to many platform drivers. > > I personally can find a use case for having a custom scan function. > However, we should at least provide a default implementation. Probably, > both the scan and match functions should be used to _override_ a default > behaviour. So, only drivers that require to scan devices in a specific > way would provide a custom function for this. > And for each platform/product > I agree, that this can sometimes lead to code duplication. Moreover, it > opens door for a very non-standard, unsecure and wrong-by-design > approaches. I'd like more to provide one or more scan implementations > in EAL and do not put this responsibility on PMDs. > >> >> >detect the devices. This is because SoC may require specific or >> >additional info for device detection. Further, SoC may have embedded > > Can you provide an example for "additional info for device detection"? > >> >> Can you give us more precise definition about SoC driver? Does it >> include the driver in ARM server? > > I am sorry but I don't understand this question. > > What you mean by a "driver in ARM server"? Do you mean a kernel driver? > > There is no "SoC driver" in the text so what definition are asking for? > This patchset introduces rte_soc_driver, which is inheriting from rte_driver. I want to know what devices can use this SoC driver/device framework. Is it for the devices from ARM servers, or embedded systems of different vendors? And this framework is too generalized, if we don't try to understand "soc" in rte_soc_driver, we can use it for PCI devices. :) Thanks! Jianbo
[dpdk-dev] [PATCH] net/vhost: Add function to retreive the 'vid' for a given port id
On Wed, Sep 14, 2016 at 10:35:53AM +0200, Thomas Monjalon wrote: > 2016-09-14 15:21, Yuanhan Liu: > > On Wed, Sep 14, 2016 at 09:10:48AM +0200, Thomas Monjalon wrote: > > > 2016-09-14 12:43, Yuanhan Liu: > > > > On Tue, Sep 13, 2016 at 05:10:09PM +0200, Thomas Monjalon wrote: > > > > > 2016-09-13 14:47, Ciara Loftus: > > > > > > In some cases when using the vHost PMD, certain vHost library > > > > > > functions > > > > > > may still need to be accessed. One such example is the > > > > > > rte_vhost_get_queue_num function which returns the number of > > > > > > virtqueues > > > > > > reported by the guest - information which is not exposed by the PMD. > > > > > > > > > > > > This commit introduces a new rte_eth_vhost function that returns the > > > > > > 'vid' associated with a given port id. This allows the PMD user to > > > > > > call > > > > > > vHost library functions which require the 'vid' value. > > > > > > > > > > I think we should not add any API to the PMDs. > > > > > > > > In general, I agree with you. > > > > > > > > > Maybe you are looking for a generic API in ethdev. > > > > > > > > But maybe it's a bit hard to define a "right" generic API here. For this > > > > case, the generic API I can think of could be: > > > > > > > > - an API to get queue num, like rte_eth_get_queue_enabled_num > > > > I barely know NIC pmd drivers, but I doubt it's useful/meaningful for > > > > them. > > > > > > > > - an API to get a PMD driver private (or specific) data. > > > > For vhost-pmd, it's vid. Again, I don't know what it could be for > > > > other nic > > > > drivers. > > > > > > > > This one may be a better option here, because it expose a key field to > > > > the application, vid, with which the application can invoke more vhost > > > > APIs. And apparently, it's not feasible to try to define a generic API > > > > for some (if not each) vhost APIs. > > > > > > There could be a similar need in other PMD. > > > If we can get an opaque identifier of the device which is not the port id, > > > we could call some specific functions of the driver not implemented in > > > the generic ethdev API. > > > > That means you have to add/export the PMD API first. Isn't it against what > > you are proposing -- "I think we should not add any API to the PMDs" ;) > > Yes you are totally right :) > Except that in vhost case, we would not have any API in the PMD. > But it would allow to have some specific API in other PMDs for the features > which do not fit in a generic API. So, does that mean you are okay with this patch now? I mean, okay to introduce a vhost PMD API? --yliu > Just a thought, not sure yet.
[dpdk-dev] [PATCH] crypto/qat: fix memzone creation to use a fixed size string
On Wed, Sep 14, 2016 at 04:32:46PM +0100, John Griffin wrote: > Hi Liu, > Comments embedded. > > Rgds, > John. > > On 05/09/16 04:23, Yuanhan Liu wrote: > >On Thu, Sep 01, 2016 at 11:21:38AM +0100, John Griffin wrote: > >>Remove the dependency on dev->driver->pci_drv.name when > >>creating the memzone for the qat hardware queues. > >>The pci_drv.name may grow too large for RTE_MEMZONE_NAMESIZE. > > > >Will the "may grow too large" cause any issues? If so, state it here. If > >not, marking this patch as a "fix" patch doesn't make sense to me then. > We discovered this when applying a future patch (2141c21966) and it exposed > this issue. > Problem is we create a memzone per hardware queue pair and if the memzone > name is too large, then this code will not produce a unique > name and two qps will end using the same memzone. Thanks for the info, and I think you should put it in the commit log: it helps people to really know what might go wrong without this fix. --yliu
[dpdk-dev] [PATCH v3 00/15] Introduce SoC device/driver framework for EAL
On 9 September 2016 at 16:43, Shreyansh Jain wrote: > Introduction: > = > > This patch set is direct derivative of Jan's original series [1],[2]. > > - As this deviates substantially from original series, if need be I can >post it as a separate patch rather than v2. Please suggest. > - Also, there are comments on original v1 ([4]) which are _not_ >incorporated in this series as they refer to section no more in new >version. > - This v3 version is based on the rte_driver/device patchset v9 [10]. >That series introduced device structures (rte_driver/rte_device) >generalizing devices into PCI, VDEV, XXX. For the purpose of this >patchset, XXX=>SOC. > > Aim: > > > As of now EAL is primarly focused on PCI initialization/probing. > > rte_eal_init() > |- rte_eal_pci_init(): Find PCI devices from sysfs > |- ... > |- rte_eal_memzone_init() > |- ... > `- rte_eal_pci_probe(): Driver<=>Device initialization > > This patchset introduces SoC framework which would enable SoC drivers and > drivers to be plugged into EAL, very similar to how PCI drivers/devices are > done today. > > This is a stripped down version of PCI framework which allows the SoC PMDs > to implement their own routines for detecting devices and linking devices to > drivers. > > 1) Changes to EAL > rte_eal_init() > |- rte_eal_pci_init(): Find PCI devices from sysfs > |- rte_eal_soc_init(): Calls PMDs->scan_fn > |- ... > |- rte_eal_memzone_init() > |- ... > |- rte_eal_pci_probe(): Driver<=>Device initialization, PMD->devinit() > `- rte_eal_soc_probe(): Calls PMDs->match_fn and PMDs->devinit(); > > 2) New device/driver structures: > - rte_soc_driver (inheriting rte_driver) > - rte_soc_device (inheriting rte_device) > - rte_eth_dev and eth_driver embedded rte_soc_device and rte_soc_driver, > respectively. > > 3) The SoC PMDs need to: > - define rte_soc_driver with necessary scan and match callbacks > - Register themselves using DRIVER_REGISTER_SOC() > - Implement respective bus scanning in the scan callbacks to add necessary >devices to SoC device list > - Implement necessary eth_dev_init/uninint for ethernet instances > > 4) Design considerations that are same as PCI: > - SoC initialization is being done through rte_eal_init(), just after PCI >initialization is done. > - As in case of PCI, probe is done after rte_eal_pci_probe() to link the >devices detected with the drivers registered. > - Device attach/detach functions are available and have been designed on >the lines of PCI framework. > - PMDs register using DRIVER_REGISTER_SOC, very similar to >DRIVER_REGISTER_PCI for PCI devices. > - Linked list of SoC driver and devices exists independent of the other >driver/device list, but inheriting rte_driver/rte_driver, these are also >part of a global list. > > 5) Design considerations that are different from PCI: > - Each driver implements its own scan and match function. PCI uses the BDF >format to read the device from sysfs, but this _may_not_ be a case for a >SoC ethernet device. >= This is an important change from initial proposal by Jan in [2]. Unlike >his attempt to use /sys/bus/platform, this patch relies on the PMD to It could be many redundant code if Each PMD driver has the scan function if its own. I think Jan's implementation is common to many platform drivers. >detect the devices. This is because SoC may require specific or >additional info for device detection. Further, SoC may have embedded Can you give us more precise definition about SoC driver? Does it include the driver in ARM server? >devices/MACs which require initialization which cannot be covered through >sysfs parsing. I think it can be done in devinit, not in scan function. devinit can be different for each driver. >= PCI based PMDs rely on EAL's capability to detect devices. This >proposal puts the onus on PMD to detect devices, add to soc_device_list >and wait for Probe. Matching, of device<=>driver is again PMD's callback. >
[dpdk-dev] [PATCH v3 00/15] Introduce SoC device/driver framework for EAL
On Sun, 18 Sep 2016 09:41:55 + Hemant Agrawal wrote: > > -Original Message- > > From: Jan Viktorin [mailto:viktorin at rehivetech.com] > [...] > > > And for each platform/product > > > > > > > I agree, that this can sometimes lead to code duplication. Moreover, > > > > it opens door for a very non-standard, unsecure and wrong-by-design > > > > approaches. I'd like more to provide one or more scan > > > > implementations in EAL and do not put this responsibility on PMDs. > Hi Hemant. > [Hemant] A common/default scan function can be added, provided at least one > or more PMD driver support it. > w.r.t Jan's original scan function, it was not suitable for any of the NXP > SoC's whether ARM or PowerPC. > > Unable to validate the Jan's scan function on a real platform, we have > skipped it for next phase. > Addition of a default scan function can only be done in next phase, when we > find a suitable SoC PMD driver supporting it. Quite frankly, the situation is same for me. I still have no clue about your approach which seems to be pretty non-standard. I have no way how to test it. My approach can be tested on any Linux machine with platform devices and device-tree enabled. You would see that I detect those devices (I don't mean any certain network device, I mean all platform devices) and if you provide a driver with a proper compatible string it will be set for you. I presume that I don't have any upstreamable PMD for this at the moment.
[dpdk-dev] [PATCH v3 00/15] Introduce SoC device/driver framework for EAL
On Sun, 18 Sep 2016 16:56:54 +0800 Jianbo Liu wrote: > On 18 September 2016 at 15:22, Jan Viktorin > wrote: > > On Sun, 18 Sep 2016 13:58:50 +0800 > > Jianbo Liu wrote: > > > >> On 9 September 2016 at 16:43, Shreyansh Jain > >> wrote: > >> > Introduction: > >> > = > >> > > >> > This patch set is direct derivative of Jan's original series [1],[2]. > >> > > >> > - As this deviates substantially from original series, if need be I can > >> >post it as a separate patch rather than v2. Please suggest. > >> > - Also, there are comments on original v1 ([4]) which are _not_ > >> >incorporated in this series as they refer to section no more in new > >> >version. > >> > - This v3 version is based on the rte_driver/device patchset v9 [10]. > >> >That series introduced device structures (rte_driver/rte_device) > >> >generalizing devices into PCI, VDEV, XXX. For the purpose of this > >> >patchset, XXX=>SOC. > > > > [...] > > > >> > > >> > 5) Design considerations that are different from PCI: > >> > - Each driver implements its own scan and match function. PCI uses the > >> > BDF > >> >format to read the device from sysfs, but this _may_not_ be a case > >> > for a > >> >SoC ethernet device. > >> >= This is an important change from initial proposal by Jan in [2]. > >> > Unlike > >> >his attempt to use /sys/bus/platform, this patch relies on the PMD to > >> > > >> > >> It could be many redundant code if Each PMD driver has the scan > >> function if its own. > >> I think Jan's implementation is common to many platform drivers. > > > > I personally can find a use case for having a custom scan function. > > However, we should at least provide a default implementation. Probably, > > both the scan and match functions should be used to _override_ a default > > behaviour. So, only drivers that require to scan devices in a specific > > way would provide a custom function for this. > > > And for each platform/product > > > I agree, that this can sometimes lead to code duplication. Moreover, it > > opens door for a very non-standard, unsecure and wrong-by-design > > approaches. I'd like more to provide one or more scan implementations > > in EAL and do not put this responsibility on PMDs. > > > >> > >> >detect the devices. This is because SoC may require specific or > >> >additional info for device detection. Further, SoC may have embedded > > > > Can you provide an example for "additional info for device detection"? > > > >> > >> Can you give us more precise definition about SoC driver? Does it > >> include the driver in ARM server? > > > > I am sorry but I don't understand this question. > > > > What you mean by a "driver in ARM server"? Do you mean a kernel driver? > > > > There is no "SoC driver" in the text so what definition are asking for? > > > This patchset introduces rte_soc_driver, which is inheriting from rte_driver. > I want to know what devices can use this SoC driver/device framework. > Is it for the devices from ARM servers, or embedded systems of > different vendors? First, this is not an ARM-specific feature. Consider any MAC connected to the processor via some on-chip bus. In the world of ARM, it is usually a kind of AMBA bus. I think, the Intel Xeon with FPGA would be a good non-ARM example. Here they provide the Quick Path bus (but I don't know the details). So, you cannot access such device as PCI. It is usually not possible to distinguish the bus type easily (Linux calls this a platform device). So, an rte_soc_device denotes a device integrated on the chip (SoC, System-on-Chip). Such devices can have a lower access latency because they are closer to the processor. So, if you have a server system driver by a SoC with integrated MACs (no PCI-E involved), there is no way how to access them from DPDK. An rte_soc_device represents such devices and provides a way how to access them from DPDK. That is the goal... You can have an embedded device (router, switch, monitoring device, NAT, firewall, anything in a "small box" with high throughput demands) that perfectly fits into this SoC framework because it would be usually based on some SoC (ARM, ARM64, ...). > And this framework is too generalized, if we don't try to understand > "soc" in rte_soc_driver, we can use it for PCI devices. :) No, you cannot use it for PCI devices, don't worry. There should be no PCI facilities like access to BARs :). But, I think I got your point. It seems to be generalized because there is no real standard in this area. Any vendor of SoC can provide her custom on-chip bus. The original idea was to build on top of the platform_device from Linux which hides this information from you (unless there is some bus-specific DMA which we must handle in the DPDK PMD). We could provide an rte_amba_device instead but there is no advantage in this. The amba bus is defined on the RTL level and not on the software level (no BARs, no device
[dpdk-dev] [PATCH v5 5/6] vhost: batch update used ring
On Thu, Sep 15, 2016 at 06:38:06PM +0200, Maxime Coquelin wrote:
> >>>+static inline void __attribute__((always_inline))
> >>>+flush_used_ring(struct virtio_net *dev, struct vhost_virtqueue *vq,
> >>>+ uint32_t used_idx_start)
> >>>+{
> >>>+ if (used_idx_start + vq->shadow_used_idx < vq->size) {
> >>>+ rte_memcpy(>used->ring[used_idx_start],
> >>>+ >shadow_used_ring[0],
> >>>+ vq->shadow_used_idx *
> >>>+ sizeof(struct vring_used_elem));
> >>>+ vhost_log_used_vring(dev, vq,
> >>>+ offsetof(struct vring_used,
> >>>+ ring[used_idx_start]),
> >>>+ vq->shadow_used_idx *
> >>>+ sizeof(struct vring_used_elem));
> >>>+ } else {
> >>>+ uint32_t part_1 = vq->size - used_idx_start;
> >>>+ uint32_t part_2 = vq->shadow_used_idx - part_1;
> >>>+
> >>>+ rte_memcpy(>used->ring[used_idx_start],
> >>>+ >shadow_used_ring[0],
> >>>+ part_1 *
> >>>+ sizeof(struct vring_used_elem));
> >>>+ vhost_log_used_vring(dev, vq,
> >>>+ offsetof(struct vring_used,
> >>>+ ring[used_idx_start]),
> >>>+ part_1 *
> >>>+ sizeof(struct vring_used_elem));
> >>>+ rte_memcpy(>used->ring[0],
> >>>+ >shadow_used_ring[part_1],
> >>>+ part_2 *
> >>>+ sizeof(struct vring_used_elem));
> >>>+ vhost_log_used_vring(dev, vq,
> >>>+ offsetof(struct vring_used,
> >>>+ ring[0]),
> >>>+ part_2 *
> >>>+ sizeof(struct vring_used_elem));
> >>>+ }
> >>> }
> >>Is expanding the code done for performance purpose?
> >
> >Hi Maxime,
> >
> >Yes theoretically this has the least branch number.
> >And I think the logic is simpler this way.
> Ok, in that case, maybe you could create a function to
> do the rte_memcpy and the vhost_log_used on a given range.
Agreed, that will be better; it could avoid repeating similar code
block 3 times.
> I don't have a strong opinion on this, if Yuanhan is fine
> with current code, that's ok for me.
>From what I know, that's kind of DPDK prefered way, to expand code
when necessary. For example, 9ec201f5d6e7 ("mbuf: provide bulk
allocation").
So I'm fine with it.
--yliu
[dpdk-dev] [PATCH v3 00/15] Introduce SoC device/driver framework for EAL
> -Original Message- > From: Jan Viktorin [mailto:viktorin at rehivetech.com] > On Sun, 18 Sep 2016 16:56:54 +0800 > Jianbo Liu wrote: > > > On 18 September 2016 at 15:22, Jan Viktorin > wrote: > > > On Sun, 18 Sep 2016 13:58:50 +0800 > > > Jianbo Liu wrote: > > > > > >> On 9 September 2016 at 16:43, Shreyansh Jain > wrote: > > >> > Introduction: > > >> > = > > >> > > > >> > This patch set is direct derivative of Jan's original series [1],[2]. > > >> > > > >> > - As this deviates substantially from original series, if need be I > > >> > can > > >> >post it as a separate patch rather than v2. Please suggest. > > >> > - Also, there are comments on original v1 ([4]) which are _not_ > > >> >incorporated in this series as they refer to section no more in new > > >> >version. > > >> > - This v3 version is based on the rte_driver/device patchset v9 [10]. > > >> >That series introduced device structures (rte_driver/rte_device) > > >> >generalizing devices into PCI, VDEV, XXX. For the purpose of this > > >> >patchset, XXX=>SOC. > > > > > > [...] > > > > > >> > > > >> > 5) Design considerations that are different from PCI: > > >> > - Each driver implements its own scan and match function. PCI uses the > BDF > > >> >format to read the device from sysfs, but this _may_not_ be a case > > >> > for a > > >> >SoC ethernet device. > > >> >= This is an important change from initial proposal by Jan in [2]. > > >> > Unlike > > >> >his attempt to use /sys/bus/platform, this patch relies on the > > >> > PMD to > > >> > > >> It could be many redundant code if Each PMD driver has the scan > > >> function if its own. > > >> I think Jan's implementation is common to many platform drivers. > > > > > > I personally can find a use case for having a custom scan function. > > > However, we should at least provide a default implementation. > > > Probably, both the scan and match functions should be used to > > > _override_ a default behaviour. So, only drivers that require to > > > scan devices in a specific way would provide a custom function for this. > > > > > And for each platform/product > > > > > I agree, that this can sometimes lead to code duplication. Moreover, > > > it opens door for a very non-standard, unsecure and wrong-by-design > > > approaches. I'd like more to provide one or more scan > > > implementations in EAL and do not put this responsibility on PMDs. [Hemant] A common/default scan function can be added, provided at least one or more PMD driver support it. w.r.t Jan's original scan function, it was not suitable for any of the NXP SoC's whether ARM or PowerPC. Unable to validate the Jan's scan function on a real platform, we have skipped it for next phase. Addition of a default scan function can only be done in next phase, when we find a suitable SoC PMD driver supporting it. > > > > > >> > > >> >detect the devices. This is because SoC may require specific or > > >> >additional info for device detection. Further, SoC may have > > >> > embedded > > > > > > Can you provide an example for "additional info for device detection"? > > > > > >> > > >> Can you give us more precise definition about SoC driver? Does it > > >> include the driver in ARM server? > > > > > > I am sorry but I don't understand this question. > > > > > > What you mean by a "driver in ARM server"? Do you mean a kernel driver? > > > > > > There is no "SoC driver" in the text so what definition are asking for? > > > > > This patchset introduces rte_soc_driver, which is inheriting from > > rte_driver. > > I want to know what devices can use this SoC driver/device framework. > > Is it for the devices from ARM servers, or embedded systems of > > different vendors? > > First, this is not an ARM-specific feature. Consider any MAC connected to the > processor via some on-chip bus. In the world of ARM, it is usually a kind of > AMBA bus. I think, the Intel Xeon with FPGA would be a good non-ARM example. > Here they provide the Quick Path bus (but I don't know the details). So, you > cannot access such device as PCI. It is usually not possible to distinguish > the bus > type easily (Linux calls this a platform device). > > So, an rte_soc_device denotes a device integrated on the chip (SoC, System-on- > Chip). Such devices can have a lower access latency because they are closer to > the processor. > > So, if you have a server system driver by a SoC with integrated MACs (no PCI-E > involved), there is no way how to access them from DPDK. An rte_soc_device > represents such devices and provides a way how to access them from DPDK. > That is the goal... > > You can have an embedded device (router, switch, monitoring device, NAT, > firewall, anything in a "small box" with high throughput demands) that > perfectly > fits into this SoC framework because it would be usually based on some SoC > (ARM, ARM64, ...). > > > And this framework is too generalized, if we
[dpdk-dev] [PATCH v3 00/15] Introduce SoC device/driver framework for EAL
On Sun, 18 Sep 2016 13:58:50 +0800 Jianbo Liu wrote: > On 9 September 2016 at 16:43, Shreyansh Jain > wrote: > > Introduction: > > = > > > > This patch set is direct derivative of Jan's original series [1],[2]. > > > > - As this deviates substantially from original series, if need be I can > >post it as a separate patch rather than v2. Please suggest. > > - Also, there are comments on original v1 ([4]) which are _not_ > >incorporated in this series as they refer to section no more in new > >version. > > - This v3 version is based on the rte_driver/device patchset v9 [10]. > >That series introduced device structures (rte_driver/rte_device) > >generalizing devices into PCI, VDEV, XXX. For the purpose of this > >patchset, XXX=>SOC. [...] > > > > 5) Design considerations that are different from PCI: > > - Each driver implements its own scan and match function. PCI uses the BDF > >format to read the device from sysfs, but this _may_not_ be a case for a > >SoC ethernet device. > >= This is an important change from initial proposal by Jan in [2]. Unlike > >his attempt to use /sys/bus/platform, this patch relies on the PMD to > > It could be many redundant code if Each PMD driver has the scan > function if its own. > I think Jan's implementation is common to many platform drivers. I personally can find a use case for having a custom scan function. However, we should at least provide a default implementation. Probably, both the scan and match functions should be used to _override_ a default behaviour. So, only drivers that require to scan devices in a specific way would provide a custom function for this. I agree, that this can sometimes lead to code duplication. Moreover, it opens door for a very non-standard, unsecure and wrong-by-design approaches. I'd like more to provide one or more scan implementations in EAL and do not put this responsibility on PMDs. > > >detect the devices. This is because SoC may require specific or > >additional info for device detection. Further, SoC may have embedded Can you provide an example for "additional info for device detection"? > > Can you give us more precise definition about SoC driver? Does it > include the driver in ARM server? I am sorry but I don't understand this question. What you mean by a "driver in ARM server"? Do you mean a kernel driver? There is no "SoC driver" in the text so what definition are asking for? > > >devices/MACs which require initialization which cannot be covered through > >sysfs parsing. I think, the description itself is incorrect. If a device's initialization cannot be satisfied vie sysfs, it means that you have to write a specific probe function. This is not related to scan in any way. However, there may be a group of devices which are not managed by the standard platform_driver of the Linux Kernel (or other OS). In that case, the custom scan function would be helpful. I can imagine a device in a fully I/O coherent platform that only requires to access the /dev/mem only (for the register space). It is unsecure but it would work without any OS-driver. However, I consider it a corner case. It can be useful for testing sometimes but not very helpful for production. We should however support mainly the standard devices which are always represented by the OS. Otherwise, such system would introduce security issues. > > I think it can be done in devinit, not in scan function. devinit can > be different for each driver. +1 > > >= PCI based PMDs rely on EAL's capability to detect devices. This > >proposal puts the onus on PMD to detect devices, add to soc_device_list > >and wait for Probe. Matching, of device<=>driver is again PMD's callback. > > Regards Jan -- Jan ViktorinE-mail: Viktorin at RehiveTech.com System ArchitectWeb:www.RehiveTech.com RehiveTech Brno, Czech Republic
[dpdk-dev] Dear Tetsuya Makawa, Hotplug and PMD for NFV connected port
Dear Tetsuya Makawa, I was watching your video on DPDK Hotplug module There is a mention about PMD for NFV connected port. At that time of the video (2015) it mentions no support. Now is the support available? From which version we have support please? Thank you very much M Jay
[dpdk-dev] [PATCH v2 0/2] add aes-sha384-hmac support to Intel QAT driver
Tested-by: Yong Liu - Tested Branch: dpdk-next-crypto/master - Tested Commit: 3e329d659b62097d15ec86ff92acc8effaf28cd2 - OS: Fedora20 3.11.10-301.fc20.x86_64 - GCC: gcc version 4.8.3 20140911 - CPU: Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz - NIC: Intel Corporation Device Fortville [8086:1583] - QAT: Intel Corporation Coleto Creek PCIe Endpoint [8086:0435] - Default x86_64-native-linuxapp-gcc configuration - Prerequisites: - Total 2 cases, 2 passed, 0 failed - Prerequisites command / instruction: Enable CONFIG_RTE_LIBRTE_PMD_QAT in config/common_base and rebuild dpdk Bind QAT VF devices to igb_uio - Case: Description: SHA384_HMAC authentication unit test Command / instruction: Start test application with normal eal parameter. ./$RTE_TARGET/app/test -c f -n 4 -- -i Run crypto QAT unit test suite and verify SHA384_HMAC cases passed - Case: Description: l2fwd_crypto with SHA384_HMAC authentication test Command / instruction: Start l2fwd_crypto with QAT technology enable. Authentication method is SHA384_HMAC, auth key is also inputted in. Authentication key length for SHA384_HMAC should be 128 bytes. ./examples/l2fwd-crypto/build/app/l2fwd-crypto -c0xf -n4 -- -p0x1 \ --chain HASH_ONLY --cdev_type ANY --auth_algo SHA384_HMAC \ --auth_op GENERATE --auth_key $auth_key Send 65 packets with random 64 bytes payload and capture forwarded packets. Check all forwarded packets contained of 48 bytes hashed value. Check hash values are same as calculated value. > -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Deepak Kumar Jain > Sent: Tuesday, September 13, 2016 3:51 AM > To: dev at dpdk.org > Cc: De Lara Guarch, Pablo; Jain, Deepak K > Subject: [dpdk-dev] [PATCH v2 0/2] add aes-sha384-hmac support to Intel > QAT driver > > This patchset adds support of aes-sha384-hmac in Intel(R) QuickAssist > Technology driver. > > This patchset depends on following patchset: > "crypto/qat: add aes-sha224-hmac capability to Intel QAT driver" > (http://dpdk.org/dev/patchwork/patch/15776/) > > > Jain, Deepak K (2): > crypto/qat: add aes-sha384-hmac capability to Intel QAT driver > app/test: add test cases for aes-sha384-hmac for Intel QAT driver > > Changes from V1: > * Added new feature information in release_16_11.rst file. > * Added information about sha384-hmac in capabilities. > > app/test/test_cryptodev_aes.c| 6 +++-- > doc/guides/cryptodevs/qat.rst| 1 + > doc/guides/rel_notes/release_16_11.rst | 1 + > drivers/crypto/qat/qat_adf/qat_algs_build_desc.c | 33 > > drivers/crypto/qat/qat_crypto.c | 31 > +++--- > 5 files changed, 66 insertions(+), 6 deletions(-) > > -- > 2.5.5
[dpdk-dev] [PATCH v3 0/2] add aes-sha224-hmac support to Intel QAT driver
Tested-by: Yong Liu - Tested Branch: dpdk-next-crypto/master - Tested Commit: 3e329d659b62097d15ec86ff92acc8effaf28cd2 - OS: Fedora20 3.11.10-301.fc20.x86_64 - GCC: gcc version 4.8.3 20140911 - CPU: Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz - NIC: Intel Corporation Device Fortville [8086:1583] - QAT: Intel Corporation Coleto Creek PCIe Endpoint [8086:0435] - Default x86_64-native-linuxapp-gcc configuration - Prerequisites: - Total 2 cases, 2 passed, 0 failed - Prerequisites command / instruction: Enable CONFIG_RTE_LIBRTE_PMD_QAT in config/common_base and rebuild dpdk Bind QAT VF devices to igb_uio - Case: Description: SHA224_HMAC authentication unit test Command / instruction: Start test application with normal eal parameter. ./$RTE_TARGET/app/test -c f -n 4 -- -i Run crypto QAT unit test suite and verify SHA224_HMAC cases passed - Case: Description: l2fwd_crypto with SHA224_HMAC authentication test Command / instruction: Start l2fwd_crypto with QAT technology enable. Authentication method is SHA224_HMAC, auth key is also inputted in. Authentication key length for SHA224_HMAC should be 64 bytes. ./examples/l2fwd-crypto/build/app/l2fwd-crypto -c0xf -n4 -- -p0x1 \ --chain HASH_ONLY --cdev_type ANY --auth_algo SHA224_HMAC \ --auth_op GENERATE --auth_key $auth_key Send 65 packets with random 64 bytes payload and capture forwarded packets. Check all forwarded packets contained of 28 bytes hashed value. Check hash values are same as automatic calculated value. > -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Deepak Kumar Jain > Sent: Friday, September 16, 2016 12:27 AM > To: dev at dpdk.org > Cc: De Lara Guarch, Pablo; Jain, Deepak K > Subject: [dpdk-dev] [PATCH v3 0/2] add aes-sha224-hmac support to Intel > QAT driver > > This patchset adds support of aes-sha224-hmac in Intel(R) QuickAssist > Technology driver. > > This patchset depends on following patchset: > "crypto/qat: add MD5 HMAC capability to Intel QAT driver" > (http://dpdk.org/dev/patchwork/patch/15754/) > > Jain, Deepak K (2): > crypto/qat: add aes-sha224-hmac capability to Intel QAT driver > app/test: add test cases for aes-sha224-hmac for Intel QAT driver > > Changes in v3: > * Cover letter updated with correct information about sha224-hmac. > > Changes in v2: > * Added new feature information in release_16_11.rst file. > * Added information about sha224-hmac in capabilities. > > app/test/test_cryptodev_aes.c| 6 +++-- > doc/guides/cryptodevs/qat.rst| 1 + > doc/guides/rel_notes/release_16_11.rst | 1 + > drivers/crypto/qat/qat_adf/qat_algs_build_desc.c | 33 > > drivers/crypto/qat/qat_crypto.c | 25 +- > 5 files changed, 63 insertions(+), 3 deletions(-) > > -- > 2.5.5
[dpdk-dev] [PATCH v2 0/2] Add HMAC_MD5 to Intel QuickAssist Technology driver
Tested-by: Yong Liu - Tested Branch: dpdk-next-crypto/master - Tested Commit: 3e329d659b62097d15ec86ff92acc8effaf28cd2 - OS: Fedora20 3.11.10-301.fc20.x86_64 - GCC: gcc version 4.8.3 20140911 - CPU: Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz - NIC: Intel Corporation Device Fortville [8086:1583] - QAT: Intel Corporation Coleto Creek PCIe Endpoint [8086:0435] - Default x86_64-native-linuxapp-gcc configuration - Prerequisites: - Total 2 cases, 2 passed, 0 failed - Prerequisites command / instruction: Enable CONFIG_RTE_LIBRTE_PMD_QAT in config/common_base and rebuild dpdk Bind QAT VF devices to igb_uio - Case: Description: HMAC_MD5 authentication unit test Command / instruction: Start test application with normal eal parameter. ./$RTE_TARGET/app/test -c f -n 4 -- -i Run crypto QAT unit test suite and verify MD5_HMAC cases passed - Case: Description: l2fwd_crypto with HMAC_MD5 authentication test Command / instruction: Start l2fwd_crypto with QAT technology enable. Authentication method is MD5_HMAC, auth key is also inputted in. l2fwd-crypto -c 0xf -n4 -- -p0x1 --chain HASH_ONLY --cdev_type HW \ --auth_algo MD5_HMAC --auth_op GENERATE \ --auth_key 00:01:02:03:04:05:06:07:08:09:0a:0b:0c:0d:0e:0f Send 65 packets with random 64 bytes payload and capture forwarded packets. Check all forwarded packets contained of 16 bytes hashed value. Check hash values are same as automatic calculated value. > -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Deepak Kumar Jain > Sent: Friday, September 09, 2016 11:45 PM > To: dev at dpdk.org > Cc: De Lara Guarch, Pablo; Jain, Deepak K > Subject: [dpdk-dev] [PATCH v2 0/2] Add HMAC_MD5 to Intel QuickAssist > Technology driver > > This patchset add capability to use HMAC_MD5 hash algorithm to Intel > QuickAssist Technology driver and test cases to cryptodev test files. > > This patchset depends on the following patches/patchsets: > > "crypto/qat: make the session struct variable in size" > (http://dpdk.org/dev/patchwork/patch/15125/) > > Arkadiusz Kusztal (2): > crypto/qat: add MD5 HMAC capability to Intel QAT driver > app/test: add test cases for MD5 HMAC for Intel QAT driver > > Changes from v1: > * Added new feature information in release_16_11.rst file. > > app/test/test_cryptodev.c| 185 > +++ > app/test/test_cryptodev_hmac_test_vectors.h | 121 +++ > doc/guides/cryptodevs/qat.rst| 1 + > doc/guides/rel_notes/release_16_11.rst | 5 + > drivers/crypto/qat/qat_adf/qat_algs_build_desc.c | 34 + > drivers/crypto/qat/qat_crypto.c | 28 +++- > 6 files changed, 372 insertions(+), 2 deletions(-) > create mode 100644 app/test/test_cryptodev_hmac_test_vectors.h > > -- > 2.5.5
[dpdk-dev] [PATCH v5 5/6] vhost: batch update used ring
> -Original Message-
> From: Yuanhan Liu [mailto:yuanhan.liu at linux.intel.com]
> Sent: Sunday, September 18, 2016 10:56 AM
> To: Maxime Coquelin
> Cc: Wang, Zhihong ; dev at dpdk.org;
> thomas.monjalon at 6wind.com
> Subject: Re: [PATCH v5 5/6] vhost: batch update used ring
>
> On Thu, Sep 15, 2016 at 06:38:06PM +0200, Maxime Coquelin wrote:
> > >>>+static inline void __attribute__((always_inline))
> > >>>+flush_used_ring(struct virtio_net *dev, struct vhost_virtqueue *vq,
> > >>>+uint32_t used_idx_start)
> > >>>+{
> > >>>+if (used_idx_start + vq->shadow_used_idx < vq->size) {
> > >>>+rte_memcpy(>used->ring[used_idx_start],
> > >>>+>shadow_used_ring[0],
> > >>>+vq->shadow_used_idx *
> > >>>+sizeof(struct vring_used_elem));
> > >>>+vhost_log_used_vring(dev, vq,
> > >>>+offsetof(struct vring_used,
> > >>>+ring[used_idx_start]),
> > >>>+vq->shadow_used_idx *
> > >>>+sizeof(struct vring_used_elem));
> > >>>+} else {
> > >>>+uint32_t part_1 = vq->size - used_idx_start;
> > >>>+uint32_t part_2 = vq->shadow_used_idx - part_1;
> > >>>+
> > >>>+rte_memcpy(>used->ring[used_idx_start],
> > >>>+>shadow_used_ring[0],
> > >>>+part_1 *
> > >>>+sizeof(struct vring_used_elem));
> > >>>+vhost_log_used_vring(dev, vq,
> > >>>+offsetof(struct vring_used,
> > >>>+ring[used_idx_start]),
> > >>>+part_1 *
> > >>>+sizeof(struct vring_used_elem));
> > >>>+rte_memcpy(>used->ring[0],
> > >>>+>shadow_used_ring[part_1],
> > >>>+part_2 *
> > >>>+sizeof(struct vring_used_elem));
> > >>>+vhost_log_used_vring(dev, vq,
> > >>>+offsetof(struct vring_used,
> > >>>+ring[0]),
> > >>>+part_2 *
> > >>>+sizeof(struct vring_used_elem));
> > >>>+}
> > >>> }
> > >>Is expanding the code done for performance purpose?
> > >
> > >Hi Maxime,
> > >
> > >Yes theoretically this has the least branch number.
> > >And I think the logic is simpler this way.
> > Ok, in that case, maybe you could create a function to
> > do the rte_memcpy and the vhost_log_used on a given range.
>
> Agreed, that will be better; it could avoid repeating similar code
> block 3 times.
Okay. Thanks for the suggestion, Maxime and Yuanhan.
>
> > I don't have a strong opinion on this, if Yuanhan is fine
> > with current code, that's ok for me.
>
> From what I know, that's kind of DPDK prefered way, to expand code
> when necessary. For example, 9ec201f5d6e7 ("mbuf: provide bulk
> allocation").
>
> So I'm fine with it.
>
> --yliu
