netdev
[Top] [All Lists]

Re: [PKT_SCHED]: Allow using nfmark as key in U32 classifier.

To: jamal <hadi@xxxxxxxxxx>
Subject: Re: [PKT_SCHED]: Allow using nfmark as key in U32 classifier.
From: Thomas Graf <tgraf@xxxxxxx>
Date: Mon, 3 Jan 2005 17:26:35 +0100
Cc: "David S. Miller" <davem@xxxxxxxxxxxxx>, netdev@xxxxxxxxxxx
In-reply-to: <1104767726.1049.591.camel@xxxxxxxxxxxxxxxx>
References: <20041231153930.GN32419@xxxxxxxxxxxxxx> <1104511494.1048.303.camel@xxxxxxxxxxxxxxxx> <20041231181153.GP32419@xxxxxxxxxxxxxx> <1104526311.1047.379.camel@xxxxxxxxxxxxxxxx> <20050101121041.GR32419@xxxxxxxxxxxxxx> <1104622164.1048.444.camel@xxxxxxxxxxxxxxxx> <20050102000612.GU32419@xxxxxxxxxxxxxx> <1104763012.1047.524.camel@xxxxxxxxxxxxxxxx> <20050103150230.GC26856@xxxxxxxxxxxxxx> <1104767726.1049.591.camel@xxxxxxxxxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
* jamal <1104767726.1049.591.camel@xxxxxxxxxxxxxxxx> 2005-01-03 10:55
> Sorry, havent looked at the code yet. Is the patch you posted the same
> as you have on the url earlier?

Yes, with a few minor fixes and I made it depend on
CONFIG_NET_CLS_EMATCH and added nil macros when it's not defined.
Those macros need some more work though.

TODO:
 - KConfig doc
 - make change optional
 - dump m->data if no dump implementation is provided

The question I'm yet unsure is whether to strictly return 1/0 or
allow classifier return codes.

Given I'm done with the above, a minimal ematch will look  like:

static int sec_match(struct sk_buff *skb, struct tcf_ematch *m)
{
        return *(u32 *) m->data == skb->security;
}

static struct tcf_ematch_ops sec_ops = {
        .kind = 11,
        .match = sec_match,
        .owner = THIS_MODULE
}

... init/exit calling tcf_em_(un_register ...

What do you think about checking RTA_PAYLOAD of the ematch data
for < sizeof(unsigned long) and assign it to m->data without
allocation? Would save us nonse allocations. The yet unused 8bit
in tcf_ematch_hdr would hold a flag to indicate that m->data
contains the data directly.

> I relaized that - but should the user know anything about this?

Actually no but initializing it in tcf_em_register wouldn't serve
any purpose so we can either remove it or leave it there.

<Prev in Thread] Current Thread [Next in Thread>