On 6/19/15 1:02 PM, Thomas Monjalon wrote: > 2015-06-19 12:13, Thomas F Herbert: >> >> On 6/19/15 9:16 AM, Thomas Monjalon wrote: >>> 2015-06-19 09:02, Neil Horman: >>>> On Fri, Jun 19, 2015 at 02:32:33PM +0200, Thomas Monjalon wrote: >>>>> 2015-06-19 06:26, Neil Horman: >>>>>> On Thu, Jun 18, 2015 at 04:55:45PM +0000, O'Driscoll, Tim wrote: >>>>>>> For the 2.1 release, I think we should agree to make patches that change >>>>>>> the ABI controllable via a compile-time option. I like Olivier's >>>>>>> proposal >>>>>>> on using a single option (CONFIG_RTE_NEXT_ABI) to control all of these >>>>>>> changes instead of a separate option per patch set (see >>>>>>> http://dpdk.org/ml/archives/dev/2015-June/019147.html), so I think we >>>>>>> should rework the affected patch sets to use that approach for 2.1. >>>>>> >>>>>> This is a bad idea. Making ABI dependent on compile time options isn't a >>>>>> maintainable solution. It breaks the notion of how LIBABIVER is >>>>>> supposed to >>>>>> work (that is to say you make it impossible to really tell what ABI >>>>>> version you >>>>>> are building). >>>>> >>>>> The idea was to make LIBABIVER increment dependent of CONFIG_RTE_NEXT_ABI. >>>>> So one ABI version number refers always to the same ABI. >>>>> >>>>>> If you have two compile time options that modify the ABI, you >>>>>> have to burn through 4 possible LIBABIVER version values to accomodate >>>>>> all >>>>>> possible combinations, and then you need to remember that when you make >>>>>> them >>>>>> statically applicable. >>>>> >>>>> The idea is to have only 1 compile-time option: CONFIG_RTE_NEXT_ABI. >>>>> >>>>> Your intent when introducing ABI policy was to allow smooth porting of >>>>> applications from a DPDK version to another. Right? >>>>> The adopted solution was to provide backward compatibility during 1 >>>>> release. >>>>> But there are cases where it's not possible. So the policy was to notice >>>>> the future change and wait one release cycle to break the ABI (failing >>>>> compatibility goals). >>>>> The compile-time option may provide an alternative DPDK packaging when the >>>>> ABI backward compatibility cannot be provided (case of mbuf changes). >>>>> In such case, it's still possible to upgrade DPDK by providing 2 versions >>>>> of >>>>> DPDK libs. So the existing apps continue to link with the previous ABI and >>>>> have the possibility of migrating to the new one. >>>>> Another advantage of this approach is that we don't have to wait 1 release >>>>> to integrate the changes. >>>>> The last advantage is to benefit early of these changes with static >>>>> libraries. >>>> >>>> Hm, ok, thats a bit more reasonable, but it still seems shaky to me. >>>> Implementing an ABI preview option like this implies the notion that, >>>> after a >>>> release, you have to remove all the ifdefs that you inserted to create the >>>> new >>>> ABI. That seems like an easy task, but it becomes a pain when the ABI >>>> delta is >>>> large, and is predicated on the centralization of work effort (that is to >>>> say >>>> you need to identify someone to submit the 'remove the NEXT_ABI config >>>> ifdefs >>>> from the build' patch every release. >>> >>> It won't be so huge if we reserve the NEXT_ABI solution to changes which >>> cannot >>> have easy backward compatibility with the compat macros you introduced. >>> I feel I can do the job of removing the ifdefs NEXT_ABI after each release. >>> At the same time, the deprecated API, using the compat macros, will be >>> removed. >>> >>>> What might be better would be a dpdk-next branch (or even a dpdk-next >>>> tree, of >>>> the sort that Thomas Herbert proposed a few weeks ago). >>> >>> This tree was created after Thomas' request: >>> http://dpdk.org/browse/next/dpdk-next/ >> >> Thomas, I am sorry if I went quiet for awhile but I was on personal >> travel with inconsistent access so I almost missed most of this >> discussion about ABI changes. >> >> My understanding of the purpose of the dpdk-next tree is to validate >> patches by applying and compiling against a "pull" from the main dpdk >> tree. I think a good way to handle ABI change while effectively using >> the dpdk-next might be to do as follows: >> >> Create a specific branch for the new ABI such as 2.X in the main dpdk >> tree. Once that 2.X branch is created, dpdk-next would mirror the 2.X >> branch along with master. >> >> Since, dpdk-next would also have the 2.X branch that is in the main dpdk >> tree, submitted patches could be applied to either the main branch or >> the new-ABI 2.X branch. Providing that patch submitters make it clear >> whether a submitted patch is for the new ABI or the old ABI, dpdk-next >> could continue to validate the patches for either the main branch or the >> new ABI 2.X branch. > > What is the benefit of a new-ABI branch in the -next tree? I don't think that there is any specific benefit to an new-ABI branch in the dpdk-next tree. I was responding to the suggestion above and perhaps I missread it. It sounded like what was being proposed was to use the dpdk-next tree specifically for pre-integration of new-ABI. I don't think this is of any benefit either.
However if it should be decided to integrate new-ABI patches in a branch of dpdk rather then in a separate new-ABI tree, then net-next can "mirror" that branch along with the master branch so patches can be smoke tested whether they are submitted to the master or to the new-ABI branch. > > The goal of this discussion is to find a consensus on ABI policy to > smoothly integrate new features without forcing users of shared libraries > to re-build their application when upgrading DPDK, and let them do the > transition before the next upgrade. I understand this and I think it is a good suggestion to have a mechanism to ease the transition. >
