[dpdk-users] Weird phenomenon involving KNI

[dpdk-users] Weird phenomenon involving KNI

[DoHyung Kim]

I'm on the latest revision of 17.11 w/ a 2-port Intel X540 NIC. And having
some trouble. one of the 2 ports is bound to a uio_pci_generic, and a KNI
interface is up and assigned the MAC address of the port and an IP address,
while the other port is kept intact bound to the kernel.

Initially the 2 ports are known by their own IP addresses. But a few dozen
seconds later, the latter port begins to report via ARP it has the IP
address originally assigned to the KNI interface. So my DPDK app doesn't
receive any of packets sent to the IP address assigned to the KNI interface.

If I set the latter port down w/ ifdown and start my DPDK app, then my app
receives packets as intended. But when I set the normal port up again, then
it doesn't receive any packet since, this time, the KNI announces via ARP
it has the IP address of the other port too.

I searched for solution in DPDK mailing lists for this problem, but instead
found a few posts mentioning KNI will be replaced w/ something else. But it
seems that it's still gaining functionalities over the releases. So I'm
confused.

Please inform me of any clue for solving the problem described above. Or
should I fallback to something more stable like TAP driver?

Thanks in advance.

-- 
DoHyung Kim
Fluidic Inc.

Re: [dpdk-users] Weird phenomenon involving KNI

[DoHyung Kim]

It was a consequence of the well-known behavior of Linux kernel regarding
ARP handling when multiple NICs are on the same subnet.

Thanks for all who have spent one's time looking into my question.

DoHyung


2018년 12월 31일 (월) 오후 6:42, DoHyung Kim <dohyung.kim@fluidic.io>님이 작성:

> I'm on the latest revision of 17.11 w/ a 2-port Intel X540 NIC. And having
> some trouble. one of the 2 ports is bound to a uio_pci_generic, and a KNI
> interface is up and assigned the MAC address of the port and an IP address,
> while the other port is kept intact bound to the kernel.
>
> Initially the 2 ports are known by their own IP addresses. But a few dozen
> seconds later, the latter port begins to report via ARP it has the IP
> address originally assigned to the KNI interface. So my DPDK app doesn't
> receive any of packets sent to the IP address assigned to the KNI interface.
>
> If I set the latter port down w/ ifdown and start my DPDK app, then my app
> receives packets as intended. But when I set the normal port up again, then
> it doesn't receive any packet since, this time, the KNI announces via ARP
> it has the IP address of the other port too.
>
> I searched for solution in DPDK mailing lists for this problem, but
> instead found a few posts mentioning KNI will be replaced w/ something
> else. But it seems that it's still gaining functionalities over the
> releases. So I'm confused.
>
> Please inform me of any clue for solving the problem described above. Or
> should I fallback to something more stable like TAP driver?
>
> Thanks in advance.
>
> --
> DoHyung Kim
> Fluidic Inc.
>


-- 
DoHyung Kim
Fluidic Inc.

Re: [dpdk-users] Weird phenomenon involving KNI

[Jay Rolette]

On Tue, Jan 1, 2019 at 4:05 AM DoHyung Kim <dohyung.kim@fluidic.io> wrote:

> It was a consequence of the well-known behavior of Linux kernel regarding
> ARP handling when multiple NICs are on the same subnet.
>

What solution did you end up going with?

Re: [dpdk-users] Weird phenomenon involving KNI

[DoHyung Kim]

It's not relevant to DPDK at all. I was trying to put two NICs in a host to
single subnet, and even w/o DPDK involved, the NICs didn't work properly.
Googling turned out that one can't use multiple NICs in a Linux host in
single subnet under the default, out of the box, configuration.

I guess many of subscribers in this mailing list should already be familar
w/ the problem. But I describe how I've solved the problem below in the
hope that it may be helpful to someone like me:

If one wants such a network setup, one needs to tweak routing rules
together w/ a few changes to the way ARP is handled. An interesting point
here is one needs to set routing rules correctly in order to just get ARP
replies work as intenteded, though ARP replies are not strictly relevant to
the outgoing packets.

Please refer to the following doc: https://access.redhat.com/solutions/30564
In summary, each NIC needs to have a separate routing table and a routing
rule linking the table w/ the IP address of the NIC.
I added arp_ignore = 1 together w/ arp_announce = 2 since other docs on the
ARP flux problem suggests doing so.

DoHyung



2019년 1월 2일 (수) 오후 9:38, Jay Rolette <rolette@infinite.io>님이 작성:

> On Tue, Jan 1, 2019 at 4:05 AM DoHyung Kim <dohyung.kim@fluidic.io> wrote:
>
>> It was a consequence of the well-known behavior of Linux kernel regarding
>> ARP handling when multiple NICs are on the same subnet.
>>
>
> What solution did you end up going with?
>


-- 
DoHyung Kim
Fluidic Inc.