L2 MTU includes both payload and ethernet header. gVisor has supported setting
data link layer MTU, it will be up to users to set up proper value for a
device's MTU if a larger value is expected.
By doing the change, gVisor will be consistent with runc:
```shell
# runc
root@cec4d7238802:/# ip link set dev lo mtu 1234
root@cec4d7238802:/# ip link list dev lo
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 1234 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
# runsc before the change.
root@7cd89278d414:/# ip link set dev lo mtu 1234
root@7cd89278d414:/# ip link list dev lo
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 1220
link/loopback 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
# runsc after the change.
root@e811c5851226:/# ip link set dev lo mtu 1234
root@e811c5851226:/# ip link list dev lo
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 1234
link/loopback 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
```
PiperOrigin-RevId: 684746090
Marks the structs in netstack as savable. This does not change or break any
existing behavior as the netstack itself is not savable yet.
PiperOrigin-RevId: 635943481
Previously, when a packet was sent from a raw packet socket, the packet
buffer's link header was left unpopulated and the link header was only
found in the packet buffer's payload. This breaks the expectations of
LinkEndpoints which expect the link layer header to always be populated
when the link requires a header.
PiperOrigin-RevId: 542349445
In preparation for improving ARP handling of gratuitous ARPs, set PktType in
regular inbound flow instead of only when handling packet sockets.
PiperOrigin-RevId: 501562322
This change has significant performance implications. bufferv2 is reference
counted and pooled, which alleviates heap/GC pressure. Below are the results
from running the iperf benchmark.
HEAD:
BenchmarkIperf/operation.Upload-16 1552 ns/op 46.6GiB total allocations
BenchmarkIperf/operation.Download-16 1114 ns/op 68.6GiB total allocations
w/ change:
BenchmarkIperf/operation.Upload-16 1139 ns/op (-27%) 1.41GiB total allocations (-97%)
BenchmarkIperf/operation.Download-16 753.2 ns/op (-33%) 706MiB total allocations (-99%)
PiperOrigin-RevId: 462453185
The packetsocket link endpoint is used to enable a packet endpoint to
receive packets right before they are sent to the driver for outgoing
packets or right after they are recieved from the driver for incoming
packets.
Before this change, only packets that are sent/received by the
`stack.nic` were delivered to packet endpoints. However, the packet
endpoint should also receive packets that don't reach `stack.nic`.
Such an example can be when the interface is bridged and an incoming
packet is sent out through a sibling bridge port instead of being
delivered to a `stack.nic`.
The packetsocket link endpoint must wrap a link endpoint that
populates the link headers for ingress packets. It should ideally
be placed as low in the link endpoint heirarchy as possible so that
packets are probed as close to device drivers as possible.
https://github.com/google/gvisor/commit/2d9b33c0fd7d812a7296cd71f14c03925f815f28
removed the original packetsocket link endpoint which only allowed
low-level capturing of outbound packets but not inbound packets.
The CL mentioned above is cl/395761629.
PiperOrigin-RevId: 424947620
The arguments passed to LinkEndpoint.AddHeader are all available in
the packet buffer so just get the values from the packet buffer.
PiperOrigin-RevId: 424463821
This removes the need for the stack to add a link header out-of-line the
write path when delivering outbound packets to a packet socket.
PiperOrigin-RevId: 424444109
...as they are not used in all cases expect in the packet endpoint
which can get the link address directly from the link header.
PiperOrigin-RevId: 424427195
...instead of the arguments provided in the call to WritePackets.
QDisc always passes 0 for the protocol for calls to WritePackets as
each packet may have a different protocol number.
A later change will remove the unnecessary arguments from WritePackets.
PiperOrigin-RevId: 418513699
...to match Linux behaviour.
We can see evidence of Linux representing loopback as an ethernet-based
device below:
```
# EUI-48 based MAC addresses.
$ ip link show lo
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
# tcpdump showing ethernet frames when sniffing loopback and logging the
# link-type as EN10MB (Ethernet).
$ sudo tcpdump -i lo -e -c 2 -n
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on lo, link-type EN10MB (Ethernet), snapshot length 262144 bytes
03:09:05.002034 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype IPv4 (0x0800), length 66: 127.0.0.1.9557 > 127.0.0.1.36828: Flags [.], ack 3562800815, win 15342, options [nop,nop,TS val 843174495 ecr 843159493], length 0
03:09:05.002094 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype IPv4 (0x0800), length 66: 127.0.0.1.36828 > 127.0.0.1.9557: Flags [.], ack 1, win 6160, options [nop,nop,TS val 843174496 ecr 843159493], length 0
2 packets captured
116 packets received by filter
0 packets dropped by kernel
```
Wireshark shows a similar result as the tcpdump example above.
Linux's loopback setup: https://github.com/torvalds/linux/blob/5bfc75d92efd494db37f5c4c173d3639d4772966/drivers/net/loopback.c#L162
PiperOrigin-RevId: 391836719
