Cong Wang writes:
> On Fri, Jul 10, 2020 at 7:40 AM Petr Machata wrote:
>>
>>
>> Cong Wang writes:
>>
>> > On Wed, Jul 8, 2020 at 5:13 PM Petr Machata wrote:
>> >>
>> >>
>> >> Petr Machata writes:
>> >>
>> >> > Cong Wang writes:
>> >> >
>> >> > I'll think about it some more. For now I will
On Fri, Jul 10, 2020 at 7:40 AM Petr Machata wrote:
>
>
> Cong Wang writes:
>
> > On Wed, Jul 8, 2020 at 5:13 PM Petr Machata wrote:
> >>
> >>
> >> Petr Machata writes:
> >>
> >> > Cong Wang writes:
> >> >
> >> > I'll think about it some more. For now I will at least fix the lack of
> >> > loc
Cong Wang writes:
> On Wed, Jul 8, 2020 at 5:13 PM Petr Machata wrote:
>>
>>
>> Petr Machata writes:
>>
>> > Cong Wang writes:
>> >
>> > I'll think about it some more. For now I will at least fix the lack of
>> > locking.
>>
>> I guess I could store smp_processor_id() that acquired the lock
On Wed, Jul 8, 2020 at 5:13 PM Petr Machata wrote:
>
>
> Petr Machata writes:
>
> > Cong Wang writes:
> >
> > I'll think about it some more. For now I will at least fix the lack of
> > locking.
>
> I guess I could store smp_processor_id() that acquired the lock in
> struct qdisc_skb_head. Do a t
Petr Machata writes:
> Cong Wang writes:
>
> I'll think about it some more. For now I will at least fix the lack of
> locking.
I guess I could store smp_processor_id() that acquired the lock in
struct qdisc_skb_head. Do a trylock instead of lock, and on fail check
the stored value. I'll need
Cong Wang writes:
> On Wed, Jul 8, 2020 at 5:35 AM Petr Machata wrote:
>> Do you have another solution in mind here? I think the deadlock (in both
>> classification and qevents) is an issue, but really don't know how to
>> avoid it except by dropping the lock.
>
> Ideally we should only take t
On Wed, Jul 8, 2020 at 9:21 AM Petr Machata wrote:
>
> Actually I guess I could qdisc_refcount_inc() the current qdisc so that
> it doesn't go away. Then when enqueing I could access the child
> directly, not relying on the now-obsolete cache from the beginning of
> the enqueue function. I suppose
On Wed, Jul 8, 2020 at 5:35 AM Petr Machata wrote:
> Do you have another solution in mind here? I think the deadlock (in both
> classification and qevents) is an issue, but really don't know how to
> avoid it except by dropping the lock.
Ideally we should only take the lock once, but it clearly r
Petr Machata writes:
> Cong Wang writes:
>
>> On Tue, Jul 7, 2020 at 8:22 AM Petr Machata wrote:
>>>
>>>
>>> Cong Wang writes:
>>>
>>> > On Fri, Jun 26, 2020 at 3:46 PM Petr Machata wrote:
>>> >> The function tcf_qevent_handle() should be invoked when qdisc hits the
>>> >> "interesting even
Cong Wang writes:
> On Tue, Jul 7, 2020 at 8:22 AM Petr Machata wrote:
>>
>>
>> Cong Wang writes:
>>
>> > On Fri, Jun 26, 2020 at 3:46 PM Petr Machata wrote:
>> >> The function tcf_qevent_handle() should be invoked when qdisc hits the
>> >> "interesting event" corresponding to a block. This
Cong Wang writes:
> On Fri, Jun 26, 2020 at 3:46 PM Petr Machata wrote:
>> The function tcf_qevent_handle() should be invoked when qdisc hits the
>> "interesting event" corresponding to a block. This function releases root
>> lock for the duration of executing the attached filters, to allow pa
On Fri, Jun 26, 2020 at 3:46 PM Petr Machata wrote:
> The function tcf_qevent_handle() should be invoked when qdisc hits the
> "interesting event" corresponding to a block. This function releases root
> lock for the duration of executing the attached filters, to allow packets
> generated through u
On Tue, Jul 7, 2020 at 8:22 AM Petr Machata wrote:
>
>
> Cong Wang writes:
>
> > On Fri, Jun 26, 2020 at 3:46 PM Petr Machata wrote:
> >> The function tcf_qevent_handle() should be invoked when qdisc hits the
> >> "interesting event" corresponding to a block. This function releases root
> >> loc
Cong Wang writes:
> On Fri, Jun 26, 2020 at 3:46 PM Petr Machata wrote:
>> The function tcf_qevent_handle() should be invoked when qdisc hits the
>> "interesting event" corresponding to a block. This function releases root
>> lock for the duration of executing the attached filters, to allow pa
On Fri, Jun 26, 2020 at 3:46 PM Petr Machata wrote:
> The function tcf_qevent_handle() should be invoked when qdisc hits the
> "interesting event" corresponding to a block. This function releases root
> lock for the duration of executing the attached filters, to allow packets
> generated through u
Qevents are attach points for TC blocks, where filters can be put that are
executed when "interesting events" take place in a qdisc. The data to keep
and the functions to invoke to maintain a qevent will be largely the same
between qevents. Therefore introduce sched-wide helpers for qevent
manageme
16 matches
Mail list logo
