On Mon, Jun 2, 2014 at 1:58 AM, Florian Westphal <fw@xxxxxxxxx> wrote: > Álvaro Neira Ayuso <alvaroneay@xxxxxxxxx> wrote: >> >>Now, when we add a rule with DSCP, in the code generation step, nftables >> >>compares 1 bytes but it should compare 6 bits. I think that the problem should >> >>be in the code generation. >> > >> >I don't really see how this patch changes this. The kernel operates in units >> >of bytes. For anything smaller nftables will have to generate appropriate >> >bitwise operations. Please explain in more detail how this patch changes this. >> > >> >> Now, nothing. For that it's stopped. I'm working for doing a patch >> for operating in the kernel not only with units of bytes like you >> say. In a couple of days, I'm going to send it to the list. > > Are you sure this is the right approach? > > It might be better to create appropriate masking instructions in > userspace, in most cases byte addressing is sufficient. > > Something like this (warning: untested, misses 'reverse' mapping to > remove the implicit bitops when listing rules): > > http://git.breakpoint.cc/cgit/fw/nftables.git/commit/?h=payload_offset_04&id=76ac27643400111785a8abb21fdd9e4311d9876e > -- > To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html I know very little about how nftables is actually implemented. That said: The IPv6 TOS byte is actually half in one byte half in the next, as a result of which the 6 dscp bits are 4 bits of one byte and 2 bits of the next. The IPv6 flowinfo field is similarly a 20 bit field 12 bits into the packet. The IPv4 fragment offset is 13 bits in size. I wonder if for performance reasons the right answer isn't to allow a fetch N<=64 bits from bit offset M (M=0..inf) opcode as opposed to doing the masking by hand (perhaps require (M%8)+N<=64 as well). Perhaps it should also be capable of left shifting the result by K bits (to deal with fields - like the ipv4 header length field - which count dwords instead of bytes). Theoretically with a sufficiently good jit compiler it shouldn't matter... but I'm assuming that's in the far future. (??) I'm not sure if there should be multiple versions of this (little-endian vs big-endian, bit ordering...) or just the immediately useful ones (ie. network byte order). - Maciej -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
