[dpdk-dev] [PATCH] mbuf: clean old refcnt option
2015-03-31 21:26, Olivier MATZ:
> Hi Thomas,
>
> On 03/31/2015 07:58 PM, Thomas Monjalon wrote:
> > CONFIG_RTE_MBUF_SCATTER_GATHER was renamed into CONFIG_RTE_MBUF_REFCNT
> > by commit 62814bc2e923 and removed by commit 4769bc5a27cc.
> > Some traces remain because of delayed patches.
> >
> > It can also be removed from doxygen config.
> > It is now poisoned in rte_mbuf.h to warn any misuse.
> >
> > Fixes: d0dff9ba445e ("doc: sample application user guide")
> > Fixes: fc1f2750a3ec ("doc: programmers guide")
> > Fixes: 4769bc5a27cc ("mbuf: remove build option to disable refcnt")
> >
> > Signed-off-by: Thomas Monjalon
[...]
> > --- a/doc/guides/sample_app_ug/vhost.rst
> > +++ b/doc/guides/sample_app_ug/vhost.rst
> > @@ -338,28 +338,6 @@ Compiling the Sample Code
> >
> > .. code-block:: console
> >
> > -make
> > -
> > -.. note::
> > -
> > -Note For zero copy, need firstly disable
> > CONFIG_RTE_MBUF_SCATTER_GATHER,
> > -CONFIG_RTE_LIBRTE_IP_FRAG and CONFIG_RTE_LIBRTE_DISTRIBUTOR
> > -in the config file and then re-configure and compile the core lib,
> > and then build the application:
> > -
> > -.. code-block:: console
> > -
> > -vi ${RTE_SDK}/config/common_linuxapp
> > -
> > -change it as follows:
> > -
> > -::
> > -
> > -CONFIG_RTE_MBUF_SCATTER_GATHER=n
> > -CONFIG_RTE_LIBRTE_IP_FRAG=n
> > -CONFIG_RTE_LIBRTE_DISTRIBUTOR=n
> > -
> > -.. code-block:: console
> > -
> > cd ${RTE_SDK}
> > make config ${RTE_TARGET}
> > make install ${RTE_TARGET}
Note that make config is useless and T= is missing.
> I have one doubt about the vhost part, as the previous doc was telling
> to disable refcnt option and now the behavior is equivalent to having
> the option always enabled. Also you are removing parts of doc that
> talk about CONFIG_RTE_LIBRTE_DISTRIBUTOR and CONFIG_RTE_LIBRTE_IP_FRAG.
>
> It would be safer to also have an acknowledgment from a vhost expert.
Huawei, Changchun, any opinion please?
[dpdk-dev] [PATCH] i40e: fix no effect wait_to_complete on link_get
> > API *rte_eth_link_get* expect to call a wait to complete link_update. > > That's the difference between *rte_eth_link_get_nowait*. > > The patch fixes the issue that i40e link_update ignores the wait_to_complete > > flag. > > The issue impacts those applications calling rte_eth_link_get to get wrong > > intermediate link status. > > > > Signed-off-by: Cunming Liang > Acked-by: Helin Zhang Applied, thanks
[dpdk-dev] [PATCH] i40e: fix no effect wait_to_complete on link_get
Hi, 2015-04-01 06:10, Zhang, XiaonanX: > > Tested-by: Xiaonan zhang > > - OS: Fedora21 3.19.1-201.fc21.x86_64 > - GCC: gcc version 4.9.1 20140930 (Red Hat 4.9.1-11) (GCC) > - CPU: Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz > - NIC: Ethernet controller [0200]: Intel Corporation Ethernet Controller X710 > for 10GbE SFP+ [8086:1572] (rev 01) > - Default x86_64-native-linuxapp-gcc configuration > - Total 1 cases, 1 passed, 0 failed > > - Test case: Used Qos example to verified > - What is the relation between link status timeout and qos_sched? > Traffic shaping for subport. Check that the subport rate is enforced. > > Set the subport output rate to x% of line rate (x = 10 .. 100). Set the > subport TC limits high (100% line rate each), so they do not constitute > limitations. Input traffic is 100% line rate. > > Different tb period and tb credits, therefore different output rate, are > tried: 25%, 50%, 75%, 90% and 100% the lineal rate. (The output for subport > is Tb credits per period / Tb period.) > The traffic is injected change subport value random. > > Other parameters are same before tests and they don't change here. > > Cmdline: ./examples/qos_sched/build/qos_sched -c 0xe -n 4 -- --pfc > "0,1,2,3,3" --cfg "/root/profile_sched_pipe_1.cfg" > > The result is this table: > > > +---+--+ > | Subport output rate | Subport output rate | > | (% line rate) | (Mpps) | > +---+---+--+---+ > | Expected | Actual| Expected | Actual| > +---+---+--+---+ This table is empty. > > Signed-off-by: Xiaonan Zhang It seems that this test report is not relevant. It will be ignored in the commit message. Sorry
[dpdk-dev] [PATCH] doc: add note for txqflags in testpmd UG
> > Since txqflags is now set from the default rx/tx configuration, depending on > > the PMD, it might not be 0. > > Therefore, user has to overwrite it with --txqflags 0. > > > > Signed-off-by: Pablo de Lara > > Thanks Pablo that wording is better > Acked-by Siobhan Butler Applied, thanks
[dpdk-dev] [PATCH v2] mk: fix pdf doc rules order
2015-04-01 13:29, Mcnamara, John:
> > -Original Message-
> > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> > Sent: Wednesday, April 1, 2015 1:31 PM
> > To: dev at dpdk.org
> > Cc: mukawa at igel.co.jp; Mcnamara, John; De Lara Guarch, Pablo
> > Subject: [PATCH v2] mk: fix pdf doc rules order
> >
> > From: John McNamara
> >
> > Re-ordered the guide-pdf-% and guide-% rules to allow the doc-guides-pdf
> > target to build with make 3.81. It builds unmodified with all later
> > versions of make.
> >
> > Reported-by: Tetsuya Mukawa
> > Signed-off-by: John McNamara
> > Signed-off-by: Thomas Monjalon
> > ---
> > v2: reorder also clean rules
>
> Hi Thomas,
>
> That is fine for consistency but there weren't any issues with "make
> doc-clean" and "make doc-guides-pdf-clean" in the V1 patch/original.
>
> But I'm fine with it like this as well.
>
> John.
Fixes: ebf8050afd44 ("doc: add pdf output")
Applied, thanks
[dpdk-dev] DPDK Community Call - Software QoS
This was meant to be sent as a calendar invite, so the time would automatically convert to your local time zone. That didn't seem to work though. I'm not sure if that's just the way the mailing list works, or if it's an outlook config error on my side. Anyway, here's the date and time in a variety of time zones: Dublin (Ireland) - Tuesday, April 21, 2015 at 4:00:00 PM IST UTC+1 hour San Francisco (U.S.A. - California) - Tuesday, April 21, 2015 at 8:00:00 AM PDT UTC-7 hours Phoenix (U.S.A. - Arizona) - Tuesday, April 21, 2015 at 8:00:00 AM MST UTC-7 hours Boston (U.S.A. - Massachusetts) - Tuesday, April 21, 2015 at 11:00:00 AM EDT UTC-4 hours New York (U.S.A. - New York) - Tuesday, April 21, 2015 at 11:00:00 AM EDT UTC-4 hours Ottawa (Canada - Ontario) - Tuesday, April 21, 2015 at 11:00:00 AM EDT UTC-4 hours London (United Kingdom - England) - Tuesday, April 21, 2015 at 4:00:00 PM BST UTC+1 hour Paris (France) - Tuesday, April 21, 2015 at 5:00:00 PM CEST UTC+2 hours Tel Aviv (Israel) - Tuesday, April 21, 2015 at 6:00:00 PM IDT UTC+3 hours Moscow (Russia) - Tuesday, April 21, 2015 at 6:00:00 PM MSK UTC+3 hours New Delhi (India - Delhi) - Tuesday, April 21, 2015 at 8:30:00 PM IST UTC+5:30 hours Beijing (China - Beijing Municipality) - Tuesday, April 21, 2015 at 11:00:00 PM CST UTC+8 hours Corresponding UTC (GMT) - Tuesday, April 21, 2015 at 15:00:00 Apologies for any confusion. Tim > -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of O'driscoll, Tim > Sent: Wednesday, April 1, 2015 4:41 PM > To: dev at dpdk.org > Subject: [dpdk-dev] DPDK Community Call - Software QoS > > Agenda: > - Software Quality of Service (Cristian Dumitrescu) > > > Tue, Apr 21, 4:00-5:30 PM GMT Daylight Time > > Please join my meeting from your computer, tablet or smartphone. > https://global.gotomeeting.com/join/293233645 > > You can also dial in using your phone. > Ireland : +353 (0) 15 290 180 > United States : +1 (312) 757-3126 > Australia : +61 2 9087 3604 > Austria : +43 (0) 7 2088 0034 > Belgium : +32 (0) 28 08 9321 > Canada : +1 (647) 497-9350 > Denmark : +45 (0) 69 91 80 05 > Finland : +358 (0) 931 58 1746 > France : +33 (0) 182 880 780 > Germany : +49 (0) 692 5736 7211 > Italy : +39 0 699 26 68 58 > Netherlands : +31 (0) 208 908 267 > New Zealand : +64 (0) 9 442 7358 > Norway : +47 21 54 32 44 > Spain : +34 911 23 0850 > Sweden : +46 (0) 853 527 835 > Switzerland : +41 (0) 435 0006 96 > United Kingdom : +44 (0) 20 3713 5028 > > Access Code: 293-233-645 > Audio PIN: Shown after joining the meeting >
[dpdk-dev] Cannot build doc using DPDK-2.0.0-rc3
Hi, guide-% rule is selected instead of guide-pdf-% in mk/rte.sdkdoc.mk, I guess. 2015-04-01 19:08 GMT+09:00 Mcnamara, John : >> -Original Message- >> From: Tetsuya Mukawa [mailto:mukawa at igel.co.jp] >> Sent: Wednesday, April 1, 2015 10:49 AM >> To: De Lara Guarch, Pablo; Mcnamara, John >> Cc: dev at dpdk.org >> Subject: Re: [dpdk-dev] Cannot build doc using DPDK-2.0.0-rc3 >> >> I am using Ubuntu14, so package name may be different. >> >> To make sure, I just installed 'texlive-*', then tried to build doc again. >> But I faced the same error. >> Anyway, it seems the error comes from my environment, so I will check it >> more. > > Hi, > > Actually that looks like a Makefile issue rather than a toolchain issue. > Sphinx shouldn't be trying to build with a builder called "pdf-freebsd_gsg". > It seems that it has picked up the wrong rule. > > I'll look into it. > > John
[dpdk-dev] Cannot build doc using DPDK-2.0.0-rc3
On 2015/04/01 18:29, De Lara Guarch, Pablo wrote: > Hi Tetsuya, > >> -Original Message- >> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Tetsuya Mukawa >> Sent: Wednesday, April 01, 2015 10:18 AM >> To: Mcnamara, John >> Cc: dev at dpdk.org >> Subject: [dpdk-dev] Cannot build doc using DPDK-2.0.0-rc3 >> >> Hi John, >> >> >> It seems after applying following patch, I cannot build doc. >> ebf8050 doc: add pdf output >> >> --- >> $ T=x86_64-native-linuxapp-gcc make doc >> >> (snip) >> >> lookup cache used 2433/65536 hits=6354 misses=2576 >> finished... >> sphinx processing guides-html... >> sphinx processing guides-pdf-freebsd_gsg... >> >> Sphinx error: >> Builder name pdf-freebsd_gsg not registered >> make[1]: *** [guides-pdf-freebsd_gsg] Error 1 >> make: *** [doc-all] Error 2 >> --- >> >> Could you please check it? > I have no issues building the docs. Do you have all necessary packages for > building them? > > You will need texlive, texlive-latex, texlive-collection-latex, > texlive-collection-latexrecommended, > texlive-collection-latexextra and texlive-dejavu. Hi Pablo, Thanks for your reply. I am using Ubuntu14, so package name may be different. To make sure, I just installed ?texlive-*?, then tried to build doc again. But I faced the same error. Anyway, it seems the error comes from my environment, so I will check it more. Thanks, Tetsuya > Pablo >> Thanks, >> Tetsuya
[dpdk-dev] Cannot build doc using DPDK-2.0.0-rc3
Hi John, It seems after applying following patch, I cannot build doc. ebf8050 doc: add pdf output --- $ T=x86_64-native-linuxapp-gcc make doc (snip) lookup cache used 2433/65536 hits=6354 misses=2576 finished... sphinx processing guides-html... sphinx processing guides-pdf-freebsd_gsg... Sphinx error: Builder name pdf-freebsd_gsg not registered make[1]: *** [guides-pdf-freebsd_gsg] Error 1 make: *** [doc-all] Error 2 --- Could you please check it? Thanks, Tetsuya
[dpdk-dev] Running DPDK with Docker
Hi, Given the popularity of Docker it would be nice if we can run DPDK inside a Docker container but the challenge is the igb_uio.ko and rte_kni.ko kernel modules which need to be compiled with the exact kernel source running on the host. Are there ways to seamlessly run DPDK with Docker? I came across an articles about running DPDK with Linux container but still the requirement is to insert igb_uio. Any plans to make the igb_uio and rte_kni modules as default modules of Linux source code or any other better approaches/suggestions ? Thanks. http://dpdk.org/ml/archives/dev/2014-October/006373.html http://permalink.gmane.org/gmane.comp.networking.dpdk.devel/6479 Regards Suyash Karmarkar
[dpdk-dev] [PATCH v2 0/3] split programmers guide a bit
> -Original Message- > From: Mcnamara, John > Sent: Wednesday, April 1, 2015 5:37 PM > To: Iremonger, Bernard; Thomas Monjalon > Cc: Butler, Siobhan A; dev at dpdk.org > Subject: RE: [dpdk-dev] [PATCH v2 0/3] split programmers guide a bit > > > -Original Message- > > From: Iremonger, Bernard > > Sent: Wednesday, April 1, 2015 10:19 AM > > To: Thomas Monjalon; Mcnamara, John > > Cc: Butler, Siobhan A; dev at dpdk.org > > Subject: RE: [dpdk-dev] [PATCH v2 0/3] split programmers guide a bit > > > > > > 2015-03-31 11:34, Mcnamara, John: > > > > Any objection to an additional patch to move the figure captions > > > > below the figures in the docs? > > > > > > No objection. > > > We should use figure:: keyword instead of image:: to add a caption. > > > > > > > The caption above the figure was the format used in the initial > > > > docs, and it looks okay in the HTML output, but in the PDF output > > > > it tends to get merged into the preceding paragraph and isn't > > > > always on the same page as the figure. > > > > > > Yes, it's a bit strange. > > > Why moving it below will ensure to keep it in the same page? > > > I think figure:: keyword may solve it. > > > > Hi John, > > > > My preference would be to keep the caption above the figure. > > This was the way it was done in the original 1.7 MSword documents (the > > starting point for the conversion to rst files). > > Hi Bernard, > > I don't mind the caption above. I'm mainly concerned with it staying with the > image. > > To do this we need to use the figure:: keyword as Thomas suggested. However, > there are some knock > on effects from this. > > * As far as I can see, we can't just replace with image:: with figure:: in > the |image-name| substitution > definitions since Sphinx or RST doesn't support it. > * This means that the |image-name| substitutions will have to change back to > explicit .. figure:: > declarations. Not a big deal. > * The captions have to be under the image. I don't see a way to configure it > to be on top. It may be > possible in LaTex but not in Html. > * We should also modify the table captions in the same way. > > So at this point I'm sorry I brought it up. I can post a programmatically > generated patch as an RFC if > there is interest in seeing what the updated output would look like. > > The main positive is that it would give us automatic* figure/table numbering > in Html and PDF and the > captioning looks quite good. (*This requires Sphinx 1.3). > > John > Hi John, I am not sure why the captions have to be under the images. At present the captions are just a bold line of text before the image in the rst files for example, **Figure 17. Components of a DPDK KNI Application** This will probably affect the cross reference links as well or does the automatic numbering work with the links as well. Regards, Bernard
[dpdk-dev] [PATCH v2 1/5] mbuf: fix clone support when application uses private mbuf data
Hi,
On 04/01/2015 03:48 PM, Ananyev, Konstantin wrote:
>> With this solution, there are 2 options:
>> - no mempool modification, so each application/driver has to add
>> priv_size bytes to the object to get the mbuf pointer. This does not
>> look feasible.
>> - change the mempool to support private area before each object. I
>> think mempool API is already quite complex, and I think it's not
>> the role of the mempool library to provide such features.
>
>
> In fact, I think the changes would be minimal.
> All we have to do, is to make changes in rte_pktmbuf_init():
>
> void
> rte_pktmbuf_init(struct rte_mempool *mp,
> __attribute__((unused)) void *opaque_arg,
> void *_m,
> __attribute__((unused)) unsigned i)
> {
>
> //extract priv_size from mempool (discussed above).
> uint16_t priv_size = rte_mbufpool_get_priv_size(mp);
>
> struct rte_mbuf *m = _m + priv_size;
> uint32_t buf_len = mp->elt_size - sizeof(struct rte_mbuf) -
> priv_size;
>
>
>
>
> With that way priv_size inside mbuf would always be the size its own
> private space,
> for both direct and indirect mbus., so we don't require to set priv_size
> at attach/detach.
> Again RTE_MBUF_TO_BADDR() and RTE_MBUF_FROM_BADDR() would just work
> without any modifications.
I'm not sure I'm getting it. The argument '_m' of your
rte_pktmbuf_init() is the pointer to the priv data, right?
So it means that the mbuf is located priv_size bytes after.
The rte_pktmbuf_init() function is called by mempool_create(),
and the _m parameter is a pointer to a mempool object. So
in my understanding, mempool_get() would not return a rte_mbuf
but a pointer to the application private data.
>>>
>>> Ah my bad, forgot that mempool's obj_init() returns void now :(
>>> To make this approach work also need to change it, so it return a pointer
>>> to the new object.
>>> So, rte_pktmbuf_init() would return m and then in mempool_add_elem():
>>>
>>> if (obj_init)
>>> obj = obj_init(mp, obj_init_arg, obj, obj_idx);
>>>
>>> rte_ring_sp_enqueue(mp->ring, obj);
>>
>> Yes, but modififying mempool is what I wanted to avoid for several
>> reasons. First, I think that changing the mempool_create() API here
>> (actually the obj_init prototype) would impact existing applications.
>>
>> Also, I'm afraid that storing a different address than the start
>> address of the object would have additional impacts. For instance,
>> some data is supposed to be stored before the object, see
>> __mempool_from_obj() or mempool_obj_audit().
>
> mempool_obj_audit() should be ok, I think, but yes -
> rte_mempool_from_obj() would change the behaviour and
> can't be used by mempool_obj_audit() anymore.
>
> Ok, I am convinced - let's stick with private space between rte_mbuf and
> buf_adddr, as you suggested.
>
>>
>> Finally, I believe that mempool is not the proper place to do
>> modifications that are only needed for mbufs. If we really want
>> to implement mbuf private data in that way, maybe it would be
>> better to add a new layer above mempool (a mbuf pool layer).
>
> Not that I am against it, but seems like even more massive change -
> every application would need to be changed to use rte_mbufpool_create(), no?
Yes, indeed that would be a significant change for the applications,
which is probably not what we want, except if we can keep backward
compatibility. Maybe it's possible. That's something to keep in mind
if I send a patch series that introduce a new rte_mbuf_pool_create()
function.
Regards,
Olivier
[dpdk-dev] [PATCH v2 0/3] split programmers guide a bit
> -Original Message- > From: Iremonger, Bernard > Sent: Wednesday, April 1, 2015 10:19 AM > To: Thomas Monjalon; Mcnamara, John > Cc: Butler, Siobhan A; dev at dpdk.org > Subject: RE: [dpdk-dev] [PATCH v2 0/3] split programmers guide a bit > > > > 2015-03-31 11:34, Mcnamara, John: > > > Any objection to an additional patch to move the figure captions > > > below the figures in the docs? > > > > No objection. > > We should use figure:: keyword instead of image:: to add a caption. > > > > > The caption above the figure was the format used in the initial > > > docs, and it looks okay in the HTML output, but in the PDF output it > > > tends to get merged into the preceding paragraph and isn't always on > > > the same page as the figure. > > > > Yes, it's a bit strange. > > Why moving it below will ensure to keep it in the same page? > > I think figure:: keyword may solve it. > > Hi John, > > My preference would be to keep the caption above the figure. > This was the way it was done in the original 1.7 MSword documents (the > starting point for the conversion to rst files). Hi Bernard, I don't mind the caption above. I'm mainly concerned with it staying with the image. To do this we need to use the figure:: keyword as Thomas suggested. However, there are some knock on effects from this. * As far as I can see, we can't just replace with image:: with figure:: in the |image-name| substitution definitions since Sphinx or RST doesn't support it. * This means that the |image-name| substitutions will have to change back to explicit .. figure:: declarations. Not a big deal. * The captions have to be under the image. I don't see a way to configure it to be on top. It may be possible in LaTex but not in Html. * We should also modify the table captions in the same way. So at this point I'm sorry I brought it up. I can post a programmatically generated patch as an RFC if there is interest in seeing what the updated output would look like. The main positive is that it would give us automatic* figure/table numbering in Html and PDF and the captioning looks quite good. (*This requires Sphinx 1.3). John
[dpdk-dev] library choices for AES CBC/GCM on dpdk app datapath
Hi, I was wondering if anyone has pointers for a crypto library implementing AES CBC and GCM that I can use for encrypting network packets in a DPDK app's datapath. The app is supposed to run in a VM in the cloud. So access to crypto acceleration hardware (besides Intel AES NI/pmuludq) may not be present. Does it make sense to look into OpenSSL and invoking it's APIs from a DPDK app? Thanks!
[dpdk-dev] [PULL REQUEST] i40e: bug fixes of flow director and link update
The following changes since commit f14db469be8e6ac625353f577ad8fa0eec489e54: version: 2.0.0-rc3 (2015-03-31 03:34:24 +0200) are available in the git repository at: helin at dpdk.org:dpdk-i40e-next.git master for you to fetch changes up to 6e278442b8669fc442c4a9b4b7d14b61cd579e39: i40e: fix no effect wait_to_complete on link_get (2015-04-01 02:30:59 -0400) Cunming Liang (1): i40e: fix no effect wait_to_complete on link_get Jingjing Wu (1): i40e: fix the issue reported by klocwork lib/librte_pmd_i40e/i40e_ethdev.c | 29 +++-- lib/librte_pmd_i40e/i40e_fdir.c | 35 +-- 2 files changed, 36 insertions(+), 28 deletions(-)
[dpdk-dev] [PATCH] cast used->idx to volatile
On 4/1/2015 3:51 PM, Thomas Monjalon wrote: > 2015-03-30 15:56, Xie, Huawei: >> On 3/30/2015 5:21 PM, Linhaifeng wrote: >>> On 2015/3/24 18:06, Xie, Huawei wrote: On 3/24/2015 3:44 PM, Linhaifeng wrote: > On 2015/3/24 9:53, Xie, Huawei wrote: >> On 3/24/2015 9:00 AM, Linhaifeng wrote: >>> On 2015/3/23 20:54, Xie, Huawei wrote: We have compiler barrier before and an external function call behind, so we don't need volatile here. Do you meet issue? >>> Tx_q is sometimes stopped when we use virtio_net. Because vhost thought >>> there are no buffers in tx_q and virtio_net >>> though vhost haven't handle all packets so we have to restart VM to >>> restore work. >>> >>> The status in VM is: >>> Mar 18 17:11:10 linux-b2ij kernel: [46337.246687] net eth7: virtnet_poll >>> Mar 18 17:11:10 linux-b2ij kernel: [46337.246690] net eth7: receive_buf >>> Mar 18 17:11:10 linux-b2ij kernel: [46337.246693] net eth7: vi->num=239 >>> Mar 18 17:11:10 linux-b2ij kernel: [46337.246695] net eth7: >>> svq:avail->idx=52939 used->idx=52939 num_free=18 num_added=0 >>> svq->last_used_idx=52820 >>> Mar 18 17:11:10 linux-b2ij kernel: [46337.246699] net eth7: >>> rvq:avail->idx=36215 used->idx=35977 num_free=18 num_added=0 >>> rvq->last_used_idx=35977 >>> Mar 18 17:11:11 linux-b2ij kernel: [46337.901038] net eth7: >>> dev_queue_xmit, qdisc->flags=4, qdisc->state deactiveed=0 >>> Mar 18 17:11:12 linux-b2ij kernel: [46337.901042] net eth7: >>> dev_queue_xmit, txq->state=1, stopped=1 >>> >>> Why compiler barrier not take effect in our case? Is compiler barrier >>> depended on -O3 option? We use -O2 option. >> compiler barrier always works regardless of the optimization option. >> I don't get your story, but the key thing is, do you check the asm code? >> If called from outside as an API, how is it possible it is optimized? >> there is only one update to used->idx in that function. > Do you mean rte_vhost_enqueue_burst also not need cast used->idx to > volatile ? Why not remove it? I checked the code. Seems we can remove. That is another issue. For your issue, you meet problem, and submit this this patch, but i am a bit confused it is the root cause. Do you check the asm code that volatile is optimized? >>> I had wrote a demo try to find out the different between >>> rte_compiler_barrier and volatile. >>> It seems no any effect on rte_compiler_barrier(). >> Haifeng: >> >> I think it doesn't make too much sense to use volatile for local variables. >> >> In our rte_vhost_dequeue_burst, there is one memory write to the >> used->idx, and there is compiler barrier to keep the order. >> Besides, as an API, how could that memory write to be optimized as >> register access? >> >> Even if you call rte_vhost_dequeue_burst in the same src file, which >> means in the same translation unit, there is function call after which >> has side effect, it still couldn't be optimized. >> >> Anyway, could we directly check the asm code of rte_vhost_dequeue_burst >> to see whether it is optimized? > Conclusion is not clear. Is this patch rejected? > > > so far we have no evidence the code has error so will temporarily reject it.
[dpdk-dev] [PATCH v2 1/5] mbuf: fix clone support when application uses private mbuf data
> -Original Message-
> From: Olivier MATZ [mailto:olivier.matz at 6wind.com]
> Sent: Tuesday, March 31, 2015 8:01 PM
> To: Ananyev, Konstantin
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v2 1/5] mbuf: fix clone support when
> application uses private mbuf data
>
> Hi Konstantin,
>
> On 03/31/2015 01:17 AM, Ananyev, Konstantin wrote:
> With this solution, there are 2 options:
> - no mempool modification, so each application/driver has to add
> priv_size bytes to the object to get the mbuf pointer. This does not
> look feasible.
> - change the mempool to support private area before each object. I
> think mempool API is already quite complex, and I think it's not
> the role of the mempool library to provide such features.
> >>>
> >>>
> >>> In fact, I think the changes would be minimal.
> >>> All we have to do, is to make changes in rte_pktmbuf_init():
> >>>
> >>> void
> >>> rte_pktmbuf_init(struct rte_mempool *mp,
> >>> __attribute__((unused)) void *opaque_arg,
> >>> void *_m,
> >>> __attribute__((unused)) unsigned i)
> >>> {
> >>>
> >>> //extract priv_size from mempool (discussed above).
> >>> uint16_t priv_size = rte_mbufpool_get_priv_size(mp);
> >>>
> >>> struct rte_mbuf *m = _m + priv_size;
> >>> uint32_t buf_len = mp->elt_size - sizeof(struct rte_mbuf) -
> >>> priv_size;
> >>>
> >>>
> >>>
> >>>
> >>> With that way priv_size inside mbuf would always be the size its own
> >>> private space,
> >>> for both direct and indirect mbus., so we don't require to set priv_size
> >>> at attach/detach.
> >>> Again RTE_MBUF_TO_BADDR() and RTE_MBUF_FROM_BADDR() would just work
> >>> without any modifications.
> >>
> >> I'm not sure I'm getting it. The argument '_m' of your
> >> rte_pktmbuf_init() is the pointer to the priv data, right?
> >> So it means that the mbuf is located priv_size bytes after.
> >>
> >> The rte_pktmbuf_init() function is called by mempool_create(),
> >> and the _m parameter is a pointer to a mempool object. So
> >> in my understanding, mempool_get() would not return a rte_mbuf
> >> but a pointer to the application private data.
> >
> > Ah my bad, forgot that mempool's obj_init() returns void now :(
> > To make this approach work also need to change it, so it return a pointer
> > to the new object.
> > So, rte_pktmbuf_init() would return m and then in mempool_add_elem():
> >
> > if (obj_init)
> > obj = obj_init(mp, obj_init_arg, obj, obj_idx);
> >
> > rte_ring_sp_enqueue(mp->ring, obj);
>
> Yes, but modififying mempool is what I wanted to avoid for several
> reasons. First, I think that changing the mempool_create() API here
> (actually the obj_init prototype) would impact existing applications.
>
> Also, I'm afraid that storing a different address than the start
> address of the object would have additional impacts. For instance,
> some data is supposed to be stored before the object, see
> __mempool_from_obj() or mempool_obj_audit().
mempool_obj_audit() should be ok, I think, but yes -
rte_mempool_from_obj() would change the behaviour and
can't be used by mempool_obj_audit() anymore.
Ok, I am convinced - let's stick with private space between rte_mbuf and
buf_adddr, as you suggested.
>
> Finally, I believe that mempool is not the proper place to do
> modifications that are only needed for mbufs. If we really want
> to implement mbuf private data in that way, maybe it would be
> better to add a new layer above mempool (a mbuf pool layer).
Not that I am against it, but seems like even more massive change -
every application would need to be changed to use rte_mbufpool_create(), no?
Konstantin
>
>
> Regards
> Olivier
[dpdk-dev] [PATCH v2] mk: fix pdf doc rules order
> -Original Message- > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > Sent: Wednesday, April 1, 2015 1:31 PM > To: dev at dpdk.org > Cc: mukawa at igel.co.jp; Mcnamara, John; De Lara Guarch, Pablo > Subject: [PATCH v2] mk: fix pdf doc rules order > > From: John McNamara > > Re-ordered the guide-pdf-% and guide-% rules to allow the doc-guides-pdf > target to build with make 3.81. It builds unmodified with all later > versions of make. > > Reported-by: Tetsuya Mukawa > Signed-off-by: John McNamara > Signed-off-by: Thomas Monjalon > --- > v2: reorder also clean rules Hi Thomas, That is fine for consistency but there weren't any issues with "make doc-clean" and "make doc-guides-pdf-clean" in the V1 patch/original. But I'm fine with it like this as well. John.
[dpdk-dev] [PATCH] doc: add note for txqflags in testpmd UG
Since txqflags is now set from the default rx/tx configuration, depending on the PMD, it might not be 0. Therefore, user has to overwrite it with --txqflags 0. Signed-off-by: Pablo de Lara --- doc/guides/testpmd_app_ug/run_app.rst |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/doc/guides/testpmd_app_ug/run_app.rst b/doc/guides/testpmd_app_ug/run_app.rst index 6cbbf40..b29c176 100644 --- a/doc/guides/testpmd_app_ug/run_app.rst +++ b/doc/guides/testpmd_app_ug/run_app.rst @@ -405,6 +405,12 @@ They must be separated from the EAL options, shown in the previous section, with Set the hexadecimal bitmask of TX queue flags, where 0 <= N <= 0x7FFF. The default value is 0. +Note:: + +When using hardware offload functions such as vlan, checksum..., +add txqflags=0, since depending on the PMD, +txqflags might be set to a non-zero value. + * --rx-queue-stats-mapping=(port,queue,mapping)[,(port,queue,mapping)] Set the RX queues statistics counters mapping 0 <= mapping <= 15. -- 1.7.4.1
[dpdk-dev] [RFC] Adding multiple device types to DPDK.
Hi all, (hoping format of the text is maintained) Bruce and myself are submitting this RFC in hopes of providing discussion points for the idea. Please do not get carried away with the code included, it was to help everyone understand the proposal/RFC. The RFC is to describe a proposed change we are looking to make to DPDK to add more device types. We would like to add in to DPDK the idea of a generic packet-device or ?pktdev?, which can be thought of as a thin layer for all device classes. For other device types such as potentially a ?cryptodev? or ?dpidev?. One of the main goals is to not effect performance and not require any current application to be modified. The pktdev layer is providing a light framework for developers to add a device to DPDK. Reason for Change - The reason why we are looking to introduce these concepts to DPDK are: * Expand the scope of DPDK so that it can provide APIs for more than just packet acquisition and transmission, but also provide APIs that can be used to work with other hardware and software offloads, such as cryptographic accelerators, or accelerated libraries for cryptographic functions. [The reason why both software and hardware are mentioned is so that the same APIs can be used whether or not a hardware accelerator is actually available]. * Provide a minimal common basis for device abstraction in DPDK, that can be used to unify the different types of packet I/O devices already existing in DPDK. To this end, the ethdev APIs are a good starting point, but the ethdev library contains too many functions which are NIC-specific to be a general-purpose set of APIs across all devices. Note: The idea was previously touched on here: http://permalink.gmane.org/gmane.comp.networking.dpdk.devel/13545 Description of Proposed Change -- The basic idea behind "pktdev" is to abstract out a few common routines and structures/members of structures by starting with ethdev structures as a starting point, cut it down to little more than a few members in each structure then possible add just rx_burst and tx_burst. Then use the structures as a starting point for writing a device type. Currently we have the rx_burst/tx_burst routines moved to the pktdev and it see like move a couple more common functions maybe resaonable. It could be the Rx/Tx routines in pktdev should be left as is, but in the code below is a possible reason to abstract a few routines into a common set of files. >From there, we have the ethdev type which adds in the existing functions specific to Ethernet devices, and also, for example, a cryptodev which may add in functions specific for cryptographic offload. As now, with the ethdev, the specific drivers provide concrete implementations of the functionality exposed by the interface. This hierarchy is shown in the diagram below, using the existing ethdev and ixgbe drivers as a reference, alongside a hypothetical cryptodev class and driver implementation (catchingly called) "X": ,-. | struct rte_pktdev | +-+ | rte_pkt_rx_burst() | .---| rte_pkt_tx_burst() |---. | `-' | | | | | ,---.,--. |struct rte_ethdev || struct rte_cryptodev| +---++--+ | rte_eth_dev_configure() || rte_crypto_init_sym_session()| | rte_eth_allmulticast_enable() || rte_crypto_del_sym_session() | | rte_eth_filter_ctrl() || | `---'`---.--' | | | | ,-'-.,---'--. |struct rte_pmd_ixgbe || struct rte_pmd_X| +---++--+ | .configure -> ixgbe_configure || .init_session -> X_init_ses()| | .tx_burst -> ixgbe_xmit_pkts || .tx_burst -> X_handle_pkts() | `---'`--' We are not attempting to create a real class model here only looking at creating a very basic common set of APIs and structures for other device types. In terms of code changes for this, we obviously need to add in new interface libraries for pktdev and cryptodev. The pktdev library can define a skeleton structure for the first few elements of the nested structures to ensure consistency. Each of the defines below illustrate the common members in device structures, which gives some basic structure the device framework.
[dpdk-dev] [PATCH] eal: rename --lcores option to --threads
Hi Thomas,
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon
> Sent: Tuesday, March 31, 2015 11:34 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH] eal: rename --lcores option to --threads
>
> Threads are no longer strictly assigned to a lcore with a 1:1 map.
> So they really should be called threads.
> The term lcore should be reserved for a physical hyperthreaded CPU part.
>
> This patch only renames the option --lcores to avoid confusion from a
> user perspective. But a deeper cleanup should be done later in EAL:
> e.g. lcore_id should be renamed to thread_id.
>
I don't see much point in such renaming.
As I remember, it was already discussed should we rename 'lcore' to 'lthread'
(or something similar) and the conclusion was to avoid that.
Such renaming would require too much changes across whole DPDK and external
apps, and it seems no real benefit in doing that.
It seems much easier to document the new notion of 'lcore' means.
Again probably 'lcore' is not a best name, but it was there for a while, and
people get used to it.
While 'thread' seems a bit overloaded to me - not clear what exactly we mean
here:
is it an EAL thread, is it just a pthread the user can create on its will?
Konstantin
> Signed-off-by: Thomas Monjalon
> ---
> app/test/test_eal_flags.c | 34 -
> doc/guides/prog_guide/env_abstraction_layer.rst | 25 ---
> doc/guides/testpmd_app_ug/run_app.rst | 10 +--
> lib/librte_eal/common/eal_common_options.c | 96
> -
> lib/librte_eal/common/eal_options.h | 4 +-
> 5 files changed, 84 insertions(+), 85 deletions(-)
>
> diff --git a/app/test/test_eal_flags.c b/app/test/test_eal_flags.c
> index 0352f87..1096bea 100644
> --- a/app/test/test_eal_flags.c
> +++ b/app/test/test_eal_flags.c
> @@ -512,7 +512,7 @@ test_missing_c_flag(void)
>
> /* -c flag but no coremask value */
> const char *argv1[] = { prgname, prefix, mp_flag, "-n", "3", "-c"};
> - /* No -c, -l or --lcores flag at all */
> + /* No -c, -l or --threads flag at all */
> const char *argv2[] = { prgname, prefix, mp_flag, "-n", "3"};
> /* bad coremask value */
> const char *argv3[] = { prgname, prefix, mp_flag,
> @@ -538,37 +538,37 @@ test_missing_c_flag(void)
> const char *argv11[] = { prgname, prefix, mp_flag,
>"-n", "3", "-l", "1-2,3" };
>
> - /* --lcores flag but no lcores value */
> + /* --threads flag but no lcores value */
> const char *argv12[] = { prgname, prefix, mp_flag,
> - "-n", "3", "--lcores" };
> + "-n", "3", "--threads" };
> const char *argv13[] = { prgname, prefix, mp_flag,
> - "-n", "3", "--lcores", " " };
> + "-n", "3", "--threads", " " };
> /* bad lcores value */
> const char *argv14[] = { prgname, prefix, mp_flag,
> - "-n", "3", "--lcores", "1-3-5" };
> + "-n", "3", "--threads", "1-3-5" };
> const char *argv15[] = { prgname, prefix, mp_flag,
> - "-n", "3", "--lcores", "0-1,,2" };
> + "-n", "3", "--threads", "0-1,,2" };
> const char *argv16[] = { prgname, prefix, mp_flag,
> - "-n", "3", "--lcores", "0-,1" };
> + "-n", "3", "--threads", "0-,1" };
> const char *argv17[] = { prgname, prefix, mp_flag,
> - "-n", "3", "--lcores", "(0-,2-4)" };
> + "-n", "3", "--threads", "(0-,2-4)" };
> const char *argv18[] = { prgname, prefix, mp_flag,
> - "-n", "3", "--lcores", "(-1,2)" };
> + "-n", "3", "--threads", "(-1,2)" };
> const char *argv19[] = { prgname, prefix, mp_flag,
> - "-n", "3", "--lcores", "(2-4)@(2-4-6)" };
> + "-n", "3", "--threads", "(2-4)@(2-4-6)" };
> const char *argv20[] = { prgname, prefix, mp_flag,
> - "-n", "3", "--lcores", "(a,2)" };
> + "-n", "3", "--threads", "(a,2)" };
> const char *argv21[] = { prgname, prefix, mp_flag,
> - "-n", "3", "--lcores", "1-3@(1,3)" };
> + "-n", "3", "--threads", "1-3@(1,3)" };
> const char *argv22[] = { prgname, prefix, mp_flag,
> - "-n", "3", "--lcores", "3@((1,3)" };
> + "-n", "3", "--threads", "3@((1,3)" };
> const char *argv23[] = { prgname, prefix, mp_flag,
> - "-n", "3", "--lcores", "(4-7)=(1,3)" };
> + "-n", "3", "--threads", "(4-7)=(1,3)" };
> const char
[dpdk-dev] [PATCH] mk: fix for "make doc-guides-pdf" with make 3.81
Re-ordered the guide-pdf-% and guide-% rules to allow the doc-guides-pdf target to build with make 3.81. It builds unmodified with all later versions of make. Reported-by: Tetsuya Mukawa Signed-off-by: John McNamara --- mk/rte.sdkdoc.mk | 11 ++- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/mk/rte.sdkdoc.mk b/mk/rte.sdkdoc.mk index 5b44083..0b69d99 100644 --- a/mk/rte.sdkdoc.mk +++ b/mk/rte.sdkdoc.mk @@ -94,11 +94,6 @@ guides-pdf-img-clean: $(Q)rm -f $(RTE_SDK)/doc/guides/*/img/*.pdf guides-pdf: $(addprefix guides-pdf-, $(notdir $(RTE_GUIDES:/=))) ; -guides-%: - @echo 'sphinx processing $@...' - $(Q)$(RTE_SPHINX_BUILD) -b $* $(RTE_SPHINX_VERBOSE) \ - -c $(RTE_SDK)/doc/guides $(RTE_SDK)/doc/guides \ - $(RTE_OUTPUT)/doc/$*/guides guides-pdf-%: @echo 'sphinx processing $@...' @@ -112,6 +107,12 @@ guides-pdf-%: $(Q)mv $(RTE_OUTPUT)/doc/pdf/guides/$*/doc.pdf \ $(RTE_OUTPUT)/doc/pdf/guides/$*.pdf +guides-%: + @echo 'sphinx processing $@...' + $(Q)$(RTE_SPHINX_BUILD) -b $* $(RTE_SPHINX_VERBOSE) \ + -c $(RTE_SDK)/doc/guides $(RTE_SDK)/doc/guides \ + $(RTE_OUTPUT)/doc/$*/guides + # Each PDF depends on generated images *.pdf from *.svg $(foreach guide, $(RTE_GUIDES), $(foreach img, $(wildcard $(guide)img/*.svg), \ $(eval guides-pdf-$(notdir $(guide:/=)): $(img:svg=pdf -- 1.8.1.4 Fix for issue: $ ~/tmp/make-3.81/make doc-guides-pdf sphinx processing guides-pdf-freebsd_gsg... Sphinx error: Builder name pdf-freebsd_gsg not registered make[1]: *** [guides-pdf-freebsd_gsg] Error 1 make: *** [doc-guides-pdf] Error 2
[dpdk-dev] [PATCH] doc: add note for txqflags in testpmd UG
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Pablo de Lara > Sent: Wednesday, April 1, 2015 1:10 PM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH] doc: add note for txqflags in testpmd UG > > Since txqflags is now set from the default rx/tx configuration, depending on > the PMD, it might not be 0. > Therefore, user has to overwrite it with --txqflags 0. > > Signed-off-by: Pablo de Lara > --- > doc/guides/testpmd_app_ug/run_app.rst |6 ++ > 1 files changed, 6 insertions(+), 0 deletions(-) > > diff --git a/doc/guides/testpmd_app_ug/run_app.rst > b/doc/guides/testpmd_app_ug/run_app.rst > index 6cbbf40..b29c176 100644 > --- a/doc/guides/testpmd_app_ug/run_app.rst > +++ b/doc/guides/testpmd_app_ug/run_app.rst > @@ -405,6 +405,12 @@ They must be separated from the EAL options, > shown in the previous section, with > Set the hexadecimal bitmask of TX queue flags, where 0 <= N <= > 0x7FFF. > The default value is 0. > > +Note:: > + > +When using hardware offload functions such as vlan, checksum..., > +add txqflags=0, since depending on the PMD, > +txqflags might be set to a non-zero value. > + > * --rx-queue-stats- > mapping=(port,queue,mapping)[,(port,queue,mapping)] > > Set the RX queues statistics counters mapping 0 <= mapping <= 15. > -- > 1.7.4.1 Thanks Pablo that wording is better Acked-by Siobhan Butler
[dpdk-dev] [PATCH] mk: fix for "make doc-guides-pdf" with make 3.81
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of John McNamara > Sent: Wednesday, April 01, 2015 12:33 PM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH] mk: fix for "make doc-guides-pdf" with make > 3.81 > > Re-ordered the guide-pdf-% and guide-% rules to allow > the doc-guides-pdf target to build with make 3.81. It > builds unmodified with all later versions of make. > > Reported-by: Tetsuya Mukawa > Signed-off-by: John McNamara Acked-by: Pablo de Lara
[dpdk-dev] Running DPDK with Docker
On Wed, 1 Apr 2015 17:56:56 + Karmarkar Suyash wrote: > Hi, > > Given the popularity of Docker it would be nice if we can run DPDK inside a > Docker container but the challenge is the igb_uio.ko and rte_kni.ko kernel > modules which need to be compiled with the exact kernel source running on the > host. Are there ways to seamlessly run DPDK with Docker? I came across an > articles about running DPDK with Linux container but still the requirement is > to insert igb_uio. Any plans to make the igb_uio and rte_kni modules as > default modules of Linux source code or any other better > approaches/suggestions ? Thanks. > > http://dpdk.org/ml/archives/dev/2014-October/006373.html > http://permalink.gmane.org/gmane.comp.networking.dpdk.devel/6479 igb_uio and rte_kni are unlikely to be accepted upstream since they have intrinsic security problems. Can you use VFIO?
[dpdk-dev] [PATCH] ixgbe: do not include CRC in Tx byte count
On Wed, 1 Apr 2015 07:45:02 + Thomas Monjalon wrote: > 2015-03-24 23:54, Ananyev, Konstantin: > > From: Stephen Hemminger [mailto:stephen at networkplumber.org] > > > On Mon, 23 Mar 2015 16:45:44 + > > > "Ananyev, Konstantin" wrote: > > > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of stephen at > > > > networkplumber.org > > > > > From: Stephen Hemminger > > > > > > > > > > The ixgbe driver was including CRC in the transmit packet byte > > > > > count, but not for packets received. > > > > > This was notice when forwarding and > > > > > the number of bytes received was greater than the number of bytes > > > > > transmitted > > > > > for the same number of packets. Make the driver behave like other > > > > > virtual devices and not include CRC in byte count. Use the same queue > > > > > counters already computed and used for Rx. > > > > > > > > About RX side stats - as I remember it depends to what value > > > > hw_stip_crc is set at configure(). > > > > If hw_stip_crc==1, then, yes CRC bytes are not included into QBRC > > > > value. > > > > I If hw_stip_crc==0, then CRC bytes are included into QBRC. > > > > > > That is an additional bug! > > > * CRC should never be included in the byte count. > > > This is not how Linux or other drivers report byte count. > > > > I don't have any strong opinion here... > > For me any method (with or without CRC) of counting bytes are ok, as long > > as this method is identical across all PMDs we support. > > Which makes we wonder, what approach other PMDs use? > > > > > > > > * the byte count must be symmetrical Rx == Tx > > > > > > The Brocade router always set strip_crc to 1. So did not see the > > > additional bug > > > of CRC being included in byte count. > > > > Are you going to submit v2, to make Rx==Tx for both cases? > > Any conclusion? > Without update, this patch is going to be dropped. I was hoping Intel would maintain their drivers and fix the issue. Don't have resources to do it across all configurations and hardware, my bet is that this is broken on i40e, igb, e1000 as well.
[dpdk-dev] Cannot build doc using DPDK-2.0.0-rc3
> -Original Message- > From: Masaru Oki [mailto:m-oki at stratosphere.co.jp] > Sent: Wednesday, April 1, 2015 11:14 AM > To: Mcnamara, John > Cc: Tetsuya Mukawa; De Lara Guarch, Pablo; dev at dpdk.org > Subject: Re: [dpdk-dev] Cannot build doc using DPDK-2.0.0-rc3 > > > guide-% rule is selected instead of guide-pdf-% in mk/rte.sdkdoc.mk, I > guess. Hi, Changing the order of the guide-pdf-% and guide-% rules fixes the issue with make 3.81. I'll submit a patch. John
[dpdk-dev] Cannot build doc using DPDK-2.0.0-rc3
> -Original Message- > From: Masaru Oki [mailto:m-oki at stratosphere.co.jp] > Sent: Wednesday, April 1, 2015 11:14 AM > To: Mcnamara, John > Cc: Tetsuya Mukawa; De Lara Guarch, Pablo; dev at dpdk.org > Subject: Re: [dpdk-dev] Cannot build doc using DPDK-2.0.0-rc3 > > Hi, > > guide-% rule is selected instead of guide-pdf-% in mk/rte.sdkdoc.mk, I > guess. Hi, Yes, that is the issue. I see it fail with make 3.81 but not 3.82, which might explain why it works on some systems and not on others. John
[dpdk-dev] Cannot build doc using DPDK-2.0.0-rc3
> -Original Message- > From: Tetsuya Mukawa [mailto:mukawa at igel.co.jp] > Sent: Wednesday, April 1, 2015 10:49 AM > To: De Lara Guarch, Pablo; Mcnamara, John > Cc: dev at dpdk.org > Subject: Re: [dpdk-dev] Cannot build doc using DPDK-2.0.0-rc3 > > I am using Ubuntu14, so package name may be different. > > To make sure, I just installed 'texlive-*', then tried to build doc again. > But I faced the same error. > Anyway, it seems the error comes from my environment, so I will check it > more. Hi, Actually that looks like a Makefile issue rather than a toolchain issue. Sphinx shouldn't be trying to build with a builder called "pdf-freebsd_gsg". It seems that it has picked up the wrong rule. I'll look into it. John
[dpdk-dev] [PATCH] ixgbe: do not include CRC in Tx byte count
2015-03-24 23:54, Ananyev, Konstantin: > From: Stephen Hemminger [mailto:stephen at networkplumber.org] > > On Mon, 23 Mar 2015 16:45:44 + > > "Ananyev, Konstantin" wrote: > > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of stephen at > > > networkplumber.org > > > > From: Stephen Hemminger > > > > > > > > The ixgbe driver was including CRC in the transmit packet byte > > > > count, but not for packets received. > > > > This was notice when forwarding and > > > > the number of bytes received was greater than the number of bytes > > > > transmitted > > > > for the same number of packets. Make the driver behave like other > > > > virtual devices and not include CRC in byte count. Use the same queue > > > > counters already computed and used for Rx. > > > > > > About RX side stats - as I remember it depends to what value hw_stip_crc > > > is set at configure(). > > > If hw_stip_crc==1, then, yes CRC bytes are not included into QBRC value. > > > I If hw_stip_crc==0, then CRC bytes are included into QBRC. > > > > That is an additional bug! > > * CRC should never be included in the byte count. > > This is not how Linux or other drivers report byte count. > > I don't have any strong opinion here... > For me any method (with or without CRC) of counting bytes are ok, as long as > this method is identical across all PMDs we support. > Which makes we wonder, what approach other PMDs use? > > > > > * the byte count must be symmetrical Rx == Tx > > > > The Brocade router always set strip_crc to 1. So did not see the additional > > bug > > of CRC being included in byte count. > > Are you going to submit v2, to make Rx==Tx for both cases? Any conclusion? Without update, this patch is going to be dropped.
[dpdk-dev] Cannot build doc using DPDK-2.0.0-rc3
Hi Tetsuya, > -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Tetsuya Mukawa > Sent: Wednesday, April 01, 2015 10:18 AM > To: Mcnamara, John > Cc: dev at dpdk.org > Subject: [dpdk-dev] Cannot build doc using DPDK-2.0.0-rc3 > > Hi John, > > > It seems after applying following patch, I cannot build doc. > ebf8050 doc: add pdf output > > --- > $ T=x86_64-native-linuxapp-gcc make doc > > (snip) > > lookup cache used 2433/65536 hits=6354 misses=2576 > finished... > sphinx processing guides-html... > sphinx processing guides-pdf-freebsd_gsg... > > Sphinx error: > Builder name pdf-freebsd_gsg not registered > make[1]: *** [guides-pdf-freebsd_gsg] Error 1 > make: *** [doc-all] Error 2 > --- > > Could you please check it? I have no issues building the docs. Do you have all necessary packages for building them? You will need texlive, texlive-latex, texlive-collection-latex, texlive-collection-latexrecommended, texlive-collection-latexextra and texlive-dejavu. Pablo > > Thanks, > Tetsuya
[dpdk-dev] [PATCH v2 0/3] split programmers guide a bit
> -Original Message- > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > Sent: Tuesday, March 31, 2015 1:23 PM > To: Mcnamara, John > Cc: Butler, Siobhan A; Iremonger, Bernard; dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCH v2 0/3] split programmers guide a bit > > 2015-03-31 11:34, Mcnamara, John: > > Any objection to an additional patch to move the figure captions below > > the figures in the docs? > > No objection. > We should use figure:: keyword instead of image:: to add a caption. > > > The caption above the figure was the format used in the initial docs, > > and it looks okay in the HTML output, but in the PDF output it tends > > to get merged into the preceding paragraph and isn't always on the > > same page as the figure. > > Yes, it's a bit strange. > Why moving it below will ensure to keep it in the same page? > I think figure:: keyword may solve it. Hi John, My preference would be to keep the caption above the figure. This was the way it was done in the original 1.7 MSword documents (the starting point for the conversion to rst files). Regards, Bernard
[dpdk-dev] [PATCH] pci: rename passthrough driver to kernel driver
Hello Thomas, On Wed, Apr 1, 2015 at 12:05 AM, Thomas Monjalon wrote: > Kernel driver (kdrv) seems easier to understand than > passthrough driver (pt_driver). It's also more generic > as a PMD could run on top of any PCI kernel driver if > it would offer such support. > > Signed-off-by: Thomas Monjalon > --- > lib/librte_eal/bsdapp/eal/eal_pci.c | 3 +-- > lib/librte_eal/common/include/rte_pci.h | 12 ++-- > lib/librte_eal/linuxapp/eal/eal_pci.c | 33 > - > lib/librte_ether/rte_ethdev.c | 8 > 4 files changed, 27 insertions(+), 29 deletions(-) > This looks ok for me. I suppose you checked it builds fine on both linux and bsd ? Acked-by: David Marchand -- David Marchand
[dpdk-dev] [PATCH] i40e: fix no effect wait_to_complete on link_get
Tested-by: Xiaonan zhang - OS: Fedora21 3.19.1-201.fc21.x86_64 - GCC: gcc version 4.9.1 20140930 (Red Hat 4.9.1-11) (GCC) - CPU: Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz - NIC: Ethernet controller [0200]: Intel Corporation Ethernet Controller X710 for 10GbE SFP+ [8086:1572] (rev 01) - Default x86_64-native-linuxapp-gcc configuration - Total 1 cases, 1 passed, 0 failed - Test case: Used Qos example to verified - Traffic shaping for subport. Check that the subport rate is enforced. Set the subport output rate to x% of line rate (x = 10 .. 100). Set the subport TC limits high (100% line rate each), so they do not constitute limitations. Input traffic is 100% line rate. Different tb period and tb credits, therefore different output rate, are tried: 25%, 50%, 75%, 90% and 100% the lineal rate. (The output for subport is Tb credits per period / Tb period.) The traffic is injected change subport value random. Other parameters are same before tests and they don't change here. Cmdline: ./examples/qos_sched/build/qos_sched -c 0xe -n 4 -- --pfc "0,1,2,3,3" --cfg "/root/profile_sched_pipe_1.cfg" The result is this table: +---+--+ | Subport output rate | Subport output rate | | (% line rate) | (Mpps) | +---+---+--+---+ | Expected | Actual| Expected | Actual| +---+---+--+---+ Signed-off-by: Xiaonan Zhang -Original Message- From: Zhang, Helin Sent: Wednesday, April 01, 2015 10:50 AM To: Liang, Cunming; dev at dpdk.org Cc: Zhang, XiaonanX; Dumitrescu, Cristian Subject: RE: [PATCH] i40e: fix no effect wait_to_complete on link_get > -Original Message- > From: Liang, Cunming > Sent: Wednesday, April 1, 2015 10:34 AM > To: dev at dpdk.org > Cc: Zhang, Helin; Zhang, XiaonanX; Dumitrescu, Cristian; Liang, Cunming > Subject: [PATCH] i40e: fix no effect wait_to_complete on link_get > > API *rte_eth_link_get* expect to call a wait to complete link_update. > That's the difference between *rte_eth_link_get_nowait*. > The patch fixes the issue that i40e link_update ignores the wait_to_complete > flag. > The issue impacts those applications calling rte_eth_link_get to get wrong > intermediate link status. > > Signed-off-by: Cunming Liang Acked-by: Helin Zhang > --- > lib/librte_pmd_i40e/i40e_ethdev.c | 29 +++-- > 1 file changed, 19 insertions(+), 10 deletions(-)
[dpdk-dev] Secondary process crash in rte_eal_init
Hi All, We have a single primary application with multiple secondary applications launched on the same cpu core. When the system boots up for the first time ,the primary comes up followed by the secondary process everything works fine. But in between if I try to restart the secondary processes without restart the primary, the secondary process crashes with the below stack trace. Any idea what is going wrong out here. Stack Trace of the Crash : (gdb) bt #0 0x7f4dad6e01b5 in raise () from /lib/libc.so.6 #1 0x7f4dad6e2fc0 in abort () from /lib/libc.so.6 #2 0x00402545 in __rte_panic () #3 0x007353f4 in rte_eal_init () #4 0x00403133 in main (argc=10, argv=0x7fff2c52fea8) -- Regards, Souvik
[dpdk-dev] [PATCH] i40e: fix no effect wait_to_complete on link_get
> -Original Message- > From: Liang, Cunming > Sent: Wednesday, April 1, 2015 10:34 AM > To: dev at dpdk.org > Cc: Zhang, Helin; Zhang, XiaonanX; Dumitrescu, Cristian; Liang, Cunming > Subject: [PATCH] i40e: fix no effect wait_to_complete on link_get > > API *rte_eth_link_get* expect to call a wait to complete link_update. > That's the difference between *rte_eth_link_get_nowait*. > The patch fixes the issue that i40e link_update ignores the wait_to_complete > flag. > The issue impacts those applications calling rte_eth_link_get to get wrong > intermediate link status. > > Signed-off-by: Cunming Liang Acked-by: Helin Zhang > --- > lib/librte_pmd_i40e/i40e_ethdev.c | 29 +++-- > 1 file changed, 19 insertions(+), 10 deletions(-)
[dpdk-dev] [PATCH] pci: rename passthrough driver to kernel driver
On 4/1/2015 6:07 AM, Thomas Monjalon wrote:
> Kernel driver (kdrv) seems easier to understand than
> passthrough driver (pt_driver). It's also more generic
> as a PMD could run on top of any PCI kernel driver if
> it would offer such support.
>
> Signed-off-by: Thomas Monjalon
> ---
Acked-by: Michael Qiu
> lib/librte_eal/bsdapp/eal/eal_pci.c | 3 +--
> lib/librte_eal/common/include/rte_pci.h | 12 ++--
> lib/librte_eal/linuxapp/eal/eal_pci.c | 33
> -
> lib/librte_ether/rte_ethdev.c | 8
> 4 files changed, 27 insertions(+), 29 deletions(-)
>
> diff --git a/lib/librte_eal/bsdapp/eal/eal_pci.c
> b/lib/librte_eal/bsdapp/eal/eal_pci.c
> index fe3ef86..30f0232 100644
> --- a/lib/librte_eal/bsdapp/eal/eal_pci.c
> +++ b/lib/librte_eal/bsdapp/eal/eal_pci.c
> @@ -356,8 +356,7 @@ pci_scan_one(int dev_pci_fd, struct pci_conf *conf)
> TAILQ_INSERT_BEFORE(dev2, dev, next);
> return 0;
> } else { /* already registered */
> - /* update pt_driver */
> - dev2->pt_driver = dev->pt_driver;
> + dev2->kdrv = dev->kdrv;
> dev2->max_vfs = dev->max_vfs;
> memmove(dev2->mem_resource,
> dev->mem_resource,
> diff --git a/lib/librte_eal/common/include/rte_pci.h
> b/lib/librte_eal/common/include/rte_pci.h
> index 995f814..785852d 100644
> --- a/lib/librte_eal/common/include/rte_pci.h
> +++ b/lib/librte_eal/common/include/rte_pci.h
> @@ -142,11 +142,11 @@ struct rte_pci_addr {
>
> struct rte_devargs;
>
> -enum rte_pt_driver {
> - RTE_PT_UNKNOWN = 0,
> - RTE_PT_IGB_UIO = 1,
> - RTE_PT_VFIO = 2,
> - RTE_PT_UIO_GENERIC = 3,
> +enum rte_kernel_driver {
> + RTE_KDRV_UNKNOWN = 0,
> + RTE_KDRV_IGB_UIO,
> + RTE_KDRV_VFIO,
> + RTE_KDRV_UIO_GENERIC,
> };
>
> /**
> @@ -162,7 +162,7 @@ struct rte_pci_device {
> uint16_t max_vfs; /**< sriov enable if not zero */
> int numa_node; /**< NUMA node connection */
> struct rte_devargs *devargs;/**< Device user arguments */
> - enum rte_pt_driver pt_driver; /**< Driver of passthrough */
> + enum rte_kernel_driver kdrv;/**< Kernel driver passthrough
> */
> };
>
> /** Any PCI device identifier (vendor, device, ...) */
> diff --git a/lib/librte_eal/linuxapp/eal/eal_pci.c
> b/lib/librte_eal/linuxapp/eal/eal_pci.c
> index 83c589e..9cb0ffd 100644
> --- a/lib/librte_eal/linuxapp/eal/eal_pci.c
> +++ b/lib/librte_eal/linuxapp/eal/eal_pci.c
> @@ -340,19 +340,19 @@ pci_scan_one(const char *dirname, uint16_t domain,
> uint8_t bus,
> ret = pci_get_kernel_driver_by_path(filename, driver);
> if (!ret) {
> if (!strcmp(driver, "vfio-pci"))
> - dev->pt_driver = RTE_PT_VFIO;
> + dev->kdrv = RTE_KDRV_VFIO;
> else if (!strcmp(driver, "igb_uio"))
> - dev->pt_driver = RTE_PT_IGB_UIO;
> + dev->kdrv = RTE_KDRV_IGB_UIO;
> else if (!strcmp(driver, "uio_pci_generic"))
> - dev->pt_driver = RTE_PT_UIO_GENERIC;
> + dev->kdrv = RTE_KDRV_UIO_GENERIC;
> else
> - dev->pt_driver = RTE_PT_UNKNOWN;
> + dev->kdrv = RTE_KDRV_UNKNOWN;
> } else if (ret < 0) {
> RTE_LOG(ERR, EAL, "Fail to get kernel driver\n");
> free(dev);
> return -1;
> } else
> - dev->pt_driver = RTE_PT_UNKNOWN;
> + dev->kdrv = RTE_KDRV_UNKNOWN;
>
> /* device is valid, add in list (sorted) */
> if (TAILQ_EMPTY(_device_list)) {
> @@ -370,8 +370,7 @@ pci_scan_one(const char *dirname, uint16_t domain,
> uint8_t bus,
> TAILQ_INSERT_BEFORE(dev2, dev, next);
> return 0;
> } else { /* already registered */
> - /* update pt_driver */
> - dev2->pt_driver = dev->pt_driver;
> + dev2->kdrv = dev->kdrv;
> dev2->max_vfs = dev->max_vfs;
> memmove(dev2->mem_resource,
> dev->mem_resource,
> @@ -570,20 +569,20 @@ pci_map_device(struct rte_pci_device *dev)
> int ret = -1;
>
> /* try mapping the NIC resources using VFIO if it exists */
> - switch (dev->pt_driver) {
> - case RTE_PT_VFIO:
> + switch (dev->kdrv) {
> + case RTE_KDRV_VFIO:
> #ifdef VFIO_PRESENT
> if (pci_vfio_is_enabled())
> ret = pci_vfio_map_resource(dev);
> #endif
>
[dpdk-dev] [PATCH] i40e: fix the issue reported by klocwork
Hi Thomas Actually it is a bug fix. It would be better to be put in R2.0. It may not crash, as it just possibly read something out of range. I am waiting the test report from our validation team, and then I will merge that. Thanks for your patience! Regards, Helin > -Original Message- > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > Sent: Tuesday, March 31, 2015 6:28 PM > To: Zhang, Helin > Cc: dev at dpdk.org; Wu, Jingjing > Subject: Re: [dpdk-dev] [PATCH] i40e: fix the issue reported by klocwork > > Hi Helin, > > > > Klocwork reports array 'src_offset' may use index 16. > > > In function i40e_srcoff_to_flx_pit, index j + 1 can reach > > > I40E_FDIR_MAX_FLEX_LEN. > > > This patch fixes this issue to avoid array bound. > > > > > > Signed-off-by: Jingjing Wu > > Acked-by: Helin Zhang > > Please confirm it's a real bug which needs to be fixed in 2.0, and/or you are > sure > this patch won't bring a new problem. > > Thanks
[dpdk-dev] [PATCH] eal: rename --lcores option to --threads
Threads are no longer strictly assigned to a lcore with a 1:1 map.
So they really should be called threads.
The term lcore should be reserved for a physical hyperthreaded CPU part.
This patch only renames the option --lcores to avoid confusion from a
user perspective. But a deeper cleanup should be done later in EAL:
e.g. lcore_id should be renamed to thread_id.
Signed-off-by: Thomas Monjalon
---
app/test/test_eal_flags.c | 34 -
doc/guides/prog_guide/env_abstraction_layer.rst | 25 ---
doc/guides/testpmd_app_ug/run_app.rst | 10 +--
lib/librte_eal/common/eal_common_options.c | 96 -
lib/librte_eal/common/eal_options.h | 4 +-
5 files changed, 84 insertions(+), 85 deletions(-)
diff --git a/app/test/test_eal_flags.c b/app/test/test_eal_flags.c
index 0352f87..1096bea 100644
--- a/app/test/test_eal_flags.c
+++ b/app/test/test_eal_flags.c
@@ -512,7 +512,7 @@ test_missing_c_flag(void)
/* -c flag but no coremask value */
const char *argv1[] = { prgname, prefix, mp_flag, "-n", "3", "-c"};
- /* No -c, -l or --lcores flag at all */
+ /* No -c, -l or --threads flag at all */
const char *argv2[] = { prgname, prefix, mp_flag, "-n", "3"};
/* bad coremask value */
const char *argv3[] = { prgname, prefix, mp_flag,
@@ -538,37 +538,37 @@ test_missing_c_flag(void)
const char *argv11[] = { prgname, prefix, mp_flag,
"-n", "3", "-l", "1-2,3" };
- /* --lcores flag but no lcores value */
+ /* --threads flag but no lcores value */
const char *argv12[] = { prgname, prefix, mp_flag,
-"-n", "3", "--lcores" };
+"-n", "3", "--threads" };
const char *argv13[] = { prgname, prefix, mp_flag,
-"-n", "3", "--lcores", " " };
+"-n", "3", "--threads", " " };
/* bad lcores value */
const char *argv14[] = { prgname, prefix, mp_flag,
-"-n", "3", "--lcores", "1-3-5" };
+"-n", "3", "--threads", "1-3-5" };
const char *argv15[] = { prgname, prefix, mp_flag,
-"-n", "3", "--lcores", "0-1,,2" };
+"-n", "3", "--threads", "0-1,,2" };
const char *argv16[] = { prgname, prefix, mp_flag,
-"-n", "3", "--lcores", "0-,1" };
+"-n", "3", "--threads", "0-,1" };
const char *argv17[] = { prgname, prefix, mp_flag,
-"-n", "3", "--lcores", "(0-,2-4)" };
+"-n", "3", "--threads", "(0-,2-4)" };
const char *argv18[] = { prgname, prefix, mp_flag,
-"-n", "3", "--lcores", "(-1,2)" };
+"-n", "3", "--threads", "(-1,2)" };
const char *argv19[] = { prgname, prefix, mp_flag,
-"-n", "3", "--lcores", "(2-4)@(2-4-6)" };
+"-n", "3", "--threads", "(2-4)@(2-4-6)" };
const char *argv20[] = { prgname, prefix, mp_flag,
-"-n", "3", "--lcores", "(a,2)" };
+"-n", "3", "--threads", "(a,2)" };
const char *argv21[] = { prgname, prefix, mp_flag,
-"-n", "3", "--lcores", "1-3@(1,3)" };
+"-n", "3", "--threads", "1-3@(1,3)" };
const char *argv22[] = { prgname, prefix, mp_flag,
-"-n", "3", "--lcores", "3@((1,3)" };
+"-n", "3", "--threads", "3@((1,3)" };
const char *argv23[] = { prgname, prefix, mp_flag,
-"-n", "3", "--lcores", "(4-7)=(1,3)" };
+"-n", "3", "--threads", "(4-7)=(1,3)" };
const char *argv24[] = { prgname, prefix, mp_flag,
-"-n", "3", "--lcores", "[4-7]@(1,3)" };
+"-n", "3", "--threads", "[4-7]@(1,3)" };
/* sanity check of tests - valid lcores value */
const char *argv25[] = { prgname, prefix, mp_flag,
-"-n", "3", "--lcores",
+"-n", "3", "--threads",
"0-1,2@(5-7),(3-5)@(0,2),(0,6),7"};
if (launch_proc(argv1) == 0
@@ -601,7 +601,7 @@ test_missing_c_flag(void)
return -1;
}
- /* start --lcores tests */
+ /* start --threads tests */
if (launch_proc(argv12) == 0 || launch_proc(argv13) == 0 ||
launch_proc(argv14) == 0 || launch_proc(argv15) == 0 ||
launch_proc(argv16) == 0 || launch_proc(argv17) == 0 ||
diff --git a/doc/guides/prog_guide/env_abstraction_layer.rst
[dpdk-dev] [PATCH] pci: rename passthrough driver to kernel driver
Kernel driver (kdrv) seems easier to understand than
passthrough driver (pt_driver). It's also more generic
as a PMD could run on top of any PCI kernel driver if
it would offer such support.
Signed-off-by: Thomas Monjalon
---
lib/librte_eal/bsdapp/eal/eal_pci.c | 3 +--
lib/librte_eal/common/include/rte_pci.h | 12 ++--
lib/librte_eal/linuxapp/eal/eal_pci.c | 33 -
lib/librte_ether/rte_ethdev.c | 8
4 files changed, 27 insertions(+), 29 deletions(-)
diff --git a/lib/librte_eal/bsdapp/eal/eal_pci.c
b/lib/librte_eal/bsdapp/eal/eal_pci.c
index fe3ef86..30f0232 100644
--- a/lib/librte_eal/bsdapp/eal/eal_pci.c
+++ b/lib/librte_eal/bsdapp/eal/eal_pci.c
@@ -356,8 +356,7 @@ pci_scan_one(int dev_pci_fd, struct pci_conf *conf)
TAILQ_INSERT_BEFORE(dev2, dev, next);
return 0;
} else { /* already registered */
- /* update pt_driver */
- dev2->pt_driver = dev->pt_driver;
+ dev2->kdrv = dev->kdrv;
dev2->max_vfs = dev->max_vfs;
memmove(dev2->mem_resource,
dev->mem_resource,
diff --git a/lib/librte_eal/common/include/rte_pci.h
b/lib/librte_eal/common/include/rte_pci.h
index 995f814..785852d 100644
--- a/lib/librte_eal/common/include/rte_pci.h
+++ b/lib/librte_eal/common/include/rte_pci.h
@@ -142,11 +142,11 @@ struct rte_pci_addr {
struct rte_devargs;
-enum rte_pt_driver {
- RTE_PT_UNKNOWN = 0,
- RTE_PT_IGB_UIO = 1,
- RTE_PT_VFIO = 2,
- RTE_PT_UIO_GENERIC = 3,
+enum rte_kernel_driver {
+ RTE_KDRV_UNKNOWN = 0,
+ RTE_KDRV_IGB_UIO,
+ RTE_KDRV_VFIO,
+ RTE_KDRV_UIO_GENERIC,
};
/**
@@ -162,7 +162,7 @@ struct rte_pci_device {
uint16_t max_vfs; /**< sriov enable if not zero */
int numa_node; /**< NUMA node connection */
struct rte_devargs *devargs;/**< Device user arguments */
- enum rte_pt_driver pt_driver; /**< Driver of passthrough */
+ enum rte_kernel_driver kdrv;/**< Kernel driver passthrough
*/
};
/** Any PCI device identifier (vendor, device, ...) */
diff --git a/lib/librte_eal/linuxapp/eal/eal_pci.c
b/lib/librte_eal/linuxapp/eal/eal_pci.c
index 83c589e..9cb0ffd 100644
--- a/lib/librte_eal/linuxapp/eal/eal_pci.c
+++ b/lib/librte_eal/linuxapp/eal/eal_pci.c
@@ -340,19 +340,19 @@ pci_scan_one(const char *dirname, uint16_t domain,
uint8_t bus,
ret = pci_get_kernel_driver_by_path(filename, driver);
if (!ret) {
if (!strcmp(driver, "vfio-pci"))
- dev->pt_driver = RTE_PT_VFIO;
+ dev->kdrv = RTE_KDRV_VFIO;
else if (!strcmp(driver, "igb_uio"))
- dev->pt_driver = RTE_PT_IGB_UIO;
+ dev->kdrv = RTE_KDRV_IGB_UIO;
else if (!strcmp(driver, "uio_pci_generic"))
- dev->pt_driver = RTE_PT_UIO_GENERIC;
+ dev->kdrv = RTE_KDRV_UIO_GENERIC;
else
- dev->pt_driver = RTE_PT_UNKNOWN;
+ dev->kdrv = RTE_KDRV_UNKNOWN;
} else if (ret < 0) {
RTE_LOG(ERR, EAL, "Fail to get kernel driver\n");
free(dev);
return -1;
} else
- dev->pt_driver = RTE_PT_UNKNOWN;
+ dev->kdrv = RTE_KDRV_UNKNOWN;
/* device is valid, add in list (sorted) */
if (TAILQ_EMPTY(_device_list)) {
@@ -370,8 +370,7 @@ pci_scan_one(const char *dirname, uint16_t domain, uint8_t
bus,
TAILQ_INSERT_BEFORE(dev2, dev, next);
return 0;
} else { /* already registered */
- /* update pt_driver */
- dev2->pt_driver = dev->pt_driver;
+ dev2->kdrv = dev->kdrv;
dev2->max_vfs = dev->max_vfs;
memmove(dev2->mem_resource,
dev->mem_resource,
@@ -570,20 +569,20 @@ pci_map_device(struct rte_pci_device *dev)
int ret = -1;
/* try mapping the NIC resources using VFIO if it exists */
- switch (dev->pt_driver) {
- case RTE_PT_VFIO:
+ switch (dev->kdrv) {
+ case RTE_KDRV_VFIO:
#ifdef VFIO_PRESENT
if (pci_vfio_is_enabled())
ret = pci_vfio_map_resource(dev);
#endif
break;
- case RTE_PT_IGB_UIO:
- case RTE_PT_UIO_GENERIC:
+ case RTE_KDRV_IGB_UIO:
+ case RTE_KDRV_UIO_GENERIC:
/* map resources for
