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
> Acked-by:
ked-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 dele
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
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
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,
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
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
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
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
>
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
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
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
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
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
17 matches
Mail list logo
