[Click] Blocking queue element?

[Eddie Kohler]

Hi guys,

I implemented a little something that may simulate this "blocking queue".

Try a "FullNoteQueue" in place of a Queue.  The "FullNoteQueue" has a notifier 
bit that it turns on when it is full.  The upstream FromHost now looks 
downstream for this kind of bit, and I believe (not super well tested) that it 
will correctly tell Linux that the device is "busy" until the FullNoteQueue 
drains.

There are a couple reasons why this might fail.  If the path branches after 
FromHost, and there are any regular Queues or Discards or anything other than 
FullNoteQueues, then it will fail "gracefully" back to the old behavior.

Anyway, let me know if this works or doesn't!
Eddie



John Bicket wrote:
> It would get blocked - linux will buffer a small number of
> packets per socket before blocking it (even if it's not tcp), and this 
> will fill up if a device queue is marked as busy.  This is why 
> you can't really do udp tests at userlevel when using fromhost 
> configurations - you end up sending so many packets, and they 
> all get dropped when they hit click's queue.
> 
> --john
> 
> 
> Eddie Kohler [kohler at cs.ucla.edu] wrote:
> 
>>Hmm.  I'm not sure that your ping process would get blocked without 
>>Click, would it?  I mean Click's queue happens below the IP layer.
>>
>>However, it is true that Click's "device queue" is not being reflected 
>>in its "device".  What you want is for Click's FromHost element to mark 
>>itself as "busy", if the Click Queue is relatively full.
>>
>>Are you up for some hacking?  You could hack FromHost to mark itself 
>>busy when the particular downstream Queue is full -- or even just 
>>change it to mark itself busy randomly, and see whether this blocks the 
>>upstream ping process.  If it _would_ block that process, then we can 
>>work on making FromHost "do the right thing".
>>
>>Eddie
>>
>>
>>Charles Reis wrote:
>>
>>>Thanks--
>>> It looks like that would work for TCP connections (which adjust when 
>>>they see dropped packets), but my current experiment involves sending 
>>>a ping flood.  With either Queue or RED, most of the packets will end 
>>>up dropped unless the ping process is blocked (as it normally would be 
>>>without Click).
>>>
>>> Any other thoughts?  I'll probably try the InfiniteSource element as 
>>>an alternative to ping, but this issue seems like it could come up in 
>>>many contexts.
>>>
>>>Thanks,
>>>Charlie
>>>
>>>
>>>Beyers Cronje wrote:
>>>
>>>
>>>>Hi,
>>>>
>>>>Have a look at RED  http://www.pdos.lcs.mit.edu/click/doc/RED.n.html 
>>>>and http://www.pdos.lcs.mit.edu/click/doc/AdaptiveRED.n.html 
>>>>AdaptiveRED elements.
>>>>"Random Early Detection (RED) is a congestion avoidance mechanism 
>>>>designed for packet switched networks that aims to control the 
>>>>average queue size by indicating to the end hosts when they should 
>>>>temporarily stop sending packets." 
>>>>http://www.cisco.com/warp/public/732/Tech/red/
>>>>
>>>>
>>>>------------------------------------------------------------------------
>>>>*From:* click-bounces at amsterdam.lcs.mit.edu on behalf of Charles Reis
>>>>*Sent:* Wed 2004/09/22 09:25 PM
>>>>*To:* click at amsterdam.lcs.mit.edu
>>>>*Subject:* [Click] Blocking queue element?
>>>>
>>>>Hi--
>>>>  I'm using Click and the stripped madwifi driver, with a click
>>>>configuration based on the gen_config_pseudo_ibss.pl script that comes
>>>>with the driver.
>>>>
>>>>  I've noticed that any packets sent out while the Queue element is
>>>>full are simply dropped.  Are there any elements that cause the sender
>>>>to block instead if the queue is full?
>>>>
>>>>Thanks,
>>>>Charlie Reis
>>>>_______________________________________________
>>>>click mailing list
>>>>click at amsterdam.lcs.mit.edu
>>>>https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>>>>
>>>>This is an email from CS Holdings. It is confidential to the ordinary 
>>>>user of the email address to which it is addressed and may contain 
>>>>copyright and/or legally privileged information. No one else may 
>>>>read, print, store, copy, forward or act in reliance upon all or any 
>>>>part of it or its attachments. If you received this email in error 
>>>>please notify its sender.
>>>>
>>>
>>>_______________________________________________
>>>click mailing list
>>>click at amsterdam.lcs.mit.edu
>>>https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>>
>>_______________________________________________
>>click mailing list
>>click at amsterdam.lcs.mit.edu
>>https://amsterdam.lcs.mit.edu/mailman/listinfo/click