Adding Acked-by line
On 18/02/16 11:26, Ferruh Yigit wrote:
> 1- remove duplicate nb_rx/tx_queues fields from internals
> 2- remove duplicate numa_node field from internals
>
> Signed-off-by: Ferruh Yigit
> Tested-by: Tetsuya Mukawa
> Acked-by: Tetsuya Mukawa
> Acked-by: N
Adding Acked-by line.
On 18/02/16 11:26, Ferruh Yigit wrote:
> 1- Remove duplicate nb_rx/tx_queues fields from internals
>
> Signed-off-by: Ferruh Yigit
> Acked-by: Nicolas Pernas Maradei
> ---
> drivers/net/ring/rte_eth_ring.c | 57
> ++
Hi,
Patch looks good to me although I haven't tested it. Adding Acked-by line.
Nico.
On 18/02/16 11:26, Ferruh Yigit wrote:
> 1- Remove duplicate nb_rx/tx_queues fields from internals
> 2- Move duplicate code into a common function
>
> Signed-off-by: Ferruh Yigit
> Acke
t; Acked-by: Nicolas Pernas Maradei
> ---
>
>
> Without this fix, if the captured length is smaller than the original
> length on the wire, mbuf will contain incorrect data.
>
>
> drivers/net/pcap/rte_eth_pcap.c | 12 ++--
> 1 file changed, 6 insertions(+), 6
Hi Dror,
Good catch. What you are saying makes sense and it is also explained in
pcap's documentation. Was your setup unusual though?
This might sound like a silly question but I don't remember seeing that
issue and I should have since your fix is correct.
Nico.
On 28/01/16 11:09, Dror Birkman
Hi,
Are those the only two libraries with external dependencies? I took a
quick look to the rte.app.mk file and there seem to be some others like
-lfuse and -lnuma. Would it be possible to move those to their specific
Makefiles as well?
Thanks,
Nico.
On 10/21/2015 03:18 PM, Panu Matilainen wr
Hi,
I had a look to the patch set last night and it looks good to me apart
from the few comments that I've already shared with Tero.
Nico.
On 28/04/15 13:09, Mcnamara, John wrote:
>> -Original Message-
>> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
>> Sent: Tuesday, Apri
Hi Dor,
What you are looking for seems straight forward to implement and it
should not really affect the driver's performance at all. Even adding
the full timestamp (seconds plus microseconds). However, I don't see too
much people looking for that feature to make it to mainline. I could be
wro
On 17/11/14 16:00, Neil Horman wrote:
> I get that, I was more asking, why those values? They seem a bit magic to me,
> and might benefit from some descriptive macros or comments so they make more
> sense
> Neil
OK, I get you now.
Maybe the diff is not very clear. I just left the original calls
On 17/11/14 14:10, Neil Horman wrote:
> What are the above pci bus/device/function tuples?
>
> Neil
Hi,
I'm not sure if I understand the question. If you mean what kind of
devices those are, as in physical or virtual, they are physical.
rte_eal_devargs_add() would parse the string as a PCI ID.
On 10/11/14 08:13, Olivier MATZ wrote:
> What about using the --no-pci option ?
>
> It would blacklist all physical devices (as PCI devices are the only
> ones supported today).
Hi Olivier,
Your idea does work for me. Although it's more a workaround than a real
solution. I'll be submitting a pa
On 07/11/14 14:57, Thomas Monjalon wrote:
> OK, now I better understand your need.
> I think that your use case was simply forgotten when designing the
> new behaviour.
> Could you prepare a patch for this need?
> Or maybe you could workaround with a script based on lspci to blacklist all
> network
On 07/11/14 14:02, Neil Horman wrote:
> Ah, you want the -w option then, it still appears in the short options list in
> my tree. That sets up the option parsing for all pci devices to require
> whitelisting to be initalized. virtual devices are exempt from this process
> because declaring them wi
On 07/11/14 13:26, Neil Horman wrote:
> Then you create the pcap device with --vdev, and simply don't load the pmds
> for
> any of your physical devices (or just don't use pci-whitelist at all if you're
> doing a static build). If you do that, then the corresponding niantic driver
> won't initia
On 07/11/14 12:55, Thomas Monjalon wrote:
> It's by design. If you add a vdev, you want to use it and there is no
> reason to whitelist it, and especially no reason to blacklist a device
> you created for your usage.
>
> Do you agree?
Hi Thomas,
Generally speaking you probably won't want to white
Hi,
I'm currently using the --vdev option to create virtual devices, mainly
for testing. I noticed that these virtual devices are not being
white-listed any more. That was the original behaviour when the option
was called --use-device. Instead of that the virtual device is being
added to the d
Hi,
I've been using the PMD pcap driver for a while now. It's very handy for
testing and running DPDK on systems with no Intel NICs (like my laptop).
Unfortunately I've found a small issue that's been bothering me a lot.
It turns out that the PMD pcap driver opens the pcaps/interfaces only at
Hi,
At mempool creation time you can pass in a callback function to
rte_mempool_create() that DPDK will call for every mbuf on the mempool
so you can initialize them to your liking. However, there doesn't seem
to be a straight forward way do that again once the mempool is already
created thoug
18 matches
Mail list logo
