[dpdk-dev] RTE CRC hash function
10/12/2013 04:17, Pashupati Kumar:
> I am looking at the DPDK implementation for the CRC hash function using
> Intel intrinsics. Shouldn't the order of the arguments being passed to
> _mm_crc32_u32 be reversed ? http://dpdk.org/doc/api/rte__hash__crc_8h.html
>
> For a quick reference, here is the code with Actual and Modified calls.
> static inline uint32_t
> rte_hash_crc_4byte(uint32_t data, uint32_t init_val)
> {
> Actual > return _mm_crc32_u32(data, init_val);
> Modified > return _mm_crc32_u32(init_val, data);
> }
It is now fixed by this commit:
http://dpdk.org/browse/dpdk/commit/?id=65b0663b7f32e4157b71dc14a016215e1bc63157
Thanks for reporting
--
Thomas
[dpdk-dev] [PATCH v3] timer: add new rte_rdtsc_precise function
19/02/2014 17:46, Didier Pallard: > According to Intel Developer's Manual: > > "The RDTSC instruction is not a serializing instruction. It does not > necessarily wait until all previous instructions have been executed before > reading the counter. Simi- larly, subsequent instructions may begin > execution before the read operation is performed. If software requires > RDTSC to be executed only after all previous instruc- tions have completed > locally, it can either use RDTSCP (if the processor supports that > instruction) or execute the sequence LFENCE;RDTSC." > > So add a rte_rdtsc_precise function that do a memory barrier before rdtsc > to synchronize operations and ensure that the TSC read is done at the > expected place. > > Signed-off-by: Didier Pallard > --- > > Call rte_mb() and rte_rdtsc() rather than duplicating rte_rdtsc function. > Use r/w memory barrier instead of lfence to serialize both load and stores. Acked and applied. Thanks to all -- Thomas
[dpdk-dev] [dpdk-announce] DPDK 1.5.2r2 released
The new release can be downloaded here: http://dpdk.org/browse/dpdk/tag/?id=v1.5.2r2 Changelog - fix for: * RSS in testpmd - enhancements: * kvargs (generic key/value configuration) * option --create-uio-dev * interface index in pcap PMD * precise TSC * potential CRC boost Thank you to everyone, -- Thomas
[dpdk-dev] [RFC PATCH 2/2] ixgbe: release software locked semaphores on initialization
Hi,
Well, about ixgbe, you're right, i didn't notice that the
ixgbe_release_swfw_sync_X540 function is releasing the SMBI lock, even
if it is not the owner.
I'm not sure it is really safe to do that, but it may allow to release
the locks from outside the base driver in all cases using only
ixgbe_acquire/release_swfw_semaphore API functions.
for igb, in my tests, i found that i had to put lock release between
e1000_init_mac_params and e1000_init_nvm_params because all necessary
setup was not done
in hw structure before e1000_init_mac_params call (so
e1000_setup_init_funcs(hw, FALSE) was not enough to have all settings
done to be able to reset the locks).
But perhaps it may be overcome by a call to another exported function of
the API. I think that what i was needing is a call to
mac->ops.set_lan_id(hw) that is also done
in e1000_get_bus_info_pcie_generic function. So something like that
should work:
e1000_setup_init_funcs(hw, FALSE);
e1000_get_bus_info(hw);
e1000_reset_swfw_lock(hw);
e1000_setup_init_funcs(hw, TRUE);
I will try this patch.
thanks
On 02/25/2014 01:57 AM, Ananyev, Konstantin wrote:
> Hi,
> About e1000 - I suppose you refer to the
> eth_igb_dev_init()->e1000_setup_init_funcs(hw, TRUE)->
> e1000_init_nvm_params(hw)?
> If so, I suppose we can do something like that to overcome it:
> e1000_setup_init_funcs(hw, FALSE);
> e1000_reset_swfw_lock(hw);
> e1000_setup_init_funcs(hw, TRUE);
> ?
> First setup_init_funcs() would just setup hw func pointers and wouldn't call
> e1000_init_nvm_params/ e1000_init_phy_params.
> Then we reset the lock, then call setup_funcs once again - that time it would
> read/write HW regs.
> Konstantin
>
> -Original Message-
> From: didier.pallard [mailto:didier.pallard at 6wind.com]
> Sent: Monday, February 24, 2014 2:19 PM
> To: Ananyev, Konstantin
> Cc: Thomas Monjalon; dev at dpdk.org
> Subject: Re: [dpdk-dev] [RFC PATCH 2/2] ixgbe: release software locked
> semaphores on initialization
>
> Hi,
>
> The patch (or some derivative that do the same result) should probably rather
> be integrated in base driver.
>
> For IGB implementation, it is not possible to extract patch from base driver,
> since lock release should be done before calls to e1000_init_nvm_params or
> e1000_init_phy_params that use the potentially stuck locks and after enough
> function pointers fields are filled by e1000_setup_init_funcs to have
> functions to access the hardware.
> For ixgbe, it may be possible on 82598/82599 using ixgbe_xxx_swfw_semaphore
> to do the job from outside the base driver, assuming that no lock will never
> be taken by the base driver before the return of ixgbe_init_shared_code
> function. But it is not be possible on X540, since this implementation does
> not use the ixgbe_get_eeprom_semaphore generic function that automatically
> release the SMBI lock on timeout; So the release of this lock should be done
> using ixgbe_release_swfw_sync_semaphore that is not accessible through the
> API.
>
> didier
>
>
> On 02/21/2014 05:30 PM, Ananyev, Konstantin wrote:
>> To be more specific, I am talking about something like the patch below.
>> It is just a copy-paste of your fix, but implemented and called from
>> ixgbe_ethdev.c Konstantin
>>
>> diff --git a/lib/librte_pmd_ixgbe/ixgbe_ethdev.c
>> b/lib/librte_pmd_ixgbe/ixgbe_et hdev.c index 7e068c2..5d8744a 100644
>> --- a/lib/librte_pmd_ixgbe/ixgbe_ethdev.c
>> +++ b/lib/librte_pmd_ixgbe/ixgbe_ethdev.c
>> @@ -561,6 +561,42 @@ ixgbe_dcb_init(struct ixgbe_hw *hw,struct
>> ixgbe_dcb_config
>> *dcb_config)
>> }
>>}
>>
>> +static void
>> +ixgbe_swfw_lock_reset(struct ixgbe_hw *hw) {
>> + uint16_t mask;
>> +
>> + /* Get bus info */
>> + hw->mac.ops.get_bus_info(hw);
>> +
>> + /* Ensure that all locks are released before first NVM or PHY
>> + access */
>> +
>> + /*
>> +* Phy lock should not fail in this early stage. If this is the case,
>> +* it is due to an improper exit of the application.
>> +* So force the release of the faulty lock. Release of common lock
>> +* is done automatically by swfw_sync function.
>> +*/
>> + mask = IXGBE_GSSR_PHY0_SM << hw->bus.func;
>> + if (hw->mac.ops.acquire_swfw_sync(hw, mask) < 0) {
>> + DEBUGOUT1("SWFW phy%d lock released", hw->bus.func);
>> + }
>> + hw->mac.ops.release_swfw_sync(hw, mask);
>> +
>> + /*
>> +* Those one are more tricky since they are common to all ports; but
>> +* swfw_sync retries last long enough (1s) to be almost sure that if
>> +* lock can not be taken it is due to an improper lock of the
>> +* semaphore.
>> +*/
>> + mask = IXGBE_GSSR_EEP_SM | IXGBE_GSSR_MAC_CSR_SM |
>> IXGBE_GSSR_SW_MNG_SM;
>> + if (hw->mac.ops.acquire_swfw_sync(hw, mask) < 0) {
>> + DEBUGOUT("SWFW common locks released");
>> + }
>> + hw->mac.ops.release_swfw_sync(hw, mask
[dpdk-dev] Unusable interfaces although apparently attached to IGB_UIO
Hi,
>From the log it seems that it is failing at:
ixgbe_reset_pipeline_82599(struct ixgbe_hw *hw)
{
...
IXGBE_WRITE_REG(hw, IXGBE_AUTOC, autoc_reg ^ IXGBE_AUTOC_LMS_1G_AN);
/* Wait for AN to leave state 0 */
for (i = 0; i < 10; i++) {
msec_delay(4);
anlp1_reg = IXGBE_READ_REG(hw, IXGBE_ANLP1);
if (anlp1_reg & IXGBE_ANLP1_AN_STATE_MASK)
break;
}
if (!(anlp1_reg & IXGBE_ANLP1_AN_STATE_MASK)) {
DEBUGOUT("auto negotiation not completed\n");
ret_val = IXGBE_ERR_RESET_FAILED;
goto reset_pipeline_out;
}
I personally never experienced such problem, but I saw mails from other people
at dpdk.org complaining about the similiar problem:
http://search.gmane.org/?query=ixgbe_reset_pipeline_82599&group=gmane.comp.networking.dpdk.devel
As I remember, some of them just increased timeout and/or number of iterations
in the loop above and that made the problem go away.
Could you give it a try to see would it help?
Konstantin
-Original Message-
From: Marc Sune [mailto:marc.s...@bisdn.de]
Sent: Tuesday, February 25, 2014 1:28 PM
To: Ananyev, Konstantin
Cc:
Subject: Re: [dpdk-dev] Unusable interfaces although apparently attached to
IGB_UIO
Thank you,
This is the summary:
9241 PMD: ixgbe_reset_pipeline_82599(): auto negotiation not completed
9242
9243 PMD: ixgbe_setup_sfp_modules_82599(): sfp module setup not complete
9244
9245 PMD: ixgbe_check_mac_link_generic(): ixgbe_check_mac_link_generic
9246 PMD: ixgbe_get_mac_addr_generic(): ixgbe_get_mac_addr_generic
9247 PMD: ixgbe_init_rx_addrs_generic(): ixgbe_init_rx_addrs_generic
9248 PMD: ixgbe_validate_mac_addr(): ixgbe_validate_mac_addr
9249 PMD: ixgbe_validate_mac_addr(): MAC address is all zeros
9250
9251 PMD: ixgbe_get_mac_addr_generic(): ixgbe_get_mac_addr_generic
9252 PMD: ixgbe_init_rx_addrs_generic(): Keeping Current RAR0 Addr =90
E2 BA
9253 PMD: ixgbe_init_rx_addrs_generic(): 00 5F E5
9254
9255 PMD: ixgbe_init_rx_addrs_generic(): Clearing RAR[1-127]
9256
9257 PMD: ixgbe_init_rx_addrs_generic(): Clearing MTA
9258
9259 PMD: ixgbe_init_uta_tables_generic(): ixgbe_init_uta_tables_generic
9260 PMD: ixgbe_init_uta_tables_generic(): Clearing UTA
9261
9262 PMD: ixgbe_get_san_mac_addr_generic(): ixgbe_get_san_mac_addr_generic
9263 PMD: ixgbe_get_san_mac_addr_offset(): ixgbe_get_san_mac_addr_offset
9264 PMD: ixgbe_read_eeprom_82599(): ixgbe_read_eeprom_82599
9265 PMD: ixgbe_read_eerd_buffer_generic(): ixgbe_read_eerd_buffer_generic
9266 PMD: ixgbe_init_eeprom_params_generic():
ixgbe_init_eeprom_params_generic
9267 PMD: ixgbe_poll_eerd_eewr_done(): ixgbe_poll_eerd_eewr_done
9268 PMD: ixgbe_set_lan_id_multi_port_pcie():
ixgbe_set_lan_id_multi_port_pcie
9269 PMD: ixgbe_read_eeprom_82599(): ixgbe_read_eeprom_82599
9270 PMD: ixgbe_read_eerd_buffer_generic(): ixgbe_read_eerd_buffer_generic
9271 PMD: ixgbe_init_eeprom_params_generic():
ixgbe_init_eeprom_params_generic
9272 PMD: ixgbe_poll_eerd_eewr_done(): ixgbe_poll_eerd_eewr_done
9273 PMD: ixgbe_read_eeprom_82599(): ixgbe_read_eeprom_82599
9274 PMD: ixgbe_read_eerd_buffer_generic(): ixgbe_read_eerd_buffer_generic
9275 PMD: ixgbe_init_eeprom_params_generic():
ixgbe_init_eeprom_params_generic
9276 PMD: ixgbe_poll_eerd_eewr_done(): ixgbe_poll_eerd_eewr_done
9277 PMD: ixgbe_read_eeprom_82599(): ixgbe_read_eeprom_82599
9278 PMD: ixgbe_read_eerd_buffer_generic(): ixgbe_read_eerd_buffer_generic
9279 PMD: ixgbe_init_eeprom_params_generic():
ixgbe_init_eeprom_params_generic
9280 PMD: ixgbe_poll_eerd_eewr_done(): ixgbe_poll_eerd_eewr_done
9281 PMD: ixgbe_validate_mac_addr(): ixgbe_validate_mac_addr
9282 PMD: ixgbe_set_rar_generic(): ixgbe_set_rar_generic
9283 PMD: ixgbe_set_vmdq_generic(): ixgbe_set_vmdq_generic
9284 PMD: ixgbe_get_wwn_prefix_generic(): ixgbe_get_wwn_prefix_generic
9285 PMD: ixgbe_read_eeprom_82599(): ixgbe_read_eeprom_82599
9286 PMD: ixgbe_read_eerd_buffer_generic(): ixgbe_read_eerd_buffer_generic
9287 PMD: ixgbe_init_eeprom_params_generic():
ixgbe_init_eeprom_params_generic
9288 PMD: ixgbe_poll_eerd_eewr_done(): ixgbe_poll_eerd_eewr_done
9289 PMD: ixgbe_get_media_type_82599(): ixgbe_get_media_type_82599
9290 PMD: eth_ixgbe_dev_init(): Hardware Initialization Failure: -30
A quick grep over the DPDK code;
58:84221:lib/librte_pmd_ixgbe/ixgbe/ixgbe_type.h:3189:#define
IXGBE_ERR_SFP_SETUP_NOT_COMPLETE-30
It turns out that the 1G ports are also using SFPs, so this may explain why in
both 1g and 10g ports the same behaviour happens.
Any idea?
Thank you and regards
marc
On 25/02/14 14:00, Ananyev, Konstantin wrote:
> Hi,
>
> Probably try to rebuild with CONFIG_RTE_LIBRTE_IXGBE_DEBUG_*=y and rerun?
> Might be it would give you some insight what is going wrong.
>
> Konstantin
>
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Marc Sune
> Sent: Tuesday, February 25, 2014 12:20 PM
> To:
> Subject: [dpdk
[dpdk-dev] [PATCH 03/16] pkg: add recipe for RPM
On 02/04/2014 04:54 PM, Thomas Monjalon wrote:
> Packages can be built with:
> RPM_BUILD_NCPUS=8 rpmbuild -ta dpdk-1.5.2r2.tar.gz
>
> There are packages for runtime, static libraries and development.
> Once devel package installed, it can be used like this:
> make -C /usr/share/dpdk/examples/helloworld RTE_SDK=/usr/share/dpdk
>
> Signed-off-by: Thomas Monjalon
Thanks for getting this started! Some comments below. I'll be glad to
help pushing this into Fedora.
> +Name: dpdk
> +Version: 1.5.2r1
> +Release: 1
What kind of upgrade strategy do you have in mind?
I'm raising this because Fedora and other distributions will require
a unique package name for every version of the package that is not
backwards compatible.
Typically libraries provide backwards compatible within a major release,
i.e. all 1.x.x releases would be compatible. I realize that this might
not be applicable yet but maybe 1.5.x?
Depending on the versioning schema the name would be dpdk15, dpdk16, ...
or dpdk152, dpdk153, ...
> +BuildRequires: kernel-devel, kernel-headers, doxygen
Is a python environment required as well?
> +%description
> +Dummy main package. Make only subpackages.
I would just call the main package "libdpdk152" so you don't have to
repeat the encoding versioning in all the subpackages.
> +
> +%package core-runtime
What about calling it just "libdpdk"?
> +Summary: Intel(r) Data Plane Development Kit core for runtime
> +%description core-runtime
> +Intel(r) DPDK runtime includes kernel modules, core libraries and tools.
> +testpmd application allows to test fast packet processing environments
> +on x86 platforms. For instance, it can be used to check that environment
> +can support fast path applications such as 6WINDGate, pktgen, rumptcpip, etc.
> +More libraries are available as extensions in other packages.
> +
> +%package core-static
Based on the above: "libdpdk-static"
Packages that link against dpdk statically will do:
BuildRequire: libdpdk152-static
> +%files core-runtime
> +%dir %{datadir}
> +%{datadir}/config
> +%{datadir}/tools
> +%{moddir}/*
> +%{_sbindir}/*
> +%{_bindir}/*
> +%{_libdir}/*.so
This brings up the question of multiple parallel DPDK installations.
A specific application linking to library version X will also require
tools of version X, right? A second application linking against version
Y will require tools version Y. Right now, these could not be installed
in parallel. Any chance we can make the runtime version independent?
Same applies to header files. A good option here would be to install
them to /usr/include/libdpdk{version}/ and have a dpdk-1.5.2.pc which
provides Cflags: -I${includedir}/libdpdk${version}
> +%files core-static
> +%{_libdir}/*.a
> +
> +%files core-devel
> +%{_includedir}/*
> +%{datadir}/mk
> +%{datadir}/%{target}
> +%{datadir}/examples
> +%doc %{docdir}
>
You'll also need for all packages and subpackages installing shared
libraries:
%post -p /sbin/ldconfig
%postun -p /sbin/ldconfig
[dpdk-dev] [vmxnet3-usermap PATCH 07/16] pkg: add recipe for RPM
On 02/04/2014 04:54 PM, Thomas Monjalon wrote: > +BuildRequires: dpdk-core-devel, kernel-devel, kernel-headers > +Requires: dpdk-core-runtime How does the compatibility mapping look like? I assume a given vmxnet3 version can only be linked against certain dpdk versions? We need to encode that mapping in the spec file somehow.
[dpdk-dev] [PATCH 03/16] pkg: add recipe for RPM
* Thomas Graf (tgraf at redhat.com) wrote:
> On 02/04/2014 04:54 PM, Thomas Monjalon wrote:
> >Packages can be built with:
> > RPM_BUILD_NCPUS=8 rpmbuild -ta dpdk-1.5.2r2.tar.gz
> >
> >There are packages for runtime, static libraries and development.
> >Once devel package installed, it can be used like this:
> > make -C /usr/share/dpdk/examples/helloworld RTE_SDK=/usr/share/dpdk
> >
> >Signed-off-by: Thomas Monjalon
>
> Thanks for getting this started! Some comments below. I'll be glad to
> help pushing this into Fedora.
>
> >+Name: dpdk
> >+Version: 1.5.2r1
> >+Release: 1
>
> What kind of upgrade strategy do you have in mind?
>
> I'm raising this because Fedora and other distributions will require
> a unique package name for every version of the package that is not
> backwards compatible.
>
> Typically libraries provide backwards compatible within a major release,
> i.e. all 1.x.x releases would be compatible. I realize that this might
> not be applicable yet but maybe 1.5.x?
>
> Depending on the versioning schema the name would be dpdk15, dpdk16, ...
> or dpdk152, dpdk153, ...
>
> >+BuildRequires: kernel-devel, kernel-headers, doxygen
>
> Is a python environment required as well?
>
> >+%description
> >+Dummy main package. Make only subpackages.
>
> I would just call the main package "libdpdk152" so you don't have to
> repeat the encoding versioning in all the subpackages.
>
> >+
> >+%package core-runtime
>
> What about calling it just "libdpdk"?
>
> >+Summary: Intel(r) Data Plane Development Kit core for runtime
> >+%description core-runtime
> >+Intel(r) DPDK runtime includes kernel modules, core libraries and tools.
> >+testpmd application allows to test fast packet processing environments
> >+on x86 platforms. For instance, it can be used to check that environment
> >+can support fast path applications such as 6WINDGate, pktgen, rumptcpip,
> >etc.
> >+More libraries are available as extensions in other packages.
> >+
> >+%package core-static
>
> Based on the above: "libdpdk-static"
>
> Packages that link against dpdk statically will do:
> BuildRequire: libdpdk152-static
>
> >+%files core-runtime
> >+%dir %{datadir}
> >+%{datadir}/config
> >+%{datadir}/tools
> >+%{moddir}/*
> >+%{_sbindir}/*
> >+%{_bindir}/*
> >+%{_libdir}/*.so
>
> This brings up the question of multiple parallel DPDK installations.
> A specific application linking to library version X will also require
> tools of version X, right? A second application linking against version
> Y will require tools version Y. Right now, these could not be installed
> in parallel. Any chance we can make the runtime version independent?
>
> Same applies to header files. A good option here would be to install
> them to /usr/include/libdpdk{version}/ and have a dpdk-1.5.2.pc which
> provides Cflags: -I${includedir}/libdpdk${version}
>
> >+%files core-static
> >+%{_libdir}/*.a
> >+
> >+%files core-devel
> >+%{_includedir}/*
> >+%{datadir}/mk
> >+%{datadir}/%{target}
> >+%{datadir}/examples
> >+%doc %{docdir}
> >
>
> You'll also need for all packages and subpackages installing shared
> libraries:
>
> %post -p /sbin/ldconfig
> %postun -p /sbin/ldconfig
Yes, thanks, I meant to mention that too.
Details here:
https://fedoraproject.org/wiki/Packaging:Guidelines#Shared_Libraries
