Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 11 Apr 2014 12:51:08 -0700
From:      Adrian Chadd <adrian@freebsd.org>
To:        Julian Elischer <julian@freebsd.org>
Cc:        FreeBSD Net <freebsd-net@freebsd.org>
Subject:   Re: Preventing ng_callout() timeouts to trigger packet queuing
Message-ID:  <CAJ-Vmom_gpLRMOEv4A9p21LwFb1Pvxv7eUUiQ8Zy1%2BrL6Jm9rA@mail.gmail.com>
In-Reply-To: <53483B8B.7030409@freebsd.org>
References:  <53459C96.5040304@gmail.com> <5345BAE7.4010501@gmail.com> <53483B8B.7030409@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Well, ethernet drivers nowdays seem to be doing:

* always queue
* then pop the head item off the queue and transmit that.


-a


On 11 April 2014 11:59, Julian Elischer <julian@freebsd.org> wrote:
> disclaimer: I'm not looking at the code now.. I want to go to bed:  :-)
>
> When I wrote that code, the idea was that even a direct node execution
> should become a queuing operation if there was already something else on the
> queue.  so in that model packets were not supposed to get re-ordered. does
> that not still work?
>
> Either that, or you need to explain the problem to me a bit better..
>
>
>
> On 4/10/14, 5:25 AM, Karim Fodil-Lemelin wrote:
>>
>> Hi,
>>
>> Below is a revised patch for this issue. It accounts for nodes or hooks
>> that explicitly need to be queuing:
>>
>> @@ -3632,7 +3632,12 @@ ng_callout(struct callout *c, node_p node, hook_p
>> hook, int ticks,
>>         if ((item = ng_alloc_item(NGQF_FN, NG_NOFLAGS)) == NULL)
>>                 return (ENOMEM);
>>
>> -       item->el_flags |= NGQF_WRITER;
>> +       if ((node->nd_flags & NGF_FORCE_WRITER) ||
>> +           (hook && (hook->hk_flags & HK_FORCE_WRITER)))
>> +         item->el_flags |= NGQF_WRITER;
>> +       else
>> +         item->el_flags |= NGQF_READER;
>> +
>>         NG_NODE_REF(node);              /* and one for the item */
>>         NGI_SET_NODE(item, node);
>>         if (hook) {
>>
>> Regards,
>>
>> Karim.
>>
>> On 09/04/2014 3:16 PM, Karim Fodil-Lemelin wrote:
>>>
>>> Hi List,
>>>
>>> I'm calling out to the general wisdom ... I have seen an issue in
>>> netgraph where, if called, a callout routine registered by ng_callout() will
>>> trigger packet queuing inside the worklist of netgraph since ng_callout()
>>> makes my node suddenly a WRITER node (therefore non reentrant) for the
>>> duration of the call.
>>>
>>> So as soon as the callout function returns, all following packets will
>>> get directly passed to the node again and when the ngintr thread gets
>>> executed then only then will I get the queued packets. This introduces out
>>> of order packets in the flow. I am using the current patch below to solve
>>> the issue and I am wondering if there is anything wrong with it (and maybe
>>> contribute back :):
>>>
>>>
>>> @@ -3632,7 +3632,7 @@ ng_callout(struct callout *c, node_p node, hook_p
>>> hook, int ticks,
>>>         if ((item = ng_alloc_item(NGQF_FN, NG_NOFLAGS)) == NULL)
>>>                 return (ENOMEM);
>>>
>>> -       item->el_flags |= NGQF_WRITER;
>>> +       item->el_flags = NGQF_READER;
>>>         NG_NODE_REF(node);              /* and one for the item */
>>>         NGI_SET_NODE(item, node);
>>>         if (hook) {
>>>
>>>
>>> Best regards,
>>>
>>> Karim.
>>> _______________________________________________
>>> freebsd-net@freebsd.org mailing list
>>> http://lists.freebsd.org/mailman/listinfo/freebsd-net
>>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
>>
>>
>> _______________________________________________
>> freebsd-net@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-net
>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
>>
>
> _______________________________________________
> freebsd-net@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-Vmom_gpLRMOEv4A9p21LwFb1Pvxv7eUUiQ8Zy1%2BrL6Jm9rA>