summaryrefslogtreecommitdiff
path: root/bpf.h
AgeCommit message (Collapse)AuthorFilesLines
2014-04-22bpf: Remove unncessary #include <xmalloc.h> from bpf.hTobias Klauser1-1/+1
Only die.h is needed in the header for panic(). Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
2013-07-09configure: fix multiple issues in build configurationDaniel Borkmann1-1/+2
This patch is a bundle of multiple fixes. 1) Fix compilation of astraceroute when HAVE_LIBPCAP=1: astraceroute doesn't need libpcap, so add an additional guard/define to bpf.h and bpf_comp.c and netsniff-ng.c. Also since we generate a config.h file, we do not need to have this additional compile flag anymore. 2) Fix tstamping.{h,c} to use the configure script instead of the Makefile. For doing this, also fix the object inclusion in netsniff-ng/Makefile. Last but not least, rename __WITH_... into HAVE_... as this is more clean. Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
2013-06-04bpf: split up instructions and extensions from headerDaniel Borkmann1-98/+2
Move them into a separate header file, so that it is more clean. Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
2013-06-04misc: cleanup header commentsDaniel Borkmann1-6/+0
Remove header comments where appropriate. And also clean up colorize a bit. Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
2013-05-24misc: fix some minor compile warnings all overDaniel Borkmann1-2/+3
Some regarding unused parameter, some regarding signed/unsigned comparison. Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
2013-03-19bpfc: filter: add poff ancillary operationDaniel Borkmann1-0/+3
In preparation for [1], add the #poff operation, so that users can dynamically truncate packets on the payload start offset. This is useful for several reasons: privacy, speed, ... Example for bpfc: ld #poff ret a [1] http://thread.gmane.org/gmane.linux.network/262512 Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
2013-03-15all: import netsniff-ng 0.5.8-rc0 sourceDaniel Borkmann1-0/+135
We decided to get rid of the old Git history and start a new one for several reasons: *) Allow / enforce only high-quality commits (which was not the case for many commits in the history), have a policy that is more close to the one from the Linux kernel. With high quality commits, we mean code that is logically split into commits and commit messages that are signed-off and have a proper subject and message body. We do not allow automatic Github merges anymore, since they are total bullshit. However, we will either cherry-pick your patches or pull them manually. *) The old archive was about ~27MB for no particular good reason. This basically derived from the bad decision that also some PDF files where stored there. From this moment onwards, no binary objects are allowed to be stored in this repository anymore. The old archive is not wiped away from the Internet. You will still be able to find it, e.g. on git.cryptoism.org etc. Signed-off-by: Daniel Borkmann <dborkman@redhat.com> Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
generated by cgit v1.2.3-54-g00ecf (git 2.39.0) at 2024-09-21 12:22:11 +0000
d flagIdo Schimmel1-20/+80 We currently set the RTNH_F_OFFLOAD flag for all routes using remote action, but this isn't always correct. If none of the nexthops associated with a gatewayed route can be offloaded into the device, then any packet hitting it would be trapped to the CPU and forwarded by the kernel. Solve this by pushing the setting of the offload flag to after the route was programmed into the device, thereby allowing us to take all the parameters into account. This change will also help us further in the patchset, when we refresh routes following the reception of NH_{ADD,DEL} events. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net> 2017-02-08mlxsw: spectrum_router: Refactor nexthop init routineIdo Schimmel1-31/+49 The nexthop init and de-init functions both have symmetric parts concerned with the reflection of the neighbour entry into the device's adjacency table, in case it's used by a gatewayed route. These sections of code also need to be called when a nexthop is marked as valid / invalid following NH_{ADD,DEL} events. Break these out into appropriate functions, so that they could be invoked following the reception of above events. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net> 2017-02-08mlxsw: spectrum_router: Remove FIB info from FIB entry structIdo Schimmel1-3/+1 After the previous changes, the FIB info is embedded in every nexthop group struct, which in turn is embedded in every FIB entry struct. We can therefore safely remove the FIB info from the entry struct. This has the added advantage of making the router-related structs more generic and suitable for use with IPv6 offloads. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net> 2017-02-08mlxsw: spectrum_router: Store routes in a more generic wayIdo Schimmel1-13/+27 Up until now, the only FIB entries that were associated with a nexthop group were routes to remote networks where all the nexthop devices had a valid router interface (RIF). This is in contrast to the FIB code, where all the routes are associated with a FIB info. The same design choice needs to be applied to the driver's cache. Based on the NH_{ADD,DEL} events which will be added later in the patchset, we need to be able to change the action (forward / trap) associated with all the routes using the nexthop group. However, if we can't link between the nexthop and the routes using it, then the above is impossible. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net> 2017-02-08mlxsw: spectrum_router: Add gateway indication to nexthop groupIdo Schimmel1-1/+8 The next patch is going to generalize the way in which we store routes. Instead of attaching a nexthop group only to gatewayed routes, one will be attached to each route, in a similar way to the way the FIB code stores its routes. The above means that any function operating on a nexthop group cannot assume the group represents only gatewayed nexthops. One such function is the one that refreshes a nexthop group and updates the adjacency table following nexthop changes. For a nexthop group that doesn't represent any gateways this function would essentially be a NOP, but it would be useful if it did update the action associated with any route using it. This will allow us to later consolidate code paths when a nexthop changes following NH_{ADD,DEL} events. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net> 2017-02-08mlxsw: spectrum_router: Use nexthop's scope to set action typeIdo Schimmel1-1/+1 We currently use the scope of the FIB info to distinguish between a direct unicast route and a gatewayed one. However, the kernel is perfectly happy to configure a route with scope UNIVERSE to a directly connected network. Instead, we can rely on the first nexthop's scope to check if the route is gatewayed or not. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net> 2017-02-08mlxsw: spectrum_router: Store nexthops in a hash tableIdo Schimmel2-4/+55 Later in the patchset we'll add the NH_{ADD,DEL} events which will let us know when a nexthop is considered to be dead. Based on these events we need to be able to add or remove the nexthop from the device's tables. Therefore, store the private nexthop structs in a hash table and use the kernel's fib_nh struct as the key, so that we'll be able to easily find them when the events are received. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net> 2017-02-08mlxsw: spectrum_router: Store nexthop groups in a hash tableIdo Schimmel2-52/+54 Currently, when we're notified about a new RTN_UNICAST route we perform a lookup on the nexthop group list looking for a group with a matching configuration to that found in the FIB info. This is quite inefficient. Instead, we can simply rely on the kernel to consolidate several FIB configurations into the same FIB info and use the FIB info as the key for our private nexthop group struct. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net> 2017-02-08mlxsw: spectrum_router: Nullify nexthop's neigh pointerIdo Schimmel1-2/+3 When we invalidate a nexthop we should also invalidate its neighbour entry pointer as it might be destroyed later on. This makes the nexthop de-init function symmetric with its init and also ensures nobody will try to access the neighbour entry. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net> 2017-02-08mlxsw: acl: Fix mlxsw_afa_block_commit error pathJiri Pirko