On 25/07/14 10:43, Thomas Monjalon wrote:
>> On 24/07/14 07:59, Matthew Hall wrote:
>>> I ran into some weird symbol conflicts between system netinet/in.h and DPDK
>>> rte_ip.h. They have a lot of duplicated definitions for stuff like
>>> IPPROTO_IP
>>> and so on. This breaks when you want to use
Hi,
In case someone is interested in seeing new releases of dpdk tested
against against the dpdk driver for the rump kernels, please help out.
There's usually a few hours of toying around with
build/compiler/assembler stuff to figure out how to build a new release
of dpdk, and I don't seem to
On 24/07/14 07:59, Matthew Hall wrote:
> Hello,
>
> I ran into some weird symbol conflicts between system netinet/in.h and DPDK
> rte_ip.h. They have a lot of duplicated definitions for stuff like IPPROTO_IP
> and so on. This breaks when you want to use inet_pton from arpa/inet.h,
> because it incl
On 23/07/14 15:58, Kavanagh, Mark B wrote:
> Hi,
>
> I build a switching application, which links against DPDK shared libraries;
> when I run the application, I see throughput of X. I then build the
> application again, except this time I link against DPDK shared libraries,
> having modified th
On 28/05/14 13:45, Thomas Monjalon wrote:
> So maybe it's possible to improve uio_pci_generic in order to replace igb_uio.
> If someone wants to work on it, it's possible to stage uio_pci_generic in
> dpdk.org in order to make it ready for kernel.org.
Back when researching MSI + uio_pci_generic, I
On 22/05/14 13:13, Thomas Monjalon wrote:
> 2014-05-19 16:51, Anatoly Burakov:
>> Note that since igb_uio no longer has a PCI ID list, it can now be
>> bound to any device, not just those explicitly supported by DPDK. In
>> other words, it now behaves similar to PCI stub, VFIO and other generic
>>
Daniel,
On 16/05/14 22:16, daniel chapiesky wrote:
> We are interested in finding out how much we can decrease the attack surface
> of our application by going full bare metal.. (i.e. sans OS). The mention
> of a bare metal version of dpdk is one of the contributing factors for our
> working on
On 1.8.2013 19:13, Marc Sune wrote:
> Regarding the rte_eal_init(), if the concern is the number of parameters
> and backwards compatibility, a typical solution is to create a struct
> containing the parameters:
>
>
> typedef struct eal_init_params{
> uint64_t coremask;
> unsigned int nu
Semi-related: why does DPDK take a blacklist instead of a list of
devices that it should use (perhaps with a special value "all" in case
someone really wants that behavior)? Historical reasons?
(yes, I've also bricked my ssh connections several times)
On 27.6.2013 2:54, Peter Chen wrote:
> This is in the sample application guide. I want to use tcpdump on the dpdk
> port, however its not in the examples folder of the source code...was it
> accidentally left out?
If you run a rump kernel on top of dpdk, hijacking the normal tcpdump
binary agains
On 19.06.2013 09:20, Adeel Amin wrote:
> Hello,
>
> Can anyone tell me that how I can run a DPDK application as a bare-metal
> (i.e. without Linux support). I've tried to run rump kernel TCP/IP stack by
> Antti Kantee but I'm unable to figure out that how I'll be
On 12.06.2013 16:54, Olivier MATZ wrote:
>> Unless I'm missing something, testpmd still needs
>> an explicit rte_pmd_foo_init() call. It's of course not difficult to
>> sprinkle some __attribute__((constructor))'s into the pmd's
>
> Yes, you need to do it in the pmd's constructor.
Ok, I thought it
On 12.06.2013 09:51, Thomas Monjalon wrote:
> From: Damien Millescamps
>
> Add an option to specify libraries to be loaded before probing the PCI.
>
> For instance, testpmd -d librte_pmd_xxx.so can be used to enable xxx
driver
> support on testpmd without any recompilation of testpmd.
What
On 03.06.2013 18:29, Thomas Monjalon wrote:
>> Is breaking the API a bad thing in this context? IMHO the
>> initialization APIs need work before they're general enough and
>> perpetually supporting the current ones seems like an unnecessary
>> burden. I'm trying to understand the general guidelin
On 03.06.2013 10:58, Damien Millescamps wrote:
>> };
>>
>> -/** Device needs igb_uio kernel module */
>> -#define RTE_PCI_DRV_NEED_IGB_UIO 0x0001
>> /** Device driver must be registered several times until failure */
>> -#define RTE_PCI_DRV_MULTIPLE 0x0002
>> +#define RTE_PCI_DRV_MULTIPLE 0x000
On 29.05.2013 10:27, somnath kotur wrote:
> Hi,
>Pls pardon me if this has been asked/addressed in another thread. Just
> wanted to know what i need to do if i wanted to plumb my non-Intel 10G NIC
> into the DPDK , For instance just into the test-pmd framework would also be
> fine ?
> Any point
Vincent,
On 23.05.2013 21:52, Vincent JARDIN wrote:
> We had to develop a complete logic from scratch (aka fast path logic) to
> get a TCP/IP stack with good performances for 6WIND (including some
> Openflow switching). Unfortunately, as part of our DPDK opensource
> contribution, we do not plan t
On 23.05.2013 21:20, Stephen Hemminger wrote:
>> I'm aware of the paper you linked given that I wrote it. I don't agree
>> that it supports your claim "already done several times before".
>
> I was more worried about multiple different TCP-IP stacks that seem
> to be only used by small number of p
On 23.05.2013 20:39, Daniel Cegie?ka wrote:
> 2013/5/23 Robert Bays :
>
>> Of course. And many more times than that. This is one more option for us
>> and it is BSD licensed.
>>
>> Ultimately, we will probably need a TCP stack in there.
>
> indeed, but what do you mean by the TCP stack? I hope n
On 23.05.2013 19:34, Stephen Hemminger wrote:
> Already done several times before.
> http://savannah.nongnu.org/projects/lwip/
> https://code.google.com/p/tcp-ip-in-user-space/
> http://www.ohloh.net/p/tcp-ip-in-user-space
> http://www.ioremap.net/projects/unetstack
> http://www.joerch.or
Hi,
I like the opportunities that a technology like DPDK enables, and I felt
that the availability of an open source TCP/IP stack for DPDK could make
things even more interesting. I've been working on a concept called the
anykernel, where the idea is that an OS kernel should be structured in a
Hi folks,
I found myself last week wanting to do simple testing with DPDK, but did
not possess the supported hardware and neither was the supported
hardware emulated by any virtual machine I could place my hands on. I
ended up hacking enough support for 82540 into DPDK to get simple
packetflo
22 matches
Mail list logo
