> Once it figures out which gso_inner_segment to use, it calls
> __skb_udp_tunnel_segment with it, which then does some curious header
> calculations on various lengths (that I need to read carefully), and
> then proceeds to split the segments using our gso_inner_segment
> function of choice, and t
On Mon, Nov 9, 2015 at 2:40 AM, Herbert Xu wrote:
> You're right. I don't think the ordering matters.
Cool, so we're on the same page then.
In that case, any ideas about constructing UDP super-packets for GSO?
As Maciej pointed out, UFO is actually just IP fragmentation and UDP
checksums, but d
On Sun, Nov 08, 2015 at 03:57:24PM +0100, Jason A. Donenfeld wrote:
> On Sun, Nov 8, 2015 at 11:57 AM, Herbert Xu
> wrote:
> > UDP carries no ordering information so this doesn't work.
>
> But if there's no ordering information, what's the problem? Isn't it
> good enough to send the packets in t
On Sun, Nov 8, 2015 at 11:57 AM, Herbert Xu wrote:
> UDP carries no ordering information so this doesn't work.
But if there's no ordering information, what's the problem? Isn't it
good enough to send the packets in the order they were sendto()d? Or
in any order at all?
--
To unsubscribe from this
On Sun, Nov 08, 2015 at 11:36:53AM +0100, Jason A. Donenfeld wrote:
>
> Wouldn't there be some significant savings from bundling together
> several UDP packets meant for the same destination, and sending those
> all as one super-packet, so they don't each have to traverse the whole
> networking and
Hi Maciej,
On Sun, Nov 8, 2015 at 12:40 AM, Maciej Żenczykowski
wrote:
> This isn't particularly efficient. This is basically equivalent to doing
> GSO before the superpacket reaches your driver (you might get some
> savings by not bothering to look at the packet headers of the second
> and on p
> What I was thinking about is this: My driver receives a super-packet.
> By calling skb_gso_segment(), I'm given a list of equal sized packets
> (of gso_size each), except for the last one which is either the same
> size or smaller than the rest. Let's say calling skb_gso_segment()
> gives me a li
Hi Maciej,
Thanks for your reply. Some interesting things to consider here... See
inline below.
On Sat, Nov 7, 2015 at 6:19 PM, Maciej Żenczykowski
wrote:
>
> UFO will never collapse multiple (UDP) packets.
>
> It would be incorrect to do so, since UDP has to maintain packet
> framing boundaries
> I suppose this is about UFO.
>
> Specifically -- let's say I have a list of 500 skbs, which have their
> data in place but don't yet have an IP or UDP header etc. I want to
> send out these out using udp_tunnel_xmit_skb. Right now, if I just
> send them all out, one after another, they don't seem
Hi Tom,
On Fri, Nov 6, 2015 at 8:19 AM, Tom Herbert wrote:
> Is this about UFO or GSO (in email subject)? UFO should operate
> independently encapsulation or inner packet setting.
I suppose this is about UFO.
Specifically -- let's say I have a list of 500 skbs, which have their
data in place bu
On Thu, Nov 5, 2015 at 7:52 PM, Jason A. Donenfeld wrote:
> Hi folks,
>
> When sending arbitrary SKBs with udp_tunnel_xmit_skb, the networking
> stack does not appear to be utilizing UFO on the outgoing UDP packets,
> which significantly caps the transmission speed. I see about 50% CPU
> usage in
Hi folks,
When sending arbitrary SKBs with udp_tunnel_xmit_skb, the networking
stack does not appear to be utilizing UFO on the outgoing UDP packets,
which significantly caps the transmission speed. I see about 50% CPU
usage in this send path, triggered for every single outgoing packet.
Is there a
12 matches
Mail list logo
