netdev - Re: [PATCH] Packet socket: mmapped IO: PACKET_TX

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <7e0dd21a0811070836q8deb631qe8093282229b403e@mail.gmail.com>
Date:	Fri, 7 Nov 2008 17:36:06 +0100
From:	"Johann Baudy" <johaahn@...il.com>
To:	"Lovich, Vitali" <vlovich@...lcomm.com>
Cc:	"Evgeniy Polyakov" <zbr@...emap.net>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH] Packet socket: mmapped IO: PACKET_TX_RING

Hi Vitali.

> Which brings up a possible bug in the proposed patch - the mapped atomic int field should be part of the struct containing a ring buffer - each ring buffer has a different number of mappings.  Otherwise, there will be issues trying to create both a tx & rx ring.

Could you please clarify?
tx_pending_skb is only used for TX process.

> Are there any consequences to bypassing qdisc (other than not participating in any load balancing)?  Also, since any users using the tx ring approach would have to write new code, it would be part of the documentation that the send behaviour is optimized for the least latency and highest throughput, thus no guarantees and assumptions can be made about the path the data takes through the stack.
>
> I agree with you about not using the cb - I was just looking at all possible alternatives of how this can be solved.  I'm liking my approach of using the frag list because it's the least intrusive (doesn't require modification of the skb_buff structure) and the seems to be the most resilient (trying to hide data in some unused skb field and hope no one overwrites it)
>

My feeling is that all socket families have to use the same interface.
We must not bypass it, otherwise we're gonna make a mess.

I think we must not care about skb frags/device management to get
tpacket_hdr pointer back from skb. If it is changing tomorrow, we will
be in trouble.

A generic solution could be to forward a void* argument as the skb
destructor is forwarded through layers. Kind of:
skb->destructor(skb->desctructor_arg) when executing the callback. A
backup copy of destructor/destruct_arg pair should be performed if
someone needs to replace it.
This way all entities/layers could use this field to give an argument
to their destructor without adding a new field in sk_buff struct.

Thanks,
Johann
-- 
Johann Baudy
johaahn@...il.com
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html