On 9 September 2015 at 06:24, Stuart Haslam <[email protected]> wrote:
> On Tue, Sep 08, 2015 at 02:38:01PM -0400, Mike Holmes wrote: > > On 7 September 2015 at 06:01, Stuart Haslam <[email protected]> > > wrote: > > > > > On Mon, Sep 07, 2015 at 10:42:13AM +0300, Maxim Uvarov wrote: > > > > On 09/04/15 20:37, Bala Manoharan wrote: > > > > >This method of using pcap file to generate packets is fine. > > > > >But why should we use a dedicated interface with "pcap" as the name? > > > > > > > > > >I was imagining something like an ODP application which reads from a > > > > >given pcap file constructs the packet and sends the packet through > an > > > > >interface. > > > > > > > > > >The concern I have is this method of creating a dummy interface with > > > > >"pcap" name will work fine in Linux-generic code but if you want to > do > > > > >the same in other platforms then the platforms will have to > implement > > > > >this virtual pcap interface but if this was an ODP application then > > > > >the platforms can simply run the application over their platform > > > > >without any change. > > > > > > > > > >Regards, > > > > >Bala > > > > > > > > It can be both app and pktio. For linux-generic it useful for > > > > testing. Other platforms can implement > > > > that packet io or not. It's it's up to platform implementers > > > > decision. Anyway different platforms > > > > have different names for packet i/o. > > > > > > > > BR, > > > > Maxim. > > > > > > Yes, what Maxim said. > > > > > > This is linux-generic specific (unlike the loop interface which is > > > defined in the API), it's really intended for developer testing with > > > existing applications. > > > > > > > I don’t see the value of writing something only for linux-generic that is > > so close to useful for all platform testing, > > My point was that this patch series doesn't put a strict requirement on > the implementation to support reading packets from a pcap file, which > would be the case if this was defined in the API like the loop interface. > > Any platform that does support using pcap files *could* implement this > interface (and probably reuse the implementation). > I may be missing something, but *could* means that this is only ever useful to linux-generic because we cant use it in any other way since it might not be available and cant be depended on in shared examples, applications etc. > > > we need to extend the > > validation tests to run with canned traffic to get some more realistic > > coverage. > > This is intended to make functional testing of an *application* easier. > It doesn't really help with the test/validation/ tests as they're > testing the implementation. > But only a linux-generic application, because it may not be supported anywhere else,. Is it realistic that real applications get written only on the reference model and not originally on a proper performance target ? It feels very limiting. > > > This should be and application that is spawned by the test scripting to > > achieve exactly the cases you describe but in a platform independent way > I > > think. > > Of course there are plenty of other ways to test, like having a separate > application that spews packets over a test interface that's connected to > the application you're testing, which I think is what you're suggesting. > I was actually testing this way previously (using a veth pair and > tcpreplay), but it's cumbersome and depends on a bunch of stuff that I'm > not interested in testing when all I want is to get packets into my > application. But they aren't mutually exclusive. > Agree, I don’t say this cant be part of linux-generic, but it feels like we miss a bigger opportunity. > > > For example taking the first case, to a user this only changes to > > > > odp_classifier*_run* -ipcap:in=test.pcap -p -m 0 > > "ODP_PMR_SIP_ADDR:192.168.111.2:FFFFFFFF:queue1" -t 5 > > > > Now the interfaces are connected by the script between the pcap generator > > and the application under test. > > I don't really understand what you're suggesting here, how are they > connected? > The platform dependant run script takes care of connecting the pcap player to the pktio of the application under test, thus it takes the arguments for which pcap files to run rather then the application. I assume a very generic run script can be created to connect the two in linux and if nothing else we should connect things using ODP IPC when it lands to avoid the need to work with the OS to get the connection between an application under test and a generator. I don’t want this conversation to stifle a tool that makes things easier though. > > -- > Stuart. > -- Mike Holmes Technical Manager - Linaro Networking Group Linaro.org <http://www.linaro.org/> *│ *Open source software for ARM SoCs
_______________________________________________ lng-odp mailing list [email protected] https://lists.linaro.org/mailman/listinfo/lng-odp
