Thanks Bruce, I think your suggested example of multi_process answers my
questions.
Regards
-Prashant
-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Prashant Upadhyaya
Sent: Friday, November 22, 2013 7:10 PM
To: Richardson, Bruce; dev at dpdk.org
Subject: Re: [d
Hi Bruce,
Thanks.
Regarding your comment --
[BR] It will depend upon the application, but in most cases you probably want
to have slightly different code paths for primary and secondary instances. For
example, if a process is running as primary instance, it will probably call
rte_mempool_creat
Hi guys,
The DPDP programmer's guide mentions -
===
The EAL also supports an auto-detection mode (set by EAL --proc-type=auto flag),
whereby an Intel(r) DPDK process is started as a secondary instance if a primary
instance is already running.
===
So does this mean that if I have a DPDK exe foo.o
Hi, I'm experiencing weird problems with running dpdk examples on my
server running ubuntu-12.04. Application either manages to use ethernet
ports or doesn't. For example, this is results of two identical
sequental runs of l2fwd:
*
Of course you have to properly set
m->pkt.vlan_macip.f.l2_len and
m->pkt.vlan_macip.f.l3_len fields.
Regards,
Vladimir
2013/11/22 Vladimir Medvedkin
> Hi,
>
> If you need only ip checksum:
> struct rte_mbuf *m;
> m->ol_flags |= PKT_TX_IP_CKSUM;
>
> if you need to calculate tcp checksum add als
Hi,
If you need only ip checksum:
struct rte_mbuf *m;
m->ol_flags |= PKT_TX_IP_CKSUM;
if you need to calculate tcp checksum add also PKT_TX_TCP_CKSUM flag to
ol_flags field and caclulate pseudoheader checksum (see get_ipv4_psd_sum()
in app/test-pmd/csumonly.c)
struct tcp_hdr *th;
th->cksum
The new release can be downloaded here:
http://dpdk.org/browse/dpdk/tag/?id=v1.5.0r2
Changelog
- fixes for:
* RSS enabling
* ixgbe offloading
* endless loop on restart with 4096 ring entries
* build with various option
22/11/2013 14:07, Olivier MATZ :
> acked!
>
> PS: Does it pass all the non-regression tests? ;)
Yes, "make help" is still printing very helpful lines :)
So I've pushed it.
--
Thomas
Hello Thomas,
On 11/22/2013 01:53 PM, Thomas Monjalon wrote:
> The default value is /lib/modules/$(uname -r)/build
>
> Signed-off-by: Thomas Monjalon
> ---
> doc/build-sdk-quick.txt |1 +
> 1 file changed, 1 insertion(+)
acked!
PS: Does it pass all the non-regression tests? ;)
The default value is /lib/modules/$(uname -r)/build
Signed-off-by: Thomas Monjalon
---
doc/build-sdk-quick.txt |1 +
1 file changed, 1 insertion(+)
diff --git a/doc/build-sdk-quick.txt b/doc/build-sdk-quick.txt
index ca39c33..bf7c350 100644
--- a/doc/build-sdk-quick.txt
+++ b/doc/build-sdk-
Hello,
22/11/2013 13:29, Dmitry Vyal :
> EAL: PCI device :02:00.0 on NUMA socket -1
> EAL: probe driver: 8086:10fb rte_ixgbe_pmd
> EAL: PCI memory mapped at 0x7f6b83687000
> EAL: PCI memory mapped at 0x7f6b83683000
> EAL: PCI device :02:00.1 on NUMA socket -1
> EAL: probe driver: 8
22/11/2013 11:24, David Marchand :
> Fix build with old pcap library.
> Make it possible to specify which pcap library to use.
>
> David Marchand (3):
> pcap: use pcap-config to guess compilation flags
> pcap: fix build with old libpcap
> pcap: fix build when pcap_sendpacket is unavailable
Hi Prashant
> ===
> The EAL also supports an auto-detection mode (set by EAL --proc-type=auto
> flag), whereby an Intel(r) DPDK process is started as a secondary instance if
> a primary instance is already running.
> ===
>
> So does this mean that if I have a DPDK exe foo.out, then when I run the
Before libpcap 1.0.0, pcap_sendpacket was not available on linux targets (unless
backported).
When using such a library, we won't be able to send packet on the wire, yet we
can still dump packets into a pcap file.
Signed-off-by: David Marchand
---
lib/librte_pmd_pcap/rte_eth_pcap.c | 12 ++
For backwards compatibility, pcap.h includes pcap/pcap.h.
Hence, to be compatible with older pcap libraries, we must include pcap.h.
Signed-off-by: David Marchand
---
lib/librte_pmd_pcap/rte_eth_pcap.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/librte_pmd_pcap/rte
Use pcap-config to populate CFLAGS and LDFLAGS.
LIBPCAP_CFLAGS and LIBPCAP_LDFLAGS can be used to override this (useful when
cross-compiling).
Signed-off-by: David Marchand
---
app/test-pmd/Makefile |4
doc/build-sdk-quick.txt |2 ++
mk/rte.app.mk |
Fix build with old pcap library.
Make it possible to specify which pcap library to use.
David Marchand (3):
pcap: use pcap-config to guess compilation flags
pcap: fix build with old libpcap
pcap: fix build when pcap_sendpacket is unavailable
app/test-pmd/Makefile |4
Right, thanks. I had a little brain fart.
On Fri, Nov 22, 2013 at 4:42 AM, Richardson, Bruce <
bruce.richardson at intel.com> wrote:
> The Intel DPDK should work fine on RHEL 6.4. There should be no need to
> update your glibc, since this is subversion 12 (> 7), rather than 1.2.
> Regards,
> /B
RT~
22/11/2013 08:30, Ognjen Joldzic :
> Actually, the support for 82546EB Copper NIC is already there. All it takes
> to make it work is one line in rte_pci_dev_ids.h:
>
> RTE_PCI_DEV_ID_DECL_EM(PCI_VENDOR_ID_INTEL, E1000_DEV_ID_82546EB_COPPER)
>
> Not much of a patch, I guess :)
Please, I would pr
> IMHO, adding NULL objects is likely an error not a legitimate use case for
> adding ring elements.
>
> Can anyone think of a use case where adding NULL pointer objects makes
> sense?
>
[BR] As well as the use case already mentioned of passing using NULLs, there is
also the scenario where we wa
The Intel DPDK should work fine on RHEL 6.4. There should be no need to update
your glibc, since this is subversion 12 (> 7), rather than 1.2.
Regards,
/Bruce
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Michael Quicquaro
> Sent: Thursday, November 21, 2
Hi.
Actually, the support for 82546EB Copper NIC is already there. All it takes
to make it work is one line in rte_pci_dev_ids.h:
RTE_PCI_DEV_ID_DECL_EM(PCI_VENDOR_ID_INTEL, E1000_DEV_ID_82546EB_COPPER)
Not much of a patch, I guess :)
On Wed, Nov 20, 2013 at 8:57 AM, Thomas Monjalon
wrote:
> H
23 matches
Mail list logo
