On Mon, Jan 12, 2015 at 02:03:00PM +0000, Maxim Uvarov wrote: > On 01/08/2015 07:09 PM, Stuart Haslam wrote: > > Create a new linux-generic pktio type ODP_PKTIO_TYPE_LOOPBACK which > > will be used when the "loop" device is opened. A queue is used to > > connect the pktio output queue to the input queue. Packets sent to the > > loopback device are classified before making it to the input queue. > > I like that idea to create fully virtual loop dev. But how classifier > works for hardware case loop back device? > Is it always on?
This is a linux-generic implementation, platforms with a hardware classifier wouldn't reuse this code. I'd expect them to have their own mechanism for identifying and setting up a "loop" device. > > I'm a not sure if separate queue is needed. There are in/out and you > added loop. There may not be an input queue if the application is calling _recv() directly. Also the input queue is the default input queue, which may not be the one you want to deliver too after classification. > In general loop should emulate > in/out queue. It depends, in this case I've chosen to emulate the transport mechanism. The distinction is really whether packets are parsed and classified, and part of the motivation for this RFC was to have something that could be used to test the classifier. > Need to check what should other API do with that queue, > like: odp_pktio_inq_remdef(loop). They'll be unaffected (as long as the loopq remains). The only things that needed attention were those that touch the socket layer. > > 1500 as default MTU is better to set up to some define. Like if_ether.h: > ETH_DATA_LEN > I agree but I think it can be local to odp_packet_io.c, callers should get the value via the API call. > btw, can you please review v7 patch for odp_pktio_inq_remdef() ? > Will do. > BR, > Maxim. > -- Stuart. _______________________________________________ lng-odp mailing list [email protected] http://lists.linaro.org/mailman/listinfo/lng-odp
