> On Fri, Jun 28, 2013 at 10:42:13PM +0900, FUJITA Tomonori wrote: >> On Mon, 10 Jun 2013 11:00:18 +0900 >> Isaku Yamahata <yamah...@valinux.co.jp> wrote: >> >> > The patch teaches packet library to truncate padding octets. >> > The protocol class that knows its payload length should set its payload >> > length as payload_length > 0 attributes. >> > Then, the packet.parser truncates its payload. >> > If payload_length = 0, do nothing. >> > >> > Cc: YAMAMOTO Takashi <yamam...@valinux.co.jp> >> > Cc: Shaun Crampton <shaun.cramp...@metaswitch.com> >> > Signed-off-by: Isaku Yamahata <yamah...@valinux.co.jp> >> > --- >> > Changes v1 -> v2: >> > - typo in ipv4 >> > - s/payload_length_/payload_length/g >> > --- >> > ryu/lib/packet/ipv4.py | 2 ++ >> > ryu/lib/packet/lldp.py | 1 + >> > ryu/lib/packet/packet.py | 4 ++++ >> > ryu/lib/packet/packet_base.py | 1 + >> > ryu/lib/packet/udp.py | 2 ++ >> > 5 files changed, 10 insertions(+) >> >> _payload_length is better since this is used internally? We will >> support the feature to print protocol headers like we are trying to do >> with OF? >> >> Some protocols (ipv6, other?) have payload_length. If a protocol has >> payload_length then we can use it instead of adding _payload_length >> that has the exact same value. > > It sounds a good idea to try payload_length first, then try _payload_length. > I'll prepare v3 patch.
i don't think it's a good idea to make the protocol-independent code look at fields of specific protocols. isn't it better to make parser methods return (header, next_type, rest_of_packet)? this way you can clean up another side channel, proto.length, as well. YAMAMOTO Takashi > -- > yamahata ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ Ryu-devel mailing list Ryu-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ryu-devel
