Hi David,
On 02/15/2016 11:21 AM, Hunt, David wrote:
> On 15/02/2016 10:15, Olivier MATZ wrote:
>> On 02/15/2016 10:58 AM, Hunt, David wrote:
>>> I'm working on that at the moment with the external mempool handler
>>> code. However, it crossed my mind that we have a choice to use symbol
>>>
Hi David,
On 02/15/2016 10:58 AM, Hunt, David wrote:
> On 12/02/2016 15:50, Olivier MATZ wrote:
>> - NEXT_ABI does make the code harder to read in this case, and I'm
>>thinking about the patchset from David Hunt (external mempool handler)
>>that will be in the same situation, and maybe
On 15/02/2016 10:15, Olivier MATZ wrote:
> Hi David,
>
> On 02/15/2016 10:58 AM, Hunt, David wrote:
>> On 12/02/2016 15:50, Olivier MATZ wrote:
>>> - NEXT_ABI does make the code harder to read in this case, and I'm
>>> thinking about the patchset from David Hunt (external mempool handler)
>>>
On 12/02/2016 15:50, Olivier MATZ wrote:
> - NEXT_ABI does make the code harder to read in this case, and I'm
>thinking about the patchset from David Hunt (external mempool handler)
>that will be in the same situation, and maybe also another patchset
>I'm working on.
Olivier,
I'm
Hi,
On 02/12/2016 04:38 PM, Thomas Monjalon wrote:
> OK, I'm going to sum it up with new words and let the conclusion comes
> from Keith, Panu and Olivier.
>
> We agreed to allow ABI breaking if a notification was done in the
> previous release.
> Keith has sent a notification for 16.04 so the
2016-02-12 15:07, Wiles, Keith:
> >On 02/12/2016 03:57 PM, Thomas Monjalon wrote:
> >> 2016-02-12 13:23, Panu Matilainen:
> >>> On 02/10/2016 11:18 PM, Keith Wiles wrote:
> static inline void *rte_mempool_get_priv(struct rte_mempool *mp)
> {
> +#ifdef RTE_NEXT_ABI
> +
On 02/12/2016 03:57 PM, Thomas Monjalon wrote:
> 2016-02-12 13:23, Panu Matilainen:
>> On 02/10/2016 11:18 PM, Keith Wiles wrote:
>>>static inline void *rte_mempool_get_priv(struct rte_mempool *mp)
>>>{
>>> +#ifdef RTE_NEXT_ABI
>>> + return (char *)mp +
>>> +
>Hi,
>
>On 02/12/2016 04:38 PM, Thomas Monjalon wrote:
>> OK, I'm going to sum it up with new words and let the conclusion comes
>> from Keith, Panu and Olivier.
>>
>> We agreed to allow ABI breaking if a notification was done in the
>> previous release.
>> Keith has sent a notification for 16.04
>2016-02-12 15:07, Wiles, Keith:
>> >On 02/12/2016 03:57 PM, Thomas Monjalon wrote:
>> >> 2016-02-12 13:23, Panu Matilainen:
>> >>> On 02/10/2016 11:18 PM, Keith Wiles wrote:
>> static inline void *rte_mempool_get_priv(struct rte_mempool *mp)
>> {
>> +#ifdef RTE_NEXT_ABI
>>
>On 02/12/2016 03:57 PM, Thomas Monjalon wrote:
>> 2016-02-12 13:23, Panu Matilainen:
>>> On 02/10/2016 11:18 PM, Keith Wiles wrote:
static inline void *rte_mempool_get_priv(struct rte_mempool *mp)
{
+#ifdef RTE_NEXT_ABI
+ return (char *)mp +
+
2016-02-12 13:23, Panu Matilainen:
> On 02/10/2016 11:18 PM, Keith Wiles wrote:
> > static inline void *rte_mempool_get_priv(struct rte_mempool *mp)
> > {
> > +#ifdef RTE_NEXT_ABI
> > + return (char *)mp +
> > + MEMPOOL_HEADER_SIZE(mp, mp->pg_num, mp->cache_size);
> > +#else
> >
On 02/10/2016 11:18 PM, Keith Wiles wrote:
> The rte_mempool structure is changed, which will cause an ABI change
> for this structure. Providing backward compat is not reasonable
> here as this structure is used in multiple defines/inlines.
>
> Allow mempool cache support to be dynamic depending
The rte_mempool structure is changed, which will cause an ABI change
for this structure. Providing backward compat is not reasonable
here as this structure is used in multiple defines/inlines.
Allow mempool cache support to be dynamic depending on if the
mempool being created needs cache support.
13 matches
Mail list logo