> > 2016-10-28 11:34, Ananyev, Konstantin: > > > > 2016-10-27 16:24, Ananyev, Konstantin: > > > > > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > > > > > > 2016-10-27 15:52, Ananyev, Konstantin: > > > > > > > > 2016-10-26 14:56, Tomasz Kulasek: > > > > > > > > > --- a/config/common_base > > > > > > > > > +++ b/config/common_base > > > > > > > > > +CONFIG_RTE_ETHDEV_TX_PREP=y > > > > > > > > > > > > > > > > We cannot enable it until it is implemented in every drivers. > > > > > > > > > > > > > > Not sure why? > > > > > > > If tx_pkt_prep == NULL, then rte_eth_tx_prep() would just act as > > > > > > > noop. > > > > > > > Right now it is not mandatory for the PMD to implement it. > > > > > > > > > > > > If it is not implemented, the application must do the preparation > > > > > > by itself. > > > > > > From patch 6: > > > > > > " > > > > > > Removed pseudo header calculation for udp/tcp/tso packets from > > > > > > application and used Tx preparation API for packet preparation and > > > > > > verification. > > > > > > " > > > > > > So how does it behave with other drivers? > > > > > > > > > > Hmm so it seems that we broke testpmd csumonly mode for non-intel > > > > > drivers.. > > > > > My bad, missed that part completely. > > > > > Yes, then I suppose for now we'll need to support both (with and > > > > > without) code paths for testpmd. > > > > > Probably a new fwd mode or just extra parameter for the existing one? > > > > > Any other suggestions? > > > > > > > > Please think how we can use it in every applications. > > > > It is not ready. > > > > Either we introduce the API without enabling it, or we implement it > > > > in every drivers. > > > > > > I understand your position here, but just like to point that: > > > 1) It is a new functionality optional to use. > > > The app is free not to use that functionality and still do the > > > preparation itself > > > (as it has to do it now). > > > All existing apps would keep working as expected without using that > > > function. > > > Though if the app developer knows that for all HW models he plans to > > > run on > > > tx_prep is implemented - he is free to use it. > > > 2) It would be difficult for Tomasz (and other Intel guys) to > > > implement tx_prep() > > > for all non-Intel HW that DPDK supports right now. > > > We just don't have all the actual HW in stock and probably adequate > > > knowledge of it. > > > So we depend here on the good will of other PMD mainaners/developers > > > to implement > > > tx_prep() for these devices. > > > From other side, if it will be disabled by default, then, I think, > > > PMD developers just wouldn't be motivated to implement it. > > > So it will be left untested and unused forever. > > > > Actually as another thought: > > Can we have it enabled by default, but mark it as experimental or so? > > If memory serves me right, we've done that for cryptodev in the past, no? > > Cryptodev was a whole new library. > We won't play the game "find which function is experimental or not". > > We should not enable a function until it is fully implemented. > > If the user really understands that it will work only with few drivers > then he can change the build configuration himself. > Enabling in the default configuration is a message to say that it works > everywhere without any risk. > It's so simple that I don't even understand why I must argue for. > > And by the way, it is late for 16.11.
Ok, I understand your concern about enabling it by default and testpmd breakage, but what else you believe is not ready? > I suggest to integrate it in the beginning of 17.02 cycle, with the hope > that you can convince other developers to implement it in other drivers, > so we could finally enable it in the default config. Ok, any insights then, how we can convince people to do that? BTW, it means then that tx_prep() should become part of mandatory API to be implemented by each PMD doing TX offloads, right? > > Oh, and I don't trust that nobody were thinking that it would break testpmd > for non-Intel drivers. Well, believe it or not, but yes, I missed that one. I think I already admitted that it was my fault, and apologized for that. But sure, it is your choice to trust me here or not. Konstantin
