From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Martitz Subject: Re: Trying to implement secondary loopback Date: Fri, 15 Mar 2013 16:07:32 +0100 Message-ID: <51433934.3080405@hhi.fraunhofer.de> References: <513F1A17.1000809@hhi.fraunhofer.de> <3D7E565A361FB844A410A5EFCDD7BA4002ECF5@MXSRV3.fe.hhi.de> <87r4jjav00.fsf@xmission.com> <3D7E565A361FB844A410A5EFCDD7BA4002EF11@MXSRV3.fe.hhi.de> <878v5r9es7.fsf@xmission.com> <5142CE23.9070804@hhi.fraunhofer.de> <87ip4t598t.fsf@xmission.com> <514326FF.6020205@hhi.fraunhofer.de> <51432B72.20408@hhi.fraunhofer.de> <51432E13.5060003@hhi.fraunhofer.de> <514331BC.4080802@hhi.fraunhofer.de> <5143353C.3050107 @hhi.fraunhofer.de> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Eric W. Biederman" , "netdev@vger.kernel.org" , "davem@davemloft.net" , "edumazet@google.com" , "herbert@gondor.apana.org.au" To: richard -rw- weinberger Return-path: Received: from mail.HHI.FRAUNHOFER.DE ([193.174.67.45]:60657 "EHLO mailgw.hhi.fraunhofer.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754428Ab3COPH1 (ORCPT ); Fri, 15 Mar 2013 11:07:27 -0400 In-Reply-To: <5143353C.3050107@hhi.fraunhofer.de> Sender: netdev-owner@vger.kernel.org List-ID: 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 >> wrote: >>> Am 15.03.2013 15:32, schrieb richard -rw- weinberger: >>> >>>> On Fri, Mar 15, 2013 at 3:20 PM, Thomas Martitz >>>> 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