netdev - Re: [PATCH 0/3] Basic deferred TX queue flushing infrastructure.

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]

Date:	Sat, 23 Aug 2014 21:38:39 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	netdev@...r.kernel.org
Cc:	therbert@...gle.com, jhs@...atatu.com, hannes@...essinduktion.org,
	edumazet@...gle.com, jeffrey.t.kirsher@...el.com,
	rusty@...tcorp.com.au
Subject: Re: [PATCH 0/3] Basic deferred TX queue flushing infrastructure.

From: David Miller <davem@...emloft.net>
Date: Sat, 23 Aug 2014 13:28:11 -0700 (PDT)

> This just adds the infrastructure, it does not actually add any
> instances of actually doing multiple ndo_start_xmit calls per
> ndo_xmit_flush invocation.

So today I was looking more into this aspect.

Like Tom Herbert has mentioned we have all the infrastructure (sort
of) already to handle a list of SKBs going down into
dev_hard_start_xmit() via the GSO handling.

But that code is funny, because it keeps the original GSO head SKB
around as a placeholder to maintain the list of segmented SKBs.

So the list walker basically walks starting at skb->next.  That's
awkward for what we want to do, which is pass in an arbitrary list of
SKBs.

All it really wants that head SKB for is essentially list management,
which seems like overkill to me.

Anyways, this got me thinking that we should have something that
provides the segment list management and stop keeping that head GSO
SKB around.

Then we can make that "gso:" label list walker generic enough that we
could pass down arbitrary lists of SKBs from the qdisc_restart() path.

This list management seems to be the only reason why we keep the GSO
head SKB around after dev_gso_segment(), we should be able to free it
up early without any problems right?

I'm also thinking about whether we should hang the generic SKB list
management off of the txq or the qdisc.  Right now the gso_skb thing
is in the qdisc.

Thoughts?
--
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