I've just looked at packet_info structure (epan/packet_info.h) and it's huge
- everybody keeps something there.
1. I wonder how many times its allocated/de-allocated in a capture -
reducing its size (and perhaps creating a pool of pinfo's) might help in
performance. I suspect we have 1 per packet, right? For big captures, it
would cost in a lot of memory allocations.
2. Reducing its size may help in performance (more such structs in cache).
Even memset'ing a smaller structure would be nice and BTW, if all of it was
memset, what's the point (epan/packet.c) in:
edt->pi.dl_src.type = AT_NONE;
edt->pi.dl_dst.type = AT_NONE;
edt->pi.net_src.type = AT_NONE;
edt->pi.net_dst.type = AT_NONE;
edt->pi.src.type = AT_NONE;
edt->pi.dst.type = AT_NONE;
Isn't all that zero already?
Concrete examples;
guint32 ethertype; /* Ethernet Type Code, if this is an Ethernet
packet */ - isn't guint16 enough?
guint32 ipproto; /* IP protocol, if this is an IP packet */ -
even guint8 is enough.
guint32 srcport; /* source port */ - isn't guint16 enough?
guint32 destport; /* destination port */ - isn't guint16 enough?
guint32 match_port; /* matched port for calling subdissector
from table */ - isn't guint16 enough?
int p2p_dir; /* Packet was captured as an
outbound (P2P_DIR_SENT)
inbound (P2P_DIR_RECV)
unknown (P2P_DIR_UNKNOWN) */
an int just for this?
I imagine for performance reasons some are better left 32bit, but I think
there are plenty of options for reducing the overall size of this structure.
I would also be happy if protocols perhaps could have kept their own data in
some more organized structure, for example, something like
struct _gssapi_info_t* gssapi_info
which would point to a structure that would hold (if needed, and only
allocated if needed!):
guint16 decrypt_gssapi_tvb;
tvbuff_t *gssapi_wrap_tvb;
tvbuff_t *gssapi_encrypted_tvb;
tvbuff_t *gssapi_decrypted_tvb;
gboolean gssapi_data_encrypted;
similar to:
struct _sccp_msg_info_t* sccp_info
___________________________________________________________________________
Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org>
Archives: http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
