[Click] Strange buffer_length() value for packets of more than 1500 bytes

[Eddie Kohler]

Hi Bobby, all,

Thanks for reminding us of this issue, which has been around for a long 
time.  It may or may not have been Manel's problem but seems pretty 
likely.  I've applied a patch that may help:

https://github.com/kohler/click/commit/ee66e4894316dd99579e3a42696ea41c4eadd646

This is not well tested, so any feedback would be appreciated.

Eddie


On 12/17/10 12:55 PM, Bobby Longpocket wrote:
> Hi Roman,
>
> It looks like that patch set was for fixing PollDevice handling, not FromDevice.
>
> To use FromDevice with an arbitrary network driver, I think you need to call skb->skb_linearize() before you make the packet from the sk_buff. Not very efficient, but if you're looking for performance you need to use PollDevice, anyway.
>
> Bobby
>
>
> --- On Fri, 12/17/10, Roman Chertov<rchertov at cs.ucsb.edu>  wrote:
>
>> From: Roman Chertov<rchertov at cs.ucsb.edu>
>> Subject: Re: [Click] Strange buffer_length() value for packets of more than 1500 bytes
>> To: click at amsterdam.lcs.mit.edu, "Bobby Longpocket"<bobbylongpocket at yahoo.com>
>> Date: Friday, December 17, 2010, 11:43 AM
>> Bobby,
>>
>> I believe the jumbo frame problem was fixed.  See
>> http://www.mail-archive.com/click@amsterdam.lcs.mit.edu/msg03800.html
>>
>> Roman
>>
>> On Fri, 17 Dec 2010 11:35:16 -0800 (PST) Bobby Longpocket
>> <bobbylongpocket at yahoo.com>
>> wrote
>>
>>> Hi Manel,
>>>
>>> My guess is that it is related to the Ethernet driver
>> on the receive side.
>>> When you set the MTU higher (into jumbogram
>> territory), it probably changes
>>> the receive mechanism to store only the first part of
>> the packet in the
>>> 'data' part of the buffer and sticks the rest off in
>> the 'frags' area of the
>>> buffer.  Probably your version of Click doesn't
>> support packets that are
>>> stored this way (and, for all I know, none do).
>>>
>>> Bobby
>>>
>>>
>>>> Hi all,
>>>>
>>>> I am using linuxmodule click-1.7 over
>> linux-2.6.24.7 (but
>>>> this is also
>>>> the case with linux-2.6.18.2)
>>>> If I send packets of 1480 bytes and with the
>> default mtu of
>>>> 1500, the
>>>> the buffer size allocated at the receiver is of
>> 1664,
>>>>
>>>> (p->buffer_length()= 1664 ) which is fine.
>>>> However, when I send large packets of more than
>> 1500 bytes,
>>>> and set
>>>> the mtu to a value>  1500,  the buffer
>> allocated at
>>>> the reception is
>>>> always of 256 ((p->buffer_length()= 256))
>> whatever the
>>>> packet size is.
>>>> So, if I want to access to the data stored beyond
>> the 256
>>>> bytes in
>>>> that packet, the data I get is erroneous.
>>>> So i am wondering if there is a limitation on the
>> maximum
>>>> buffers
>>>> size? where this limitation is hard-coded? and
>> why does it
>>>> change with
>>>> the mtu?
>>>>
>>>> Thanks for helping
>>>>
>>>>
>>>> Ps: Click scripts are roughly :
>>>>
>>>> Sender :
>>>> RatedSource ->UDPIPEncap ->  EtherEncap
>> ->
>>>> ToDevice(eth0)
>>>> Receiver:
>>>> FromDevice(eth0) ->  Myelement ->  Discard
>>>>
>>>> In Myelement, I only get p->buffer_length()
>> and p->
>>>> data() and p->end_data()
>>>>
>>>>
>>>> Manel BOURGUIBA
>>>> PhD Candidate
>>>> PHARE - LIP6 - UPMC - Sorbonne Universit?s
>>>> BC169 - Office 25/26-319
>>>> 4 place Jussieu
>>>> 75252 PARIS cedex 05
>>>> +33 1 44 27 61 88
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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