Re: [tcpdump-workers] twice past the taps, thence out to net?
On Thu, 15 Dec 2011 10:32:56 -0800 Rick Jones wrote: > > > More exactly, we call dev_queue_xmit_nit() from dev_hard_start_xmit() > > _before_ giving skb to device driver. > > > > If device driver returns NETDEV_TX_BUSY, and a qdisc was setup on the > > device, packet is requeued. > > > > Later, when queue is allowed to send again packets, packet is > > retransmitted (and traced a second time in dev_queue_xmit_nit()) > > Is this then an unintended consequence bug, or a known feature? > > rick > > > You can see the 'requeues' counter from "tc -s -d qdisc" output : > > > > qdisc mq 0: dev eth2 root > > Sent 29421597369 bytes 20301716 pkt (dropped 0, overlimits 0 requeues 371) > > backlog 0b 0p requeues 371 > > Sure enough: > > $ tc -s -d qdisc > qdisc mq 0: dev eth0 root > Sent 2212158799862 bytes 1938268098 pkt (dropped 0, overlimits 0 > requeues 4975139) > backlog 0b 0p requeues 4975139 > > rick jones Device's work better if the driver proactively manages stop_queue/wake_queue. Old devices used TX_BUSY, but newer devices tend to manage the queue themselves. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] vlan tagged packets and libpcap breakage
On Tue, 11 Dec 2012 14:36:33 -0800 (PST)
Ani Sinha wrote:
> >
> > It is possible to test for the presence of support of the new vlan bpf
> > extensions by attempting to load a filter that uses them. As only valid
> > filters can be loaded, old kernels that do not support filtering of vlan
> > tags will fail to load the a test filter with uses them.
>
> Unfortunately I do not see this. The sk_chk_filter() does not have a
> default in the case statement and the check will not detect an unknown
> instruction. It will fail when the filter is run and as far as I can see,
> the packet will be dropped. Something like this might help?
>
> diff --git a/net/core/filter.c b/net/core/filter.c
> index c23543c..96338aa 100644
> --- a/net/core/filter.c
> +++ b/net/core/filter.c
> @@ -548,6 +548,8 @@ int sk_chk_filter(struct sock_filter *filter, unsigned
> int flen)
> return -EINVAL;
> /* Some instructions need special checks */
> switch (code) {
> + /* for unknown instruction, return EINVAL */
> + default : return -EINVAL;
> case BPF_S_ALU_DIV_K:
> /* check for division by zero */
> if (ftest->k == 0)
Did you test this? I think it will blow up for some existing instructions
like BPF_S_ALU_XOR_X or any of the other non-special instructions.
Also it is not formatted correctly for the kernel programming style.
ERROR: space prohibited before that ':' (ctx:WxW)
#86: FILE: net/core/filter.c:552:
+ default : return -EINVAL;
^
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] Re: Setting BPF_SPECIAL_VLAN_HANDLING on a "dead" handle
--- Begin Message --- On Fri, 4 Jul 2025 13:05:01 -0700 Guy Harris wrote: > On Jul 4, 2025, at 8:55 AM, Bill Fenner wrote: > > > We may know that we will be using this code on a kernel that > > requires BPF_SPECIAL_VLAN_HANDLING, and so I'd like to be able to set that > > flag on a "dead" handle. Obviously, the current mechanism is to test this > > dynamically when the handle is live. > > > > Does anyone have any opinions about how to implement this, through the > > generic pcap interface? I can think of two possibilities: > > > > 1. implement set_special_vlan_handling_op, and have it implemented by dead > > and linux, and have the default version return an error > > 2. implement set_bpf_codegen_flags_op, and have a generic implementation, > > assuming that the caller completely knows what they are doing. Then move > > the definition of BPF_SPECIAL_VLAN_HANDLING from pcap-int.h to the public > > header. > > The underlying problem is that we have a compiler with multiple targets, and > the target is indicated by a pcap_t *. > > My inclination might be to have a version of pcap_compile() that takes, as > additional arguments, a link-layer type, a snapshot, and a set of > BPF_SPECIAL_ flags. > > That might be slightly cleaner than the bpf_open_dead() hack. Yes, it means > that the caller has to know what they're doing, but they'd have to know that > *anyway* - is the code intended for: > > * live captures with a Linux kernel without VLAN tag fetching support in BPF, > in which case you want BPF_SPECIAL_BASIC_HANDLING; > * live captures with a Linux kernel *with* VLAN tag fetching support in BPF, > in which case you want BPF_SPECIAL_BASIC_HANDLING|BPF_SPECIAL_VLAN_HANDLING; > * live captures with Npcap, in which case you want BPF_SPECIAL_VLAN_HANDLING; > * anything else, in which case you want 0. > > While we're at it, a new pcap_dump_open() routine that takes a link-layer > type and a snapshot length might be worth introducing, rendering > pcap_open_dead() mostly, if not completely, redundant. > ___ > tcpdump-workers mailing list -- tcpdump-workers@lists.tcpdump.org > To unsubscribe send an email to tcpdump-workers-le...@lists.tcpdump.org > %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s There is a related problem with use of pcap and BPF in DPDK. Current DPDK code use pcap_open_dead() and pcap_compile() to convert to cBPF, then converts that to eBPF. The problem is that it is impossible to look at metadata fields in the DPDK (negative offsets). To workaround that for now VLAN's are reinserted before running BPF. --- End Message --- ___ tcpdump-workers mailing list -- tcpdump-workers@lists.tcpdump.org To unsubscribe send an email to tcpdump-workers-le...@lists.tcpdump.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
