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). > 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. > 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. > 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? -- Stuart. _______________________________________________ lng-odp mailing list [email protected] https://lists.linaro.org/mailman/listinfo/lng-odp
