free(pkt)
> T1: interesting_data = read_from_pkt(pkt)
>
> In your scenario above: T2 cannot be issuing a read to pkt after
> ref_count is decremented because the only way that T2 could be
> decrementing ref_count would be if T2 issued an odp_packet_free() call
> for it. Obviously if
Add simple, copy based
>>> implementation first and continue development/optimization from there. So,
>>> that we can step back and compare easily with previous version, if e.g.
>>> race conditions are found.
>>>
>>> -Petri
>>>
>>>
>
tep back and compare easily with previous version, if e.g.
>> race conditions are found.
>>
>> -Petri
>>
>>
>> > -Original Message-----
>> > From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of
>> Bill
>> > Fischofer
>>
g.
> race conditions are found.
>
> -Petri
>
>
> > -Original Message-
> > From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of
> Bill
> > Fischofer
> > Sent: Saturday, February 18, 2017 6:28 PM
> > To: Francois Ozog <francoi
nal Message-
> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of Bill
> Fischofer
> Sent: Saturday, February 18, 2017 6:28 PM
> To: Francois Ozog <francois.o...@linaro.org>
> Cc: lng-odp@lists.linaro.org
> Subject: Re: [lng-odp] [API-NEXT PATCHv7 2/5] linux-g
the remaining reference between
>> >> steps 1 and 2, T1 may get even more interesting data.
>> >>
>> >> Right?
>> >
>> > I don't believe so. The semantics of odp_atomic_fetch_dec_u32(), which
>> > is what packet_ref_dec() u
> the buffer. Note that if I see ref_count == 1 no other thread can be
> > trying to increment it via a concurrent odp_packet_ref() call because
> > that would mean that two threads were trying to manipulate the same
> > odp_packet_t, which is prohibited
ulative executions are
> semantically consistent with sequential execution. If this were not
> the case you'd constantly have to worry about a processor turning
>
> T1: interesting_data = read_from_pkt(pkt)
> T1: packet_free(pkt)
>
> into
>
> T1: packet
d be
decrementing ref_count would be if T2 issued an odp_packet_free() call
for it. Obviously if it tries to reference pkt after such a call that
is an application error.
Thanks again for your much-appreciated help in looking at this!
>
> Janne
>
>
>> -
ent: Wednesday, January 11, 2017 4:34 AM
> To: lng-odp@lists.linaro.org
> Subject: [lng-odp] [API-NEXT PATCHv7 2/5] linux-generic: packet: implement
> reference apis
>
> Implement the APIs:
> - odp_packet_ref_static()
> - odp_packet_ref()
> - odp_packet_ref_pkt()
> - odp_pac
Implement the APIs:
- odp_packet_ref_static()
- odp_packet_ref()
- odp_packet_ref_pkt()
- odp_packet_has_ref()
- odp_packet_unshared_len()
This also involves functional upgrades to the existing packet manipulation
APIs to work with packet references as input arguments.
Signed-off-by: Bill
11 matches
Mail list logo
