* Trying to implement secondary loopback
@ 2013-03-12 12:05 Thomas Martitz
2013-03-13 11:13 ` richard -rw- weinberger
0 siblings, 1 reply; 24+ messages in thread
From: Thomas Martitz @ 2013-03-12 12:05 UTC (permalink / raw
To: netdev; +Cc: davem, edumazet, herbert, ebiederm
Hello folks,
(I'm sending this mail a second time (with a few people in CC) because I
received no response.)
I'm Thomas Martitz, working on my Master Thesis: an Ethernet NIC. As
part of my work I want to develop a custom loopback interface (for
testing purposes).
However I'm facing a problem: It doesn't appear to be possible for a
second loopback device to exist. Even when copying (and module'ifying)
drivers/net/loopback.c the resulting device doesn't behave like the
standard lo interface.
After examing the code I found this line (in loopback_net_init()):
loopback.c:206 net->loopback_dev = dev;
This suggests that each network namespace can only have one loopback
interface. And indeed after modifying my custom interface to include
this particular line it begins to work, but obviously at the same time
the standard lo interface stops working.
So my questions are:
* Is this on purpose/expected?
* Is there anyway around it so that I can have a custom loopback
interface without touching lo's functionality.
* Generally, what's the proper way (if any) implement a secondary
loopback interface?
Many thanks in advance.
Best regards.
-----
visit us at
CeBIT 2013 / March 5-9 / Hannover, Germany / hall 9, booth E08
OFC 2013 / March 19-21 / Anaheim Convention Center, CA, USA / booth 11807
www.hhi.fraunhofer.de/events
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Trying to implement secondary loopback
2013-03-12 12:05 Trying to implement secondary loopback Thomas Martitz
@ 2013-03-13 11:13 ` richard -rw- weinberger
2013-03-13 20:38 ` Martitz, Thomas
0 siblings, 1 reply; 24+ messages in thread
From: richard -rw- weinberger @ 2013-03-13 11:13 UTC (permalink / raw
To: Thomas Martitz; +Cc: netdev, davem, edumazet, herbert, ebiederm
On Tue, Mar 12, 2013 at 1:05 PM, Thomas Martitz
<thomas.martitz@hhi.fraunhofer.de> wrote:
> Hello folks,
>
> (I'm sending this mail a second time (with a few people in CC) because I
> received no response.)
>
> I'm Thomas Martitz, working on my Master Thesis: an Ethernet NIC. As part of
> my work I want to develop a custom loopback interface (for testing
> purposes).
>
> However I'm facing a problem: It doesn't appear to be possible for a second
> loopback device to exist. Even when copying (and module'ifying)
> drivers/net/loopback.c the resulting device doesn't behave like the standard
> lo interface.
>
> After examing the code I found this line (in loopback_net_init()):
>
> loopback.c:206 net->loopback_dev = dev;
>
> This suggests that each network namespace can only have one loopback
> interface. And indeed after modifying my custom interface to include this
> particular line it begins to work, but obviously at the same time the
> standard lo interface stops working.
>
> So my questions are:
> * Is this on purpose/expected?
> * Is there anyway around it so that I can have a custom loopback interface
> without touching lo's functionality.
> * Generally, what's the proper way (if any) implement a secondary loopback
> interface?
The only really question that matters is, why do you need a second
loopback interface?
Why can't you use any other pseudo interface?
--
Thanks,
//richard
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Trying to implement secondary loopback
2013-03-13 11:13 ` richard -rw- weinberger
@ 2013-03-13 20:38 ` Martitz, Thomas
2013-03-13 20:46 ` Eric W. Biederman
0 siblings, 1 reply; 24+ messages in thread
From: Martitz, Thomas @ 2013-03-13 20:38 UTC (permalink / raw
To: richard -rw- weinberger
Cc: netdev@vger.kernel.org, davem@davemloft.net, edumazet@google.com,
herbert@gondor.apana.org.au, ebiederm@xmission.com
>
> ________________________________________
> Von: richard -rw- weinberger [richard.weinberger@gmail.com]
> Gesendet: Mittwoch, 13. März 2013 12:13
> An: Martitz, Thomas
> Cc: netdev@vger.kernel.org; davem@davemloft.net; edumazet@google.com; herbert@gondor.apana.org.au; ebiederm@xmission.com
> Betreff: Re: Trying to implement secondary loopback
>
> >
> > So my questions are:
> > * Is this on purpose/expected?
> > * Is there anyway around it so that I can have a custom loopback interface
> > without touching lo's functionality.
> > * Generally, what's the proper way (if any) implement a secondary loopback
> > interface?
>
> The only really question that matters is, why do you need a second
> loopback interface?
> Why can't you use any other pseudo interface?
>
What pseudo interface do you mean? I'm not aware of alternative pseudo interfaces.
I'm developing a NIC and a driver for it. Thus I'm implementing the interface. I'm trying to implement an interface that does exactly do what loopback does except that I want to extend the loopback path to PCIe. This is for testing & validation purposes.
I tried to implement an interface that's doesn't advertise as such. But the data transfer didn't go through my code. My test app is a simple client/server setup in a single process that sends/receive data to/on 127.0.0.1.
Best regards.
-----
visit us at
OFC 2013 / March 19-21 / Anaheim Convention Center, CA, USA / booth 11807
www.hhi.fraunhofer.de/events
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Trying to implement secondary loopback
2013-03-13 20:38 ` Martitz, Thomas
@ 2013-03-13 20:46 ` Eric W. Biederman
2013-03-13 21:07 ` AW: " Martitz, Thomas
0 siblings, 1 reply; 24+ messages in thread
From: Eric W. Biederman @ 2013-03-13 20:46 UTC (permalink / raw
To: Martitz, Thomas
Cc: richard -rw- weinberger, netdev@vger.kernel.org,
davem@davemloft.net, edumazet@google.com,
herbert@gondor.apana.org.au
"Martitz, Thomas" <thomas.martitz@hhi.fraunhofer.de> writes:
>>
>> ________________________________________
>> Von: richard -rw- weinberger [richard.weinberger@gmail.com]
>> Gesendet: Mittwoch, 13. März 2013 12:13
>> An: Martitz, Thomas
>> Cc: netdev@vger.kernel.org; davem@davemloft.net; edumazet@google.com; herbert@gondor.apana.org.au; ebiederm@xmission.com
>> Betreff: Re: Trying to implement secondary loopback
>>
>> >
>> > So my questions are:
>> > * Is this on purpose/expected?
>> > * Is there anyway around it so that I can have a custom loopback interface
>> > without touching lo's functionality.
>> > * Generally, what's the proper way (if any) implement a secondary loopback
>> > interface?
>>
>> The only really question that matters is, why do you need a second
>> loopback interface?
>> Why can't you use any other pseudo interface?
>>
>
> What pseudo interface do you mean? I'm not aware of alternative pseudo interfaces.
>
> I'm developing a NIC and a driver for it. Thus I'm implementing the interface. I'm trying to implement an interface that does exactly do what loopback does except that I want to extend the loopback path to PCIe. This is for testing & validation purposes.
>
> I tried to implement an interface that's doesn't advertise as
> such. But the data transfer didn't go through my code. My test app is
> a simple client/server setup in a single process that sends/receive
> data to/on 127.0.0.1.
The easy solution is to setup two network namespaces and two nics.
And transmit data from one network namespace to another, through your
nics.
Eric
^ permalink raw reply [flat|nested] 24+ messages in thread
* AW: Trying to implement secondary loopback
2013-03-13 20:46 ` Eric W. Biederman
@ 2013-03-13 21:07 ` Martitz, Thomas
2013-03-13 21:21 ` Eric W. Biederman
0 siblings, 1 reply; 24+ messages in thread
From: Martitz, Thomas @ 2013-03-13 21:07 UTC (permalink / raw
To: Eric W. Biederman
Cc: richard -rw- weinberger, netdev@vger.kernel.org,
davem@davemloft.net, edumazet@google.com,
herbert@gondor.apana.org.au
>
> ________________________________________
> Von: Eric W. Biederman [ebiederm@xmission.com]
> Gesendet: Mittwoch, 13. März 2013 21:46
> An: Martitz, Thomas
> Cc: richard -rw- weinberger; netdev@vger.kernel.org; davem@davemloft.net; edumazet@google.com; herbert@gondor.apana.org.au
> Betreff: Re: Trying to implement secondary loopback
>
> > I tried to implement an interface that's doesn't advertise as
> > such. But the data transfer didn't go through my code. My test app is
> > a simple client/server setup in a single process that sends/receive
> > data to/on 127.0.0.1.
>
> The easy solution is to setup two network namespaces and two nics.
> And transmit data from one network namespace to another, through your
> nics.
>
> Eric
>
That sounds a lot more involed than using loopback to send data back to the same process. And I guess just calling netif_rx() in the xmit() function wouldn't be sufficient either? Also I wouldn't know how to do that as I'm not yet very familiar with network namespaces (but that can clearly get fixed).
Best regards.
-----
visit us at
OFC 2013 / March 19-21 / Anaheim Convention Center, CA, USA / booth 11807
www.hhi.fraunhofer.de/events
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: AW: Trying to implement secondary loopback
2013-03-13 21:07 ` AW: " Martitz, Thomas
@ 2013-03-13 21:21 ` Eric W. Biederman
2013-03-13 22:01 ` AW: " Martitz, Thomas
2013-03-15 7:30 ` Thomas Martitz
0 siblings, 2 replies; 24+ messages in thread
From: Eric W. Biederman @ 2013-03-13 21:21 UTC (permalink / raw
To: Martitz, Thomas
Cc: richard -rw- weinberger, netdev@vger.kernel.org,
davem@davemloft.net, edumazet@google.com,
herbert@gondor.apana.org.au
"Martitz, Thomas" <thomas.martitz@hhi.fraunhofer.de> writes:
>> Von: Eric W. Biederman [ebiederm@xmission.com]
>>
>> The easy solution is to setup two network namespaces and two nics.
>> And transmit data from one network namespace to another, through your
>> nics.
>
> That sounds a lot more involed than using loopback to send data back
> to the same process. And I guess just calling netif_rx() in the xmit()
> function wouldn't be sufficient either? Also I wouldn't know how to do
> that as I'm not yet very familiar with network namespaces (but that
> can clearly get fixed).
It may sound involved but it is just a few lines of code to set up.
ip netns add ns1
ip netns add ns2
ip link set nic1 netns ns1
ip link set nic2 netns ns2
int main(int argc, char **argv)
{
int netfd1, netfd2;
int sk1, sk2;
netfd1 = open(/var/run/netns/nic1);
netfd2 = open(/var/run/netns/nic2);
setns(netfd1, 0);
sk1 = socket(...);
setns(netfd2, 0);
sk2 = socket(...);
/* test test test */
}
And what is partidcularly interesting is that all of this works with
your drivers normal code paths without any kernel hacks.
Eric
^ permalink raw reply [flat|nested] 24+ messages in thread
* AW: AW: Trying to implement secondary loopback
2013-03-13 21:21 ` Eric W. Biederman
@ 2013-03-13 22:01 ` Martitz, Thomas
2013-03-15 7:30 ` Thomas Martitz
1 sibling, 0 replies; 24+ messages in thread
From: Martitz, Thomas @ 2013-03-13 22:01 UTC (permalink / raw
To: Eric W. Biederman
Cc: richard -rw- weinberger, netdev@vger.kernel.org,
davem@davemloft.net, edumazet@google.com,
herbert@gondor.apana.org.au
>
> ________________________________________
> Von: Eric W. Biederman [ebiederm@xmission.com]
> Gesendet: Mittwoch, 13. März 2013 22:21
> An: Martitz, Thomas
> Cc: richard -rw- weinberger; netdev@vger.kernel.org; davem@davemloft.net; edumazet@google.com; herbert@gondor.apana.org.au
> Betreff: Re: AW: Trying to implement secondary loopback
>
> "Martitz, Thomas" <thomas.martitz@hhi.fraunhofer.de> writes:
>
> >> Von: Eric W. Biederman [ebiederm@xmission.com]
> >>
> >> The easy solution is to setup two network namespaces and two nics.
> >> And transmit data from one network namespace to another, through your
> >> nics.
>
> >
> > That sounds a lot more involed than using loopback to send data back
> > to the same process. And I guess just calling netif_rx() in the xmit()
> > function wouldn't be sufficient either? Also I wouldn't know how to do
> > that as I'm not yet very familiar with network namespaces (but that
> > can clearly get fixed).
>
> It may sound involved but it is just a few lines of code to set up.
>
> ip netns add ns1
> ip netns add ns2
> ip link set nic1 netns ns1
> ip link set nic2 netns ns2
>
> int main(int argc, char **argv)
> {
> int netfd1, netfd2;
> int sk1, sk2;
> netfd1 = open(/var/run/netns/nic1);
> netfd2 = open(/var/run/netns/nic2);
>
> setns(netfd1, 0);
> sk1 = socket(...);
>
> setns(netfd2, 0);
> sk2 = socket(...);
>
> /* test test test */
> }
>
> And what is partidcularly interesting is that all of this works with
> your drivers normal code paths without any kernel hacks.
>
Thanks for the info, sounds very interesting. Now, how do I provide multiple interfaces within a single kernel module. Just call register_netdev() multiple times?
Best regards.
-----
visit us at
OFC 2013 / March 19-21 / Anaheim Convention Center, CA, USA / booth 11807
www.hhi.fraunhofer.de/events
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Trying to implement secondary loopback
2013-03-13 21:21 ` Eric W. Biederman
2013-03-13 22:01 ` AW: " Martitz, Thomas
@ 2013-03-15 7:30 ` Thomas Martitz
2013-03-15 8:59 ` Eric W. Biederman
2013-03-15 18:36 ` Ben Hutchings
1 sibling, 2 replies; 24+ messages in thread
From: Thomas Martitz @ 2013-03-15 7:30 UTC (permalink / raw
To: Eric W. Biederman
Cc: richard -rw- weinberger, netdev@vger.kernel.org,
davem@davemloft.net, edumazet@google.com,
herbert@gondor.apana.org.au
Am 13.03.2013 22:21, schrieb Eric W. Biederman:
> "Martitz, Thomas" <thomas.martitz@hhi.fraunhofer.de> writes:
>
>>> Von: Eric W. Biederman [ebiederm@xmission.com]
>>>
>>> The easy solution is to setup two network namespaces and two nics.
>>> And transmit data from one network namespace to another, through your
>>> nics.
>
>>
>> That sounds a lot more involed than using loopback to send data back
>> to the same process. And I guess just calling netif_rx() in the xmit()
>> function wouldn't be sufficient either? Also I wouldn't know how to do
>> that as I'm not yet very familiar with network namespaces (but that
>> can clearly get fixed).
>
> It may sound involved but it is just a few lines of code to set up.
>
> ip netns add ns1
> ip netns add ns2
> ip link set nic1 netns ns1
> ip link set nic2 netns ns2
>
> int main(int argc, char **argv)
> {
> int netfd1, netfd2;
> int sk1, sk2;
> netfd1 = open(/var/run/netns/nic1);
> netfd2 = open(/var/run/netns/nic2);
>
> setns(netfd1, 0);
> sk1 = socket(...);
>
> setns(netfd2, 0);
> sk2 = socket(...);
>
> /* test test test */
> }
>
> And what is partidcularly interesting is that all of this works with
> your drivers normal code paths without any kernel hacks.
>
> Eric
>
I have trouble understanding this approach. Does it mean that I have to
expose two interfaces from my kernel module. I.e. call register_netdev()
twice? Or use a "struct pernet_operations" to create a netdev on a
per-namespace basis.
If I do either of the above I end up with two "struct netdev" and two
MAC addresses, which I don't really want. Also I would need to transfer
from one netdev to the other in the driver's ndo_start_xmit() method
instead of simply calling netif_rx().
Perhaps I'm misunderstanding, I'm s
During my development, looping back the data in ndo_start_xmit() is only
a first step. The next step is to pass the data via PCIe and getting the
same data back later. This is why I want to keep the loopback as
simple/straightforward as possible.
Thanks for your assistance.
Best regards.
-----
visit us at
OFC 2013 / March 19-21 / Anaheim Convention Center, CA, USA / booth 11807
NABSHOW 2013 / April 8-11 / Las Vegas Convention Center, Nevada, USA / booth C7843
www.hhi.fraunhofer.de/events
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Trying to implement secondary loopback
2013-03-15 7:30 ` Thomas Martitz
@ 2013-03-15 8:59 ` Eric W. Biederman
2013-03-15 13:49 ` Thomas Martitz
2013-03-15 18:36 ` Ben Hutchings
1 sibling, 1 reply; 24+ messages in thread
From: Eric W. Biederman @ 2013-03-15 8:59 UTC (permalink / raw
To: Thomas Martitz
Cc: richard -rw- weinberger, netdev@vger.kernel.org,
davem@davemloft.net, edumazet@google.com,
herbert@gondor.apana.org.au
Thomas Martitz <thomas.martitz@hhi.fraunhofer.de> writes:
> Am 13.03.2013 22:21, schrieb Eric W. Biederman:
>> "Martitz, Thomas" <thomas.martitz@hhi.fraunhofer.de> writes:
>>
>>>> Von: Eric W. Biederman [ebiederm@xmission.com]
>>>>
>>>> The easy solution is to setup two network namespaces and two nics.
>>>> And transmit data from one network namespace to another, through your
>>>> nics.
>>
>>>
>>> That sounds a lot more involed than using loopback to send data back
>>> to the same process. And I guess just calling netif_rx() in the xmit()
>>> function wouldn't be sufficient either? Also I wouldn't know how to do
>>> that as I'm not yet very familiar with network namespaces (but that
>>> can clearly get fixed).
>>
>> It may sound involved but it is just a few lines of code to set up.
>>
>> ip netns add ns1
>> ip netns add ns2
>> ip link set nic1 netns ns1
>> ip link set nic2 netns ns2
>>
>> int main(int argc, char **argv)
>> {
>> int netfd1, netfd2;
>> int sk1, sk2;
>> netfd1 = open(/var/run/netns/nic1);
>> netfd2 = open(/var/run/netns/nic2);
>>
>> setns(netfd1, 0);
>> sk1 = socket(...);
>>
>> setns(netfd2, 0);
>> sk2 = socket(...);
>>
>> /* test test test */
>> }
>>
>> And what is partidcularly interesting is that all of this works with
>> your drivers normal code paths without any kernel hacks.
>>
>> Eric
>>
>
>
> I have trouble understanding this approach. Does it mean that I have
> to expose two interfaces from my kernel module. I.e. call
> register_netdev() twice?
The suggestion was to have one driver, driving two identical nics
plugged into the same machine with a cable between them. That creates no
special cases on your side for testing.
Shrug. It is your driver, and your hardware, feel free to
develop however you want.
> Or use a "struct pernet_operations" to create
> a netdev on a per-namespace basis.
> If I do either of the above I end up with two "struct netdev" and two
> MAC addresses, which I don't really want. Also I would need to
> transfer from one netdev to the other in the driver's ndo_start_xmit()
> method instead of simply calling netif_rx().
>
> Perhaps I'm misunderstanding, I'm s
>
> During my development, looping back the data in ndo_start_xmit() is
> only a first step. The next step is to pass the data via PCIe and
> getting the same data back later. This is why I want to keep the
> loopback as simple/straightforward as possible.
I guess the question is why do you want to loopback the data?
For testing your NIC driver? Or are you trying some strange scheme
where you try and offload processing between sockets on the same machine?
Eric
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Trying to implement secondary loopback
2013-03-15 8:59 ` Eric W. Biederman
@ 2013-03-15 13:49 ` Thomas Martitz
2013-03-15 13:56 ` richard -rw- weinberger
0 siblings, 1 reply; 24+ messages in thread
From: Thomas Martitz @ 2013-03-15 13:49 UTC (permalink / raw
To: Eric W. Biederman
Cc: richard -rw- weinberger, netdev@vger.kernel.org,
davem@davemloft.net, edumazet@google.com,
herbert@gondor.apana.org.au
Am 15.03.2013 09:59, schrieb Eric W. Biederman:
>>
>>
>> I have trouble understanding this approach. Does it mean that I have
>> to expose two interfaces from my kernel module. I.e. call
>> register_netdev() twice?
>
> The suggestion was to have one driver, driving two identical nics
> plugged into the same machine with a cable between them. That creates no
> special cases on your side for testing.
The NIC doesn't exist yet, I'm developing it along with the driver (both
part of my Master thesis). I'm implementing it in VHDL for an FPGA that
is on a PCIe card, and I can only use one card.
During development of the NIC I want to approach from the kernel module
level over to PCIe, MAC hardware and finally PHY level. For each of
these I want to establish a loopback mechanism for testing and
verification as I progress (and loopback because the level below doesn't
exist yet).
>
> Shrug. It is your driver, and your hardware, feel free to
> develop however you want.
>
>> Or use a "struct pernet_operations" to create
>> a netdev on a per-namespace basis.
>> If I do either of the above I end up with two "struct netdev" and two
>> MAC addresses, which I don't really want. Also I would need to
>> transfer from one netdev to the other in the driver's ndo_start_xmit()
>> method instead of simply calling netif_rx().
>>
>> Perhaps I'm misunderstanding, I'm s
>>
>> During my development, looping back the data in ndo_start_xmit() is
>> only a first step. The next step is to pass the data via PCIe and
>> getting the same data back later. This is why I want to keep the
>> loopback as simple/straightforward as possible.
>
> I guess the question is why do you want to loopback the data?
>
> For testing your NIC driver? Or are you trying some strange scheme
> where you try and offload processing between sockets on the same machine?
>
I want the loopback during development of the NIC hardware. Once the NIC
is done I drop the loopback and the card will be used for real networking.
Thus, I want the loopback to a) test my driver, and b) test the hardware
(for each milestone) as I'm implementing it.
Best regards.
-----
visit us at
OFC 2013 / March 19-21 / Anaheim Convention Center, CA, USA / booth 11807
NABSHOW 2013 / April 8-11 / Las Vegas Convention Center, Nevada, USA / booth C7843
www.hhi.fraunhofer.de/events
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Trying to implement secondary loopback
2013-03-15 13:49 ` Thomas Martitz
@ 2013-03-15 13:56 ` richard -rw- weinberger
2013-03-15 14:08 ` Thomas Martitz
0 siblings, 1 reply; 24+ messages in thread
From: richard -rw- weinberger @ 2013-03-15 13:56 UTC (permalink / raw
To: Thomas Martitz
Cc: Eric W. Biederman, netdev@vger.kernel.org, davem@davemloft.net,
edumazet@google.com, herbert@gondor.apana.org.au
On Fri, Mar 15, 2013 at 2:49 PM, Thomas Martitz
<thomas.martitz@hhi.fraunhofer.de> wrote:
> I want the loopback during development of the NIC hardware. Once the NIC is
> done I drop the loopback and the card will be used for real networking.
> Thus, I want the loopback to a) test my driver, and b) test the hardware
> (for each milestone) as I'm implementing it.
Sorry, I still don't get why you need a loopback device for that.
--
Thanks,
//richard
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Trying to implement secondary loopback
2013-03-15 13:56 ` richard -rw- weinberger
@ 2013-03-15 14:08 ` Thomas Martitz
2013-03-15 14:16 ` richard -rw- weinberger
0 siblings, 1 reply; 24+ messages in thread
From: Thomas Martitz @ 2013-03-15 14:08 UTC (permalink / raw
To: richard -rw- weinberger
Cc: Eric W. Biederman, netdev@vger.kernel.org, davem@davemloft.net,
edumazet@google.com, herbert@gondor.apana.org.au
Am 15.03.2013 14:56, schrieb richard -rw- weinberger:
> On Fri, Mar 15, 2013 at 2:49 PM, Thomas Martitz
> <thomas.martitz@hhi.fraunhofer.de> wrote:
>> I want the loopback during development of the NIC hardware. Once the NIC is
>> done I drop the loopback and the card will be used for real networking.
>> Thus, I want the loopback to a) test my driver, and b) test the hardware
>> (for each milestone) as I'm implementing it.
>
> Sorry, I still don't get why you need a loopback device for that.
>
What's wrong with loopback? It's the simplest method to get basic
bidirectional data transfer going.
Can you suggest an alternative approach?
Best regards.
-----
visit us at
OFC 2013 / March 19-21 / Anaheim Convention Center, CA, USA / booth 11807
NABSHOW 2013 / April 8-11 / Las Vegas Convention Center, Nevada, USA / booth C7843
www.hhi.fraunhofer.de/events
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Trying to implement secondary loopback
2013-03-15 14:08 ` Thomas Martitz
@ 2013-03-15 14:16 ` richard -rw- weinberger
2013-03-15 14:20 ` Thomas Martitz
0 siblings, 1 reply; 24+ messages in thread
From: richard -rw- weinberger @ 2013-03-15 14:16 UTC (permalink / raw
To: Thomas Martitz
Cc: Eric W. Biederman, netdev@vger.kernel.org, davem@davemloft.net,
edumazet@google.com, herbert@gondor.apana.org.au
On Fri, Mar 15, 2013 at 3:08 PM, Thomas Martitz
<thomas.martitz@hhi.fraunhofer.de> wrote:
> What's wrong with loopback? It's the simplest method to get basic
> bidirectional data transfer going.
>
> Can you suggest an alternative approach?
The real question is, why do you need a second one?
I assume your driver (for the non-existing hardware) is a ethernet driver,
and now you're looking for a way to test your shiny new ethX device, correct?
--
Thanks,
//richard
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Trying to implement secondary loopback
2013-03-15 14:16 ` richard -rw- weinberger
@ 2013-03-15 14:20 ` Thomas Martitz
2013-03-15 14:32 ` richard -rw- weinberger
0 siblings, 1 reply; 24+ messages in thread
From: Thomas Martitz @ 2013-03-15 14:20 UTC (permalink / raw
To: richard -rw- weinberger
Cc: Eric W. Biederman, netdev@vger.kernel.org, davem@davemloft.net,
edumazet@google.com, herbert@gondor.apana.org.au
Am 15.03.2013 15:16, schrieb richard -rw- weinberger:
> On Fri, Mar 15, 2013 at 3:08 PM, Thomas Martitz
> <thomas.martitz@hhi.fraunhofer.de> wrote:
>> What's wrong with loopback? It's the simplest method to get basic
>> bidirectional data transfer going.
>>
>> Can you suggest an alternative approach?
>
> The real question is, why do you need a second one?
> I assume your driver (for the non-existing hardware) is a ethernet driver,
> and now you're looking for a way to test your shiny new ethX device, correct?
>
Yes. But that's only the first step. Once I have the basic ethX device
working I want to make sure the PCIe data transfer is working (with good
performance), ideally using the very same test application in user space.
Best regards.
-----
visit us at
OFC 2013 / March 19-21 / Anaheim Convention Center, CA, USA / booth 11807
NABSHOW 2013 / April 8-11 / Las Vegas Convention Center, Nevada, USA / booth C7843
www.hhi.fraunhofer.de/events
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Trying to implement secondary loopback
2013-03-15 14:20 ` Thomas Martitz
@ 2013-03-15 14:32 ` richard -rw- weinberger
2013-03-15 14:35 ` Thomas Martitz
0 siblings, 1 reply; 24+ messages in thread
From: richard -rw- weinberger @ 2013-03-15 14:32 UTC (permalink / raw
To: Thomas Martitz
Cc: Eric W. Biederman, netdev@vger.kernel.org, davem@davemloft.net,
edumazet@google.com, herbert@gondor.apana.org.au
On Fri, Mar 15, 2013 at 3:20 PM, Thomas Martitz
<thomas.martitz@hhi.fraunhofer.de> wrote:
>> The real question is, why do you need a second one?
>> I assume your driver (for the non-existing hardware) is a ethernet driver,
>> and now you're looking for a way to test your shiny new ethX device,
>> correct?
>>
>
> Yes. But that's only the first step. Once I have the basic ethX device
> working I want to make sure the PCIe data transfer is working (with good
> performance), ideally using the very same test application in user space.
And there is the second loopback device is this picture?
--
Thanks,
//richard
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Trying to implement secondary loopback
2013-03-15 14:32 ` richard -rw- weinberger
@ 2013-03-15 14:35 ` Thomas Martitz
2013-03-15 14:45 ` richard -rw- weinberger
0 siblings, 1 reply; 24+ messages in thread
From: Thomas Martitz @ 2013-03-15 14:35 UTC (permalink / raw
To: richard -rw- weinberger
Cc: Eric W. Biederman, netdev@vger.kernel.org, davem@davemloft.net,
edumazet@google.com, herbert@gondor.apana.org.au
Am 15.03.2013 15:32, schrieb richard -rw- weinberger:
> On Fri, Mar 15, 2013 at 3:20 PM, Thomas Martitz
> <thomas.martitz@hhi.fraunhofer.de> wrote:
>>> The real question is, why do you need a second one?
>>> I assume your driver (for the non-existing hardware) is a ethernet driver,
>>> and now you're looking for a way to test your shiny new ethX device,
>>> correct?
>>>
>>
>> Yes. But that's only the first step. Once I have the basic ethX device
>> working I want to make sure the PCIe data transfer is working (with good
>> performance), ideally using the very same test application in user space.
>
> And there is the second loopback device is this picture?
>
Mine is the second one, as I cannot modify "lo". The standard "lo"
interface is the the first loopback and it seems to be hardcoded to be
the only one.
Best regards.
-----
visit us at
OFC 2013 / March 19-21 / Anaheim Convention Center, CA, USA / booth 11807
NABSHOW 2013 / April 8-11 / Las Vegas Convention Center, Nevada, USA / booth C7843
www.hhi.fraunhofer.de/events
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Trying to implement secondary loopback
2013-03-15 14:35 ` Thomas Martitz
@ 2013-03-15 14:45 ` richard -rw- weinberger
2013-03-15 14:50 ` Thomas Martitz
0 siblings, 1 reply; 24+ messages in thread
From: richard -rw- weinberger @ 2013-03-15 14:45 UTC (permalink / raw
To: Thomas Martitz
Cc: Eric W. Biederman, netdev@vger.kernel.org, davem@davemloft.net,
edumazet@google.com, herbert@gondor.apana.org.au
On Fri, Mar 15, 2013 at 3:35 PM, Thomas Martitz
<thomas.martitz@hhi.fraunhofer.de> wrote:
> Am 15.03.2013 15:32, schrieb richard -rw- weinberger:
>
>> On Fri, Mar 15, 2013 at 3:20 PM, Thomas Martitz
>> <thomas.martitz@hhi.fraunhofer.de> wrote:
>>>>
>>>> The real question is, why do you need a second one?
>>>> I assume your driver (for the non-existing hardware) is a ethernet
>>>> driver,
>>>> and now you're looking for a way to test your shiny new ethX device,
>>>> correct?
>>>>
>>>
>>> Yes. But that's only the first step. Once I have the basic ethX device
>>> working I want to make sure the PCIe data transfer is working (with good
>>> performance), ideally using the very same test application in user space.
>>
>>
>> And there is the second loopback device is this picture?
>>
>
> Mine is the second one, as I cannot modify "lo". The standard "lo" interface
> is the the first loopback and it seems to be hardcoded to be the only one.
And why can't you implement a regular ethernet driver like everyone else does?
--
Thanks,
//richard
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Trying to implement secondary loopback
2013-03-15 14:45 ` richard -rw- weinberger
@ 2013-03-15 14:50 ` Thomas Martitz
2013-03-15 15:07 ` Thomas Martitz
0 siblings, 1 reply; 24+ messages in thread
From: Thomas Martitz @ 2013-03-15 14:50 UTC (permalink / raw
To: richard -rw- weinberger
Cc: Eric W. Biederman, netdev@vger.kernel.org, davem@davemloft.net,
edumazet@google.com, herbert@gondor.apana.org.au
Am 15.03.2013 15:45, schrieb richard -rw- weinberger:
> On Fri, Mar 15, 2013 at 3:35 PM, Thomas Martitz
> <thomas.martitz@hhi.fraunhofer.de> wrote:
>> Am 15.03.2013 15:32, schrieb richard -rw- weinberger:
>>
>>> On Fri, Mar 15, 2013 at 3:20 PM, Thomas Martitz
>>> <thomas.martitz@hhi.fraunhofer.de> wrote:
>>>>>
>>>>> The real question is, why do you need a second one?
>>>>> I assume your driver (for the non-existing hardware) is a ethernet
>>>>> driver,
>>>>> and now you're looking for a way to test your shiny new ethX device,
>>>>> correct?
>>>>>
>>>>
>>>> Yes. But that's only the first step. Once I have the basic ethX device
>>>> working I want to make sure the PCIe data transfer is working (with good
>>>> performance), ideally using the very same test application in user space.
>>>
>>>
>>> And there is the second loopback device is this picture?
>>>
>>
>> Mine is the second one, as I cannot modify "lo". The standard "lo" interface
>> is the the first loopback and it seems to be hardcoded to be the only one.
>
> And why can't you implement a regular ethernet driver like everyone else does?
>
That was actually my first attepmt, because I was sure it would work.
However when I tried that I had trouble to get transfers on localhost
routed to my code. I did "ifconfig lo down" but then it didn't transfer
at all. I will retry.
Best regards.
-----
visit us at
OFC 2013 / March 19-21 / Anaheim Convention Center, CA, USA / booth 11807
NABSHOW 2013 / April 8-11 / Las Vegas Convention Center, Nevada, USA / booth C7843
www.hhi.fraunhofer.de/events
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Trying to implement secondary loopback
2013-03-15 14:50 ` Thomas Martitz
@ 2013-03-15 15:07 ` Thomas Martitz
2013-03-15 15:15 ` Hannes Frederic Sowa
2013-03-15 15:37 ` Benjamin LaHaise
0 siblings, 2 replies; 24+ messages in thread
From: Thomas Martitz @ 2013-03-15 15:07 UTC (permalink / raw
To: richard -rw- weinberger
Cc: Eric W. Biederman, netdev@vger.kernel.org, davem@davemloft.net,
edumazet@google.com, herbert@gondor.apana.org.au
Am 15.03.2013 15:50, schrieb Thomas Martitz:
> Am 15.03.2013 15:45, schrieb richard -rw- weinberger:
>> On Fri, Mar 15, 2013 at 3:35 PM, Thomas Martitz
>> <thomas.martitz@hhi.fraunhofer.de> wrote:
>>> Am 15.03.2013 15:32, schrieb richard -rw- weinberger:
>>>
>>>> On Fri, Mar 15, 2013 at 3:20 PM, Thomas Martitz
>>>> <thomas.martitz@hhi.fraunhofer.de> wrote:
>>>>>>
>>>>>> The real question is, why do you need a second one?
>>>>>> I assume your driver (for the non-existing hardware) is a ethernet
>>>>>> driver,
>>>>>> and now you're looking for a way to test your shiny new ethX device,
>>>>>> correct?
>>>>>>
>>>>>
>>>>> Yes. But that's only the first step. Once I have the basic ethX device
>>>>> working I want to make sure the PCIe data transfer is working (with
>>>>> good
>>>>> performance), ideally using the very same test application in user
>>>>> space.
>>>>
>>>>
>>>> And there is the second loopback device is this picture?
>>>>
>>>
>>> Mine is the second one, as I cannot modify "lo". The standard "lo"
>>> interface
>>> is the the first loopback and it seems to be hardcoded to be the only
>>> one.
>>
>> And why can't you implement a regular ethernet driver like everyone
>> else does?
>>
>
>
> That was actually my first attepmt, because I was sure it would work.
> However when I tried that I had trouble to get transfers on localhost
> routed to my code. I did "ifconfig lo down" but then it didn't transfer
> at all. I will retry.
>
Same result. I assumed the kernel treats lo in a special way for
localhost-connections and that it would be impossible to achieve the
same with a custom interface.
I did the following:
ifconfig lo down
insmod ./mykmod.ko
ifconfig eth2 up
ifconfig eth2 127.0.0.1
At this point ifconfig prints the same information for eth2 that it had
printed for lo before (except for the LOOPBACK flag, but I can enable
that one as well by adding IFF_LOOPBACK to the interface flags in the
module). Yet my test application only works with lo, not eth2.
Best regards.
-----
visit us at
OFC 2013 / March 19-21 / Anaheim Convention Center, CA, USA / booth 11807
NABSHOW 2013 / April 8-11 / Las Vegas Convention Center, Nevada, USA / booth C7843
www.hhi.fraunhofer.de/events
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Trying to implement secondary loopback
2013-03-15 15:07 ` Thomas Martitz
@ 2013-03-15 15:15 ` Hannes Frederic Sowa
2013-03-15 15:37 ` Benjamin LaHaise
1 sibling, 0 replies; 24+ messages in thread
From: Hannes Frederic Sowa @ 2013-03-15 15:15 UTC (permalink / raw
To: Thomas Martitz
Cc: richard -rw- weinberger, Eric W. Biederman,
netdev@vger.kernel.org, davem@davemloft.net, edumazet@google.com,
herbert@gondor.apana.org.au
On Fri, Mar 15, 2013 at 04:07:32PM +0100, Thomas Martitz wrote:
> Same result. I assumed the kernel treats lo in a special way for
> localhost-connections and that it would be impossible to achieve the
> same with a custom interface.
>
> I did the following:
>
> ifconfig lo down
> insmod ./mykmod.ko
> ifconfig eth2 up
> ifconfig eth2 127.0.0.1
>
> At this point ifconfig prints the same information for eth2 that it had
> printed for lo before (except for the LOOPBACK flag, but I can enable
> that one as well by adding IFF_LOOPBACK to the interface flags in the
> module). Yet my test application only works with lo, not eth2.
127.0.0.0/8 is guarded by the kernel, but there is a sysctl for relaxing the
checks, /proc/sys/net/ipv4/conf/route_localnet. You could give it a try.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Trying to implement secondary loopback
2013-03-15 15:07 ` Thomas Martitz
2013-03-15 15:15 ` Hannes Frederic Sowa
@ 2013-03-15 15:37 ` Benjamin LaHaise
2013-03-15 19:48 ` Martitz, Thomas
1 sibling, 1 reply; 24+ messages in thread
From: Benjamin LaHaise @ 2013-03-15 15:37 UTC (permalink / raw
To: Thomas Martitz
Cc: richard -rw- weinberger, Eric W. Biederman,
netdev@vger.kernel.org, davem@davemloft.net, edumazet@google.com,
herbert@gondor.apana.org.au
On Fri, Mar 15, 2013 at 04:07:32PM +0100, Thomas Martitz wrote:
> Same result. I assumed the kernel treats lo in a special way for
> localhost-connections and that it would be impossible to achieve the
> same with a custom interface.
>
> I did the following:
>
> ifconfig lo down
> insmod ./mykmod.ko
> ifconfig eth2 up
> ifconfig eth2 127.0.0.1
>
> At this point ifconfig prints the same information for eth2 that it had
> printed for lo before (except for the LOOPBACK flag, but I can enable
> that one as well by adding IFF_LOOPBACK to the interface flags in the
> module). Yet my test application only works with lo, not eth2.
Don't use loopback ip addresses; it makes no sense to do so. I've worked
on a couple opf nic implementations on FPGAs for a while now (a gige
implementation that works, and now a 10G nic), and it's easy enough to
develop it as a regular ethernet driver. You can write test programs that
use raw sockets to send/receive packets over the ethernet device, or use
pktgen to send packets. You don't even need to configure an ip address for
testing with raw packets. Testing with IP is a lot harder during early
bring-up of your hardware as it requires everything to work (that is, you
need ARP to work successfully before IP can work). Just stick to simple
packet injection initially, and don't confuse yourself by thinking about
the loopback device.
-ben
--
"Thought is the essence of where you are now."
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Trying to implement secondary loopback
2013-03-15 7:30 ` Thomas Martitz
2013-03-15 8:59 ` Eric W. Biederman
@ 2013-03-15 18:36 ` Ben Hutchings
1 sibling, 0 replies; 24+ messages in thread
From: Ben Hutchings @ 2013-03-15 18:36 UTC (permalink / raw
To: Thomas Martitz
Cc: Eric W. Biederman, richard -rw- weinberger,
netdev@vger.kernel.org, davem@davemloft.net, edumazet@google.com,
herbert@gondor.apana.org.au
On Fri, 2013-03-15 at 08:30 +0100, Thomas Martitz wrote:
> Am 13.03.2013 22:21, schrieb Eric W. Biederman:
> > "Martitz, Thomas" <thomas.martitz@hhi.fraunhofer.de> writes:
> >
> >>> Von: Eric W. Biederman [ebiederm@xmission.com]
> >>>
> >>> The easy solution is to setup two network namespaces and two nics.
> >>> And transmit data from one network namespace to another, through your
> >>> nics.
> >
> >>
> >> That sounds a lot more involed than using loopback to send data back
> >> to the same process. And I guess just calling netif_rx() in the xmit()
> >> function wouldn't be sufficient either? Also I wouldn't know how to do
> >> that as I'm not yet very familiar with network namespaces (but that
> >> can clearly get fixed).
> >
> > It may sound involved but it is just a few lines of code to set up.
> >
> > ip netns add ns1
> > ip netns add ns2
> > ip link set nic1 netns ns1
> > ip link set nic2 netns ns2
> >
> > int main(int argc, char **argv)
> > {
> > int netfd1, netfd2;
> > int sk1, sk2;
> > netfd1 = open(/var/run/netns/nic1);
> > netfd2 = open(/var/run/netns/nic2);
> >
> > setns(netfd1, 0);
> > sk1 = socket(...);
> >
> > setns(netfd2, 0);
> > sk2 = socket(...);
> >
> > /* test test test */
> > }
> >
> > And what is partidcularly interesting is that all of this works with
> > your drivers normal code paths without any kernel hacks.
> >
> > Eric
> >
>
>
> I have trouble understanding this approach. Does it mean that I have to
> expose two interfaces from my kernel module. I.e. call register_netdev()
> twice?
[...]
Perhaps you can use macvlan for this. Create one net device in your
driver, then use macvlan to stack two net devices on top of it using
different MAC addresses. I think you'll need to configure them in VEPA
mode so that macvlan doesn't bridge them.
As an alternative to network namespaces, you might find it easier to
assign one or both net devices to virtual machines. virt-manager and
virsh can set up KVM virtual machines using macvlan/macvtap interfaces.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Trying to implement secondary loopback
2013-03-15 15:37 ` Benjamin LaHaise
@ 2013-03-15 19:48 ` Martitz, Thomas
2013-03-18 9:33 ` Thomas Martitz
0 siblings, 1 reply; 24+ messages in thread
From: Martitz, Thomas @ 2013-03-15 19:48 UTC (permalink / raw
To: Benjamin LaHaise
Cc: richard -rw- weinberger, Eric W. Biederman,
netdev@vger.kernel.org, davem@davemloft.net, edumazet@google.com,
herbert@gondor.apana.org.au
>
> ________________________________________
> Von: Benjamin LaHaise [bcrl@kvack.org]
> Gesendet: Freitag, 15. März 2013 16:37
> An: Martitz, Thomas
> Cc: richard -rw- weinberger; Eric W. Biederman; netdev@vger.kernel.org; davem@davemloft.net; edumazet@google.com; herbert@gondor.apana.org.au
> Betreff: Re: Trying to implement secondary loopback
>
> On Fri, Mar 15, 2013 at 04:07:32PM +0100, Thomas Martitz wrote:
> > Same result. I assumed the kernel treats lo in a special way for
> > localhost-connections and that it would be impossible to achieve the
> > same with a custom interface.
> >
> > I did the following:
> >
> > ifconfig lo down
> > insmod ./mykmod.ko
> > ifconfig eth2 up
> > ifconfig eth2 127.0.0.1
> >
> > At this point ifconfig prints the same information for eth2 that it had
> > printed for lo before (except for the LOOPBACK flag, but I can enable
> > that one as well by adding IFF_LOOPBACK to the interface flags in the
> > module). Yet my test application only works with lo, not eth2.
>
> Don't use loopback ip addresses; it makes no sense to do so. I've worked
> on a couple opf nic implementations on FPGAs for a while now (a gige
> implementation that works, and now a 10G nic), and it's easy enough to
> develop it as a regular ethernet driver. You can write test programs that
> use raw sockets to send/receive packets over the ethernet device, or use
> pktgen to send packets. You don't even need to configure an ip address for
> testing with raw packets. Testing with IP is a lot harder during early
> bring-up of your hardware as it requires everything to work (that is, you
> need ARP to work successfully before IP can work). Just stick to simple
> packet injection initially, and don't confuse yourself by thinking about
> the loopback device.
Thank you for your very helpful mail. I haven't considered raw sockets, but it makes total sense now you mention it. This should give a lot less hassle.
However, please let us try to clear up my (mis-)understanding. Even when I use non-looback addresses (e.g. 192.168.1.x) it does not work. For the ARP requirement I tried to workaround by using specifying the IFF_NOARP flag, and using the arp command line tool to populate the arp cache with the the MAC. With this, and all other interfaces down'ed, I cannot get transfers to work. The the sendto() (sending UDP datadagrams) call hangs while the ndk_start_xmit() method isn't even called. As works fine with the loopback interface I started to believe that I need to implement a real loopback interface. It is this supposed to work this way isn't it?
Best regards.
-----
visit us at
OFC 2013 / March 19-21 / Anaheim Convention Center, CA, USA / booth 11807
NABSHOW 2013 / April 8-11 / Las Vegas Convention Center, Nevada, USA / booth C7843
www.hhi.fraunhofer.de/events
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Trying to implement secondary loopback
2013-03-15 19:48 ` Martitz, Thomas
@ 2013-03-18 9:33 ` Thomas Martitz
0 siblings, 0 replies; 24+ messages in thread
From: Thomas Martitz @ 2013-03-18 9:33 UTC (permalink / raw
To: Benjamin LaHaise
Cc: richard -rw- weinberger, Eric W. Biederman,
netdev@vger.kernel.org, davem@davemloft.net, edumazet@google.com,
herbert@gondor.apana.org.au
Am 15.03.2013 20:48, schrieb Martitz, Thomas:
>>
>> ________________________________________
>> Von: Benjamin LaHaise [bcrl@kvack.org]
>> Gesendet: Freitag, 15. März 2013 16:37
>> An: Martitz, Thomas
>> Cc: richard -rw- weinberger; Eric W. Biederman; netdev@vger.kernel.org; davem@davemloft.net; edumazet@google.com; herbert@gondor.apana.org.au
>> Betreff: Re: Trying to implement secondary loopback
>>
>> On Fri, Mar 15, 2013 at 04:07:32PM +0100, Thomas Martitz wrote:
>>> Same result. I assumed the kernel treats lo in a special way for
>>> localhost-connections and that it would be impossible to achieve the
>>> same with a custom interface.
>>>
>>> I did the following:
>>>
>>> ifconfig lo down
>>> insmod ./mykmod.ko
>>> ifconfig eth2 up
>>> ifconfig eth2 127.0.0.1
>>>
>>> At this point ifconfig prints the same information for eth2 that it had
>>> printed for lo before (except for the LOOPBACK flag, but I can enable
>>> that one as well by adding IFF_LOOPBACK to the interface flags in the
>>> module). Yet my test application only works with lo, not eth2.
>>
>> Don't use loopback ip addresses; it makes no sense to do so. I've worked
>> on a couple opf nic implementations on FPGAs for a while now (a gige
>> implementation that works, and now a 10G nic), and it's easy enough to
>> develop it as a regular ethernet driver. You can write test programs that
>> use raw sockets to send/receive packets over the ethernet device, or use
>> pktgen to send packets. You don't even need to configure an ip address for
>> testing with raw packets. Testing with IP is a lot harder during early
>> bring-up of your hardware as it requires everything to work (that is, you
>> need ARP to work successfully before IP can work). Just stick to simple
>> packet injection initially, and don't confuse yourself by thinking about
>> the loopback device.
>
> Thank you for your very helpful mail. I haven't considered raw sockets, but it makes total sense now you mention it. This should give a lot less hassle.
>
> However, please let us try to clear up my (mis-)understanding. Even when I use non-looback addresses (e.g. 192.168.1.x) it does not work. For the ARP requirement I tried to workaround by using specifying the IFF_NOARP flag, and using the arp command line tool to populate the arp cache with the the MAC. With this, and all other interfaces down'ed, I cannot get transfers to work. The the sendto() (sending UDP datadagrams) call hangs while the ndk_start_xmit() method isn't even called. As works fine with the loopback interface I started to believe that I need to implement a real loopback interface. It is this supposed to work this way isn't it?
>
> Best regards.
I have found the root problem, that Linux does not allow local (same
machine) connections via any non-lo interface. See [1] and [2]. Whether
two NICs connected via crossover cable, or one NIC implementing a
loopback, the kernel routes transmission via "lo" (and if it's down'ed
there is no traffic at all).
This made me led me to the conclusion that I need a real (secondary)
loopback, because an ethX interface simply doesn't work.
According to [2], I have now baked a script which enables local
connections via non-lo interfaces, and I think I'm happy with it.
Do you guys now why linux makes it so hard (before 2.6.33 even
impossible) to set up local connections like this (for testing
purposes)? I understand that routing to lo is a strong optimization for
real traffic but it should be easy to opt out if routing through NICs is
really necessary as in my case.
Thank you for your patience and help.
Best regards.
[1]: http://www.zyztematik.com/?p=10
[2]:
http://umweltsuende.wordpress.com/2011/11/13/monolog-fur-linux-server-send-to-self-patch-alternative/
-----
visit us at
OFC 2013 / March 19-21 / Anaheim Convention Center, CA, USA / booth 11807
NABSHOW 2013 / April 8-11 / Las Vegas Convention Center, Nevada, USA / booth C7843
www.hhi.fraunhofer.de/events
^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2013-03-18 9:33 UTC | newest]
Thread overview: 24+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-03-12 12:05 Trying to implement secondary loopback Thomas Martitz
2013-03-13 11:13 ` richard -rw- weinberger
2013-03-13 20:38 ` Martitz, Thomas
2013-03-13 20:46 ` Eric W. Biederman
2013-03-13 21:07 ` AW: " Martitz, Thomas
2013-03-13 21:21 ` Eric W. Biederman
2013-03-13 22:01 ` AW: " Martitz, Thomas
2013-03-15 7:30 ` Thomas Martitz
2013-03-15 8:59 ` Eric W. Biederman
2013-03-15 13:49 ` Thomas Martitz
2013-03-15 13:56 ` richard -rw- weinberger
2013-03-15 14:08 ` Thomas Martitz
2013-03-15 14:16 ` richard -rw- weinberger
2013-03-15 14:20 ` Thomas Martitz
2013-03-15 14:32 ` richard -rw- weinberger
2013-03-15 14:35 ` Thomas Martitz
2013-03-15 14:45 ` richard -rw- weinberger
2013-03-15 14:50 ` Thomas Martitz
2013-03-15 15:07 ` Thomas Martitz
2013-03-15 15:15 ` Hannes Frederic Sowa
2013-03-15 15:37 ` Benjamin LaHaise
2013-03-15 19:48 ` Martitz, Thomas
2013-03-18 9:33 ` Thomas Martitz
2013-03-15 18:36 ` Ben Hutchings
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.