On Mon, Nov 27, 2017 at 2:33 AM, Vincenzo Maffione
wrote:
> Hi,
>
> If you think it's a bug can you please open an issue on the github (
> https://github.com/luigirizzo/netmap/issues)?
>
> 2017-11-24 22:11 GMT+01:00 Xiaoye Sun :
>
>> Hi Vincenzo,
>>
>> Let me clarify my problem. (please ignore
Hi,
If you think it's a bug can you please open an issue on the github (
https://github.com/luigirizzo/netmap/issues)?
2017-11-24 22:11 GMT+01:00 Xiaoye Sun :
> Hi Vincenzo,
>
> Let me clarify my problem. (please ignore the previous incompleted email)
>
> I have a program, which is an extensio
Hi Vincenzo,
Let me clarify my problem. (please ignore the previous incompleted email)
I have a program, which is an extension of bridge.c
https://github.com/luigirizzo/netmap/blob/master/apps/bridge/bridge.c
The only difference is that my program also generates customized packets
sent to the NIC
Hi Vincenzo,
Thanks for your reply.
Let me clarify my problem.
I have a program, which is an extension of bridge.c
https://github.com/luigirizzo/netmap/blob/788f25dcc48dfec2e481573277b662968f690042/LINUX/ixgbe_netmap_linux.h#L377
On Wed, Nov 22, 2017 at 7:39 AM, Vincenzo Maffione
wr
Hi,
2017-11-21 7:51 GMT+01:00 Xiaoye Sun :
> Hi,
>
> Recently I found another problem with netmap. I think this new problem
> could be related to the problems in this threads so I just post the new
> problem here.
>
> In my setup, I have a sender program having a netmap ring (a pair of
> RX/TX ri
Hi,
Recently I found another problem with netmap. I think this new problem
could be related to the problems in this threads so I just post the new
problem here.
In my setup, I have a sender program having a netmap ring (a pair of
RX/TX ring) for the NIC and a ring for the host stack. The sender p
Hi Luigi,
Thanks Luigi!
Pinning the process to one CPU core solves the reorder problem!!!
Let me check if the duplicated packet problem is solved also.
Thanks!
Best,
Xiaoye
On Wed, Feb 10, 2016 at 7:21 AM, Luigi Rizzo wrote:
> On Tue, Feb 9, 2016 at 1:12 PM, Xiaoye Sun wrote:
> > Hi Luigi,
>
On Tue, Feb 9, 2016 at 1:12 PM, Xiaoye Sun wrote:
> Hi Luigi,
>
> Have you seen the previous email. any comments?
Hi,
to summarize, you are seeing reordering when
reinjecting packets into the host stack from bridge.c
On Linux, the NIOCTXSYNC towards the host stack calls netif_rx() one
packet at
Hi Luigi,
Have you seen the previous email. any comments?
On Fri, Feb 5, 2016 at 3:29 PM, Xiaoye Sun wrote:
> Hi Victor,
> Thanks for the help. The command you provided worked perfectly for me.
>
> Hi Luigi,
>
> Thanks for your clarification.
>
> The experiment I did was NOT running on 3 nodes.
Hi Victor,
Thanks for the help. The command you provided worked perfectly for me.
Hi Luigi,
Thanks for your clarification.
The experiment I did was NOT running on 3 nodes. They ran on two nodes.
node 1 ran [1. sender]; node 2 ran [2. bridge.c] and [3. receiver (not
using netmap)]; [2. bridge.c ]
I'm sorry, I made mistake. To workaround this try `ip link set $IFACE
promisc on`
On Thu, Feb 4, 2016 at 10:04 PM, Xiaoye Sun wrote:
> Yes. all the interfaces are up. Are you able to get ARP request when the
> interfaces are down?
>
>
> On Thursday, February 4, 2016, Victor Detoni
> wrote:
>
Yes. all the interfaces are up. Are you able to get ARP request when the
interfaces are down?
On Thursday, February 4, 2016, Victor Detoni wrote:
> Both interfaces are up? Like ifconfig... up
>
> I had this the same problem and I solve with commands above
>
> Em quinta-feira, 4 de fevereiro de 2
Both interfaces are up? Like ifconfig... up
I had this the same problem and I solve with commands above
Em quinta-feira, 4 de fevereiro de 2016, Xiaoye Sun
escreveu:
> Hi Luigi,
>
> Thanks for your explanation.
>
> I used three machines to do this experiment. They are directly connected.
>
> [(
On Tue, Feb 2, 2016 at 10:48 PM, Xiaoye Sun wrote:
>
>
> On Mon, Feb 1, 2016 at 11:34 PM, Luigi Rizzo wrote:
>>
>> On Tue, Feb 2, 2016 at 6:23 AM, Xiaoye Sun wrote:
>> > Hi Luigi,
>> >
>> > I have to clarify about the *jumping issue* about the slot indexes.
>> > In the bridge.c program, the slot
On Mon, Feb 1, 2016 at 11:34 PM, Luigi Rizzo wrote:
> On Tue, Feb 2, 2016 at 6:23 AM, Xiaoye Sun wrote:
> > Hi Luigi,
> >
> > I have to clarify about the *jumping issue* about the slot indexes.
> > In the bridge.c program, the slot index never jumps and it increases
> > sequentially.
> > In the
On Tue, Feb 2, 2016 at 6:23 AM, Xiaoye Sun wrote:
> Hi Luigi,
>
> I have to clarify about the *jumping issue* about the slot indexes.
> In the bridge.c program, the slot index never jumps and it increases
> sequentially.
> In the receiver.c program, the udp packet seq jumps and I showed the slot
>
Hi Luigi,
I have to clarify about the *jumping issue* about the slot indexes.
In the bridge.c program, the slot index never jumps and it increases
sequentially.
In the receiver.c program, the udp packet seq jumps and I showed the slot
index that each udp packet uses. So the slot index jumps togeth
Hi,
there must be some wrong with your setting because
slot indexes must be sequential and in your case they
are not (see the jump from 295 to 474 and then
back from 485 to 296, and the numerous interleavings
that you are seeing later).
I have no idea of the cause but typically this pattern
is wha
Hi Luigi,
Thanks for the detailed advice.
With more detailed experiments, actually I found that the udp
sender/receiver packet reorder issue *might* be irrelevant to the original
issue I posted. However, I think we should solve the udp sender/receiver
issue first.
I run the experiment with more d
On Fri, Jan 29, 2016 at 2:12 PM, Xiaoye Sun wrote:
> Hi Luigi,
>
> Thanks for your advice.
> I forgot to mention that I use the command "ethtool -L eth1 combined 1" to
> set the number of rings of the nic to 1. The host also only has one ring.
> I understand the situation where the first tx ring
Hi Luigi,
Thanks for your advice.
I forgot to mention that I use the command "ethtool -L eth1 combined 1" to
set the number of rings of the nic to 1. The host also only has one ring.
I understand the situation where the first tx ring is full so the bridge
will swap the packets to the second tx ri
On Fri, Jan 29, 2016 at 1:39 PM, Xiaoye Sun wrote:
> Hi Pavel,
>
> Our code is somewhat complicate.
> So I did a very simple experiment having the same problem so that you could
> regenerate the problem.
Xiaoye,
before doing more experiments can you please clarify
the operating conditions, speci
Hi Luigi,
Thanks for your reply. I try to disable iommu (add a line of
"GRUB_CMDLINE_LINUX="iommu=off
amd_iommu=off intel_iommu=off"" in /etc/default/grub and also add memory
barrier (__asm__ volatile("mfence" : : : "memory");) before it updates the
slot pointer cur and head. However, the problem
Hi Pavel,
Our code is somewhat complicate.
So I did a very simple experiment having the same problem so that you could
regenerate the problem.
In the new experiment, I used a very simple udp sender and udp receiver
that sends and receives udp packet with seq num.
I put the code here.
http://www.o
Hi,
in FreeBSD, netmap_reload_map() is basically a NOP unless the NIC uses
bounce buffers (in which case it is pointless to use netmap, and I am
not even sure the code works), or there is an iommu which may need to
be reprogrammed (but in that case you don't want to do it dynamically
on individual
Hello!
Really useful and detailed research. Thanks a lot! Could you share
your validation code? It could be useful for consistency tests for
netmap.
So I could not help with your original question. Let's wait answer
from developers of awesome Netmap :)
On Tue, Jan 26, 2016 at 2:55 AM, Xiaoye Sun
26 matches
Mail list logo
