[dpdk-dev] Achieve maximum transmit rate
Hello Friends, What should be done to achieve maximum packet transfer rate using Intel DPDK...? What are the things I should tune ? Does having more no.of tx descriptors help ? With a burst size of 30 and having 512 tx descriptors , I get a speed of around one hundred thousand packets per second (74 byte packets). What are the ones that really affect the transmit rate ? I tried changing the burst size, but the speed decreased as I increased the burst size to some 500 (with 1024 tx descriptors). Thanks and regards
[dpdk-dev] [PATCH v2] eal_common_cpuflags: Fix %rbx corruption, and simplify the code
21/03/2014 13:48, Neil Horman: > On Fri, Mar 21, 2014 at 08:03:34AM -0700, H. Peter Anvin wrote: > > On 03/21/2014 07:49 AM, Neil Horman wrote: > > > From: "H. Peter Anvin" > > > > > > Neil Horman reported that on x86-64 the upper half of %rbx would get > > > clobbered when the code was compiled PIC or PIE, because the > > > i386-specific code to preserve %ebx was incorrectly compiled. > > > > > > However, the code is really way more complex than it needs to be. For > > > one thing, the CPUID instruction only needs %eax (leaf) and %ecx > > > (subleaf) as parameters, and since we are testing for bits, we might > > > as well list the bits explicitly. Furthermore, we can use an array > > > rather than doing a switch statement inside a structure. > > > > > > Reported-by: Neil Horman > > > Signed-off-by: H. Peter Anvin > > > Tested-by: Neil Horman > > > > Thank you for dealing with this! > > > > On the subject of my other email... are C99 initializers acceptable in > > dpdk? If so, I think making that change, too, would be a good idea. > > I'll have to defer this to others, I'm not sure what the accepted > initalization method is. I'm guessing their fine, as both icc and gcc > allow them and those are the supported compilers for dpdk, but I'd like to > hear someone in the maintainership comment. Yes, DPDK use C99 syntax. Feel free to use it in a v3 :) -- Thomas
[dpdk-dev] VM L2 control register (PFVML2FLT) configuring in VMDQ mode
Hi all, I found that there is no way to configure pool behavior, for example accept broadcasts, in VMDQ mode. For SR-IOV there is rte_eth_dev_set_vf_rxmode(), but according to datasheet it doesn't matter whether the 82599's virtual environment operates in IOV mode or in Next Generation VMDq mode. So, we have 2 paths: either make single function by removing from rte_eth_dev_set_vf_rxmode() checking pool(or vf) number against dev_info.max_vfs or make similar function for vmdq mode. What is the best?
[dpdk-dev] [memnic PATCH 3/5] pmd: implement stats of MEMNIC
Hi,
11/03/2014 05:38, Hiroshi Shimamoto:
> From: Hiroshi Shimamoto
>
> Implement missing feature to account statistics.
> This patch adds just an infrastructure.
>
> Signed-off-by: Hiroshi Shimamoto
> Reviewed-by: Hayato Momma
[...]
> @@ -51,6 +51,7 @@ struct memnic_adapter {
> int up_idx, down_idx;
> struct rte_mempool *mp;
> struct ether_addr mac_addr;
> + struct rte_eth_stats stats[RTE_MAX_LCORE];
> };
Could you make a comment to explain why you allocate a structure per core?
It is easier to read when locking strategy is described.
> + for (i = 0; i < RTE_MAX_LCORE; i++) {
> + struct rte_eth_stats *st = &adapter->stats[i];
> +
> + memset(st, 0, sizeof(*st));
> + }
Could you use only one memset for the array?
--
Thomas
[dpdk-dev] patchwork for dpdk.org?
19/03/2014 11:28, Thomas Monjalon: > 18/03/2014 16:31, Kyle Mestery: > > stephen at networkplumber.org wrote: > > > Anybody considered setting up patchwork to track patches on this list? > > > > > > If not familiar, patchwork is a back end which maintainers and > > > developers > > > can keep track of patches submitted and make sure of the status > > > (accepted, > > > rejected, review, etc). > > > > +1 for patchwork. > > I agree. Installing patchwork on dpdk.org is planned. It seems that patchwork is only tested with Apache. But dpdk.org uses nginx. If someone has experience with such configuration, feedbacks are welcome. -- Thomas
[dpdk-dev] [RFC UNTESTED PATCH] eal_common_cpuflags: Fix %rbx corruption, and simplify the code
On Thu, Mar 20, 2014 at 10:03:53AM -0700, H. Peter Anvin wrote:
> I just realized there is yet another oddity in this code:
>
> > @@ -78,8 +69,10 @@ struct cpuid_parameters_t {
> > struct feature_entry {
> > enum rte_cpu_flag_t feature;/**< feature name */
>
> The structure contains a field with an enum value...
>
> > char name[CPU_FLAG_NAME_MAX_LEN]; /**< String for printing */
> > - struct cpuid_parameters_t params; /**< cpuid parameters */
> > - uint32_t feature_mask; /**< bitmask for feature */
> > + uint32_t leaf; /**< cpuid leaf */
> > + uint32_t subleaf; /**< cpuid subleaf */
> > + uint32_t reg; /**< cpuid register */
> > + uint32_t bit; /**< cpuid register bit */
> > };
> >
> >
> > /*
> > @@ -240,17 +207,20 @@ rte_cpu_get_features(struct cpuid_parameters_t params)
> > int
> > rte_cpu_get_flag_enabled(enum rte_cpu_flag_t feature)
> > {
> > - int value;
> > + const struct feature_entry *feat;
> > + cpu_registers_t regs;
> >
> > if (feature >= RTE_CPUFLAG_NUMFLAGS)
> > /* Flag does not match anything in the feature tables */
> > return -ENOENT;
> >
> > - /* get value of the register containing the desired feature */
> > - value = rte_cpu_get_features(cpu_feature_table[feature].params);
> > + feat = &cpu_feature_table[feature];
> > +
> > + /* get the cpuid leaf containing the desired feature */
> > + rte_cpu_get_features(feat->leaf, feat->subleaf, ®s);
> >
> > /* check if the feature is enabled */
> > - return (cpu_feature_table[feature].feature_mask & value) > 0;
> > + return (regs[feat->reg] >> feat->bit) & 1;
> > }
> >
> > /**
>
> ... however, this field is never actually accessed *anywhere* in the
> code; the code instead uses the enum value as the table index. There is
> absolutely no enforcement that the table contents is aligned with the enum.
>
> If C99-style initializers are permitted in this codebase, I would
> strongly recommend using them, and then drop the enum field in struct
> feature_entry and use a macro such as:
>
Actually, its a bit simpler than that, the enum parameter is actually completely
unused, and so can be removed entirely. The FEAT_DEF macro does what you
suggest below already, but only for the feature and name fields.
I'll remove the enum and its definition, and augment the macro to cover the rest
of the fields.
Neil
> #define FEAT(name,leaf,subleaf,reg,bit) \
> [RTE_CPUFLAG_##f] = { leaf, subleaf, reg, bit, #f },
>
> (I'd move the string to the end, but that is just a microoptimization.
> I'm kind of OCD that way.)
>
> -hpa
>
>
[dpdk-dev] [RFC UNTESTED PATCH] eal_common_cpuflags: Fix %rbx corruption, and simplify the code
On 03/24/2014 09:06 AM, Neil Horman wrote:
>>
>> If C99-style initializers are permitted in this codebase, I would
>> strongly recommend using them, and then drop the enum field in struct
>> feature_entry and use a macro such as:
>>
> Actually, its a bit simpler than that, the enum parameter is actually
> completely
> unused, and so can be removed entirely. The FEAT_DEF macro does what you
> suggest below already, but only for the feature and name fields.
>
> I'll remove the enum and its definition, and augment the macro to cover the
> rest
> of the fields.
>
> Neil
>
>> #define FEAT(name,leaf,subleaf,reg,bit) \
>> [RTE_CPUFLAG_##f] = { leaf, subleaf, reg, bit, #f },
>>
>> (I'd move the string to the end, but that is just a microoptimization.
>> I'm kind of OCD that way.)
>>
The nice thing with the C99 initializer is that even if the order is
mismatched between the .c file and the .h file which defines the enum,
things still work correctly.
-hpa
[dpdk-dev] [dpdk-announce] SPEED MATTERS contest by 6WIND
Hello all, This is the first day of the first DPDK contest! Developers, Network Engineers, Academics Invited To Enter Network Tool Implementation Contest 6WIND, a developer of packet processing software, is inviting the public at large to enter a software development contest, called "SPEED MATTERS: The Challenge", which will reward creativity, execution and planning for savvy technology professionals. "The objective of our contest is for applicants to enter novel applications that have been designed using Intel DPDK. Entries can take multiple forms including white papers, proof-of-concepts and finished products. We believe that by sharing implementation examples, we can increase the knowledge of the broader community to lend expertise in building high-performance networking applications with Linux." Winners of "SPEED MATTERS: The Challenge" will be announced via 6WIND at Hot Interconnects in Google?s Mountain View Headquarters on August 19, 2014. More information: http://6wind.com/speed-matters-information
[dpdk-dev] [PATCH v3] eal_common_cpuflags: Fix %rbx corruption, and simplify the code
Neil Horman reported that on x86-64 the upper half of %rbx would get
clobbered when the code was compiled PIC or PIE, because the
i386-specific code to preserve %ebx was incorrectly compiled.
However, the code is really way more complex than it needs to be. For
one thing, the CPUID instruction only needs %eax (leaf) and %ecx
(subleaf) as parameters, and since we are testing for bits, we might
as well list the bits explicitly. Furthermore, we can use an array
rather than doing a switch statement inside a structure.
Reported-by: Neil Horman
Signed-off-by: H. Peter Anvin
Signed-off-by: Neil Horman
---
Change notes:
v2) Corrected build errors
Fixed cpuid_register_t reference passing
Fixed typedef name typo
v3)
* Modified feature_entry struct to drop the name field, as its unused
* Modified cpu_feature_table to use C99 initalizers
* Updated FEAT_DEF macro to include all feature_entry fields
* Modified cpuid_reg enum to start at 1 rather than zero
* Added CPUID_REG macro to drop enum value by 1 during access
* Added check on feat->reg use to detect missing entries
* Fixed a bug in rte_cpu_check_supported in which negative errors are ignored
---
lib/librte_eal/common/eal_common_cpuflags.c | 281 +---
1 file changed, 134 insertions(+), 147 deletions(-)
diff --git a/lib/librte_eal/common/eal_common_cpuflags.c
b/lib/librte_eal/common/eal_common_cpuflags.c
index 1ebf78c..9ee0490 100644
--- a/lib/librte_eal/common/eal_common_cpuflags.c
+++ b/lib/librte_eal/common/eal_common_cpuflags.c
@@ -53,22 +53,15 @@
* Enumeration of CPU registers
*/
enum cpu_register_t {
- REG_EAX = 0,
- REG_EBX,
+ REG_EAX = 1,
REG_ECX,
REG_EDX,
+ REG_EBX,
};
-/**
- * Parameters for CPUID instruction
- */
-struct cpuid_parameters_t {
- uint32_t eax;
- uint32_t ebx;
- uint32_t ecx;
- uint32_t edx;
- enum cpu_register_t return_register;
-};
+#define CPUID_REG(reg) (reg - 1)
+
+typedef uint32_t cpuid_registers_t[4];
#define CPU_FLAG_NAME_MAX_LEN 64
@@ -76,109 +69,111 @@ struct cpuid_parameters_t {
* Struct to hold a processor feature entry
*/
struct feature_entry {
- enum rte_cpu_flag_t feature;/**< feature name */
+ uint32_t leaf; /**< cpuid leaf */
+ uint32_t subleaf; /**< cpuid subleaf */
+ uint32_t reg; /**< cpuid register */
+ uint32_t bit; /**< cpuid register bit */
char name[CPU_FLAG_NAME_MAX_LEN]; /**< String for printing */
- struct cpuid_parameters_t params; /**< cpuid parameters */
- uint32_t feature_mask; /**< bitmask for feature */
};
-#define FEAT_DEF(f) RTE_CPUFLAG_##f, #f
+#define FEAT_DEF(name, leaf, subleaf, reg, bit) \
+ [RTE_CPUFLAG_##name] = {leaf, subleaf, reg, bit, #name },
/**
* An array that holds feature entries
*/
static const struct feature_entry cpu_feature_table[] = {
- {FEAT_DEF(SSE3), {0x1, 0, 0, 0, REG_ECX}, 0x0001},
- {FEAT_DEF(PCLMULQDQ), {0x1, 0, 0, 0, REG_ECX}, 0x0002},
- {FEAT_DEF(DTES64),{0x1, 0, 0, 0, REG_ECX}, 0x0004},
- {FEAT_DEF(MONITOR), {0x1, 0, 0, 0, REG_ECX}, 0x0008},
- {FEAT_DEF(DS_CPL),{0x1, 0, 0, 0, REG_ECX}, 0x0010},
- {FEAT_DEF(VMX), {0x1, 0, 0, 0, REG_ECX}, 0x0020},
- {FEAT_DEF(SMX), {0x1, 0, 0, 0, REG_ECX}, 0x0040},
- {FEAT_DEF(EIST), {0x1, 0, 0, 0, REG_ECX}, 0x0080},
- {FEAT_DEF(TM2), {0x1, 0, 0, 0, REG_ECX}, 0x0100},
- {FEAT_DEF(SSSE3), {0x1, 0, 0, 0, REG_ECX}, 0x0200},
- {FEAT_DEF(CNXT_ID), {0x1, 0, 0, 0, REG_ECX}, 0x0400},
- {FEAT_DEF(FMA), {0x1, 0, 0, 0, REG_ECX}, 0x1000},
- {FEAT_DEF(CMPXCHG16B),{0x1, 0, 0, 0, REG_ECX}, 0x2000},
- {FEAT_DEF(XTPR), {0x1, 0, 0, 0, REG_ECX}, 0x4000},
- {FEAT_DEF(PDCM), {0x1, 0, 0, 0, REG_ECX}, 0x8000},
- {FEAT_DEF(PCID), {0x1, 0, 0, 0, REG_ECX}, 0x0002},
- {FEAT_DEF(DCA), {0x1, 0, 0, 0, REG_ECX}, 0x0004},
- {FEAT_DEF(SSE4_1),{0x1, 0, 0, 0, REG_ECX}, 0x0008},
- {FEAT_DEF(SSE4_2),{0x1, 0, 0, 0, REG_ECX}, 0x0010},
- {FEAT_DEF(X2APIC),{0x1, 0, 0, 0, REG_ECX}, 0x0020},
- {FEAT_DEF(MOVBE), {0x1, 0, 0, 0, REG_ECX}, 0x0040},
- {FEAT_DEF(POPCNT),{0x1, 0, 0, 0, REG_ECX}, 0x0080},
- {FEAT_DEF(TSC_DEADLINE), {0x1, 0, 0, 0, REG_ECX}, 0x0100},
- {FEAT_DEF(AES), {0x1, 0, 0, 0, REG_ECX}, 0x0200},
- {FEAT_DEF(XSAVE), {0x1, 0, 0, 0, REG_ECX}, 0x0400},
- {FEAT_DEF(OSXSAVE), {0x1, 0, 0, 0, REG_ECX}, 0x08000
[dpdk-dev] [PATCH v3] eal_common_cpuflags: Fix %rbx corruption, and simplify the code
On 03/24/2014 10:44 AM, Neil Horman wrote: > * Modified cpuid_reg enum to start at 1 rather than zero > * Added CPUID_REG macro to drop enum value by 1 during access I guess I don't get it... why? -hpa
[dpdk-dev] [PATCH 1/6] rte_mbuf: copy offload flags when doing attach/clone of mbuf
07/03/2014 10:13, Stephen Hemminger: > rte_pktmbuf_attach copies the packet meta data but does not > copy the offload flags. This means that cloned packets lose > their offload settings such as vlan tag. > > Signed-off-by: Stephen Hemminger Acked and applied for version 1.6.0r2. Thank you -- Thomas
[dpdk-dev] [PATCH 3/6] rte_jhash: make arg to rte_jhash2 const
07/03/2014 10:13, Stephen Hemminger: > The argument to rte_jhash2() is not changed. > > Signed-off-by: Stephen Hemminger Acked and applied for version 1.6.0r2. Thank you -- Thomas
[dpdk-dev] [PATCH 4/6] mempool: use GCC push/pop
07/03/2014 10:13, Stephen Hemminger: > The include file should not change the GCC compile options for > the whole file being compiled, but only for the one inline function > that needs it. Using the push_options/pop_options fixes this. > > Signed-off-by: Stephen Hemminger Acked and applied for version 1.6.0r2. Thank you -- Thomas
[dpdk-dev] [PATCH 2/6] qos: use rte_zmalloc instead of memzone for allocation
07/03/2014 10:13, Stephen Hemminger: > Memory zone's are inflexible and can not be destroyed. > The size is fixed when initially created therefor QoS parameters > could not be modified at run time, because table size for a subport > might change. > > Signed-off-by: Stephen Hemminger This change would probably deserve a description of the use case. Please explain in the log and/or comments why you need to increase this size. -- Thomas
[dpdk-dev] [PATCH v3] eal_common_cpuflags: Fix %rbx corruption, and simplify the code
On Mon, Mar 24, 2014 at 11:09:52AM -0700, H. Peter Anvin wrote: > On 03/24/2014 10:44 AM, Neil Horman wrote: > > * Modified cpuid_reg enum to start at 1 rather than zero > > * Added CPUID_REG macro to drop enum value by 1 during access > > I guess I don't get it... why? > To add an extra sanity check in rte_get_flag_enabled. If we were moving to the use of C99 initalizers, I wanted something to catch the possibility that we skip a flag by accident (i.e. leave a zero initalized hole in the array). Except 0 from my read is a valid value for all the fields of the array. So I bumped up the cpuid register enum by one and wrapped it in a macro. That way we can test for !feat->reg as an indicator that we're requesting feature support for a flag thats not listed in the array. Neil > -hpa > >
[dpdk-dev] [PATCH v3] eal_common_cpuflags: Fix %rbx corruption, and simplify the code
On 03/24/2014 12:52 PM, Neil Horman wrote: >> > To add an extra sanity check in rte_get_flag_enabled. If we were moving to > the > use of C99 initalizers, I wanted something to catch the possibility that we > skip > a flag by accident (i.e. leave a zero initalized hole in the array). Except 0 > from my read is a valid value for all the fields of the array. So I bumped up > the cpuid register enum by one and wrapped it in a macro. That way we can > test > for !feat->reg as an indicator that we're requesting feature support for a > flag > thats not listed in the array. It actually isn't: there aren't any flags in CPUID leaf 0, so since the code only looks for bits it'd be perfectly okay to reject leaf 0. Another thing that I noted is that the code doesn't actually check that any particular leaf is valid (by checking the maximum leaf number in CPUID leaf 0x:EAX). Especially for the leaf 7 features this could result in false positives, which obviously would be disastrous. -hpa
[dpdk-dev] [PATCH 5/6] xen: dont create dependency on cmdline library
07/03/2014 10:13, Stephen Hemminger: > The driver should not introduce an unnecessary dependency on the cmdline > code. We don't build that code since it is not used in our product. Your product is not the concern but I agree this dependency is unnecessary. I'd just remove the comment about your product. > +/* defined in but that has conflicts with rte_ethdev.h */ > +extern struct ether_addr *ether_aton(const char *); It seems we should fix this conflict first. I think the problem is about libc redefinitions in rte_ether.h. Patches are welcome. -- Thomas
[dpdk-dev] Question regarding rte_rdtsc_precise()
I have a question regarding rte_rdtsc_precise() function. I was not getting
an expected number from the normal rte_rdtsc(), and hence changed to
rte_rdtsc_precise() function and am getting a different value, which seems
to be producing a number close to my expectation.
Q1. However, I wanted to ask if how I am using the function is correct. I
am attaching a code snippet below. Is this the correct way to use
rte_rdtsc_precise() or if I need other things (e.g., adding lfence before
and after for instance?)
begin = rte_rdtsc_precise();
do something...
total_time = rte_rdtsc_precise() - begin;
printf("%g cyc\n",(double)total_time);
Q2. Am I correct that the rte_rdtsc_precise() makes the rdtsc a serializing
instruction?
Q3. I found from some sources online that there needs to be about ~ 1000
cycles between consecutive rdtsc() calls to get a more accurate measurement
[1]. Is this true? If so, is this necessary for your rte_rdtsc_precise()?
[1] http://software.intel.com/en-us/forums/topic/305287
"For best results, make sure you have at least ~1,000 clocks worth of
instructions between consecutive rdtsc calls."
Thank you.
[dpdk-dev] [PATCH] ixgbe: support flow director for X540
From: Mauro Annarumma Flow director in X540 uses the same registers as in 82599. So it just has to be enabled in the 82599 implementation. Signed-off-by: Mauro Annarumma --- lib/librte_pmd_ixgbe/ixgbe_fdir.c | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/lib/librte_pmd_ixgbe/ixgbe_fdir.c b/lib/librte_pmd_ixgbe/ixgbe_fdir.c index f15151a..0d91ff9 100644 --- a/lib/librte_pmd_ixgbe/ixgbe_fdir.c +++ b/lib/librte_pmd_ixgbe/ixgbe_fdir.c @@ -182,7 +182,7 @@ ixgbe_fdir_configure(struct rte_eth_dev *dev) PMD_INIT_FUNC_TRACE(); - if (hw->mac.type != ixgbe_mac_82599EB) + if (hw->mac.type != ixgbe_mac_82599EB && hw->mac.type !=ixgbe_mac_X540) return -ENOSYS; err = configure_fdir_flags(&dev->data->dev_conf.fdir_conf, &fdirctrl); @@ -464,7 +464,7 @@ fdir_add_update_signature_filter(struct rte_eth_dev *dev, union ixgbe_atr_input input; int err; - if (hw->mac.type != ixgbe_mac_82599EB) + if (hw->mac.type != ixgbe_mac_82599EB && hw->mac.type !=ixgbe_mac_X540) return -ENOSYS; err = fdir_filter_to_atr_input(fdir_filter, &input); @@ -550,7 +550,7 @@ ixgbe_fdir_remove_signature_filter(struct rte_eth_dev *dev, PMD_INIT_FUNC_TRACE(); - if (hw->mac.type != ixgbe_mac_82599EB) + if (hw->mac.type != ixgbe_mac_82599EB && hw->mac.type !=ixgbe_mac_X540) return -ENOSYS; err = fdir_filter_to_atr_input(fdir_filter, &input); @@ -674,7 +674,7 @@ ixgbe_fdir_set_masks(struct rte_eth_dev *dev, struct rte_fdir_masks *fdir_masks) hw = IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private); - if (hw->mac.type != ixgbe_mac_82599EB) + if (hw->mac.type != ixgbe_mac_82599EB && hw->mac.type !=ixgbe_mac_X540) return -ENOSYS; err = ixgbe_reinit_fdir_tables_82599(hw); @@ -784,7 +784,7 @@ fdir_add_update_perfect_filter(struct rte_eth_dev *dev, union ixgbe_atr_input input; int err; - if (hw->mac.type != ixgbe_mac_82599EB) + if (hw->mac.type != ixgbe_mac_82599EB && hw->mac.type !=ixgbe_mac_X540) return -ENOSYS; err = fdir_filter_to_atr_input(fdir_filter, &input); @@ -836,7 +836,7 @@ ixgbe_fdir_remove_perfect_filter(struct rte_eth_dev *dev, PMD_INIT_FUNC_TRACE(); - if (hw->mac.type != ixgbe_mac_82599EB) + if (hw->mac.type != ixgbe_mac_82599EB && hw->mac.type !=ixgbe_mac_X540) return -ENOSYS; err = fdir_filter_to_atr_input(fdir_filter, &input); @@ -859,7 +859,7 @@ ixgbe_fdir_info_get(struct rte_eth_dev *dev, struct rte_eth_fdir *fdir) IXGBE_DEV_PRIVATE_TO_FDIR_INFO(dev->data->dev_private); uint32_t reg; - if (hw->mac.type != ixgbe_mac_82599EB) + if (hw->mac.type != ixgbe_mac_82599EB && hw->mac.type !=ixgbe_mac_X540) return; /* Get the information from registers */ -- 1.9.0
[dpdk-dev] [PATCH 09/11] device-args: replace use-device eal option by pci-whitelist and vdev
Hi, 04/03/2014 13:14, Richardson, Bruce: > 04/03/2014 14:09, Olivier MATZ: > > My initial concern was that --use-device has 2 different significations, > > depending on the format of arguments: > >- instanciate a virtual driver if it looks like a vdev name > >- add a PCI device to the whitelist if it looks like a pci address > > I also find strange that instanciating a virtual device changes the PCI > > mode to whitelist, even if it could be fixed by adding a specific argument > > for that. > > [BR] I agree that having the mode change silently like that was probably not > the best design. I therefore, agree that a flag should be used to switch > from normal to whitelist mode, I just think that thereafter the devices of > whatever type should all be enumerated using a common flag parameter. I think we should split this in 2 functions because they have totally different meaning: - create a virtual device and instantiate a driver - whitelist a physical device for driver probing Using the same option for vdev and whitelist would be even more confusing in case of blacklist because drivers would probe explicitly listed vdevs and PCI devs which are not blacklisted. -- Thomas
