netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Thomas Martitz <thomas.martitz@hhi.fraunhofer.de>
Cc: richard -rw- weinberger <richard.weinberger@gmail.com>,
	"netdev\@vger.kernel.org" <netdev@vger.kernel.org>,
	"davem\@davemloft.net" <davem@davemloft.net>,
	"edumazet\@google.com" <edumazet@google.com>,
	"herbert\@gondor.apana.org.au" <herbert@gondor.apana.org.au>
Subject: Re: Trying to implement secondary loopback
Date: Fri, 15 Mar 2013 01:59:30 -0700	[thread overview]
Message-ID: <87ip4t598t.fsf@xmission.com> (raw)
In-Reply-To: <5142CE23.9070804@hhi.fraunhofer.de> (Thomas Martitz's message of "Fri, 15 Mar 2013 08:30:43 +0100")

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

  reply	other threads:[~2013-03-15  8:59 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
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
  -- strict thread matches above, loose matches on Subject: below --
2013-03-11  9:49 Thomas Martitz
2013-03-11  9:25 Thomas Martitz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87ip4t598t.fsf@xmission.com \
    --to=ebiederm@xmission.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=netdev@vger.kernel.org \
    --cc=richard.weinberger@gmail.com \
    --cc=thomas.martitz@hhi.fraunhofer.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).